Overview
In certain enterprise environments there is a desire to restrict the use of archetypes. This document is an attempt to describe the need and possible solutions that can satisfy the need.
The Jira issue MNGECLIPSE-527 has been created to track this request.
Motivation
Scenario One
In my current work at Big Networking Company, we are rolling out new release engineering system based on SVN, Eclipse and Maven. We are developing Maven archetypes to help our developer community bootstrap new projects as well as add some much needed structure to our projects via the use of Maven's POM facility. For example, we using parent POMs and the enforcer to help ensure that project POMs provide an accurate description of team members.
Beyond the policing of projects we want to ensure a simple set of options in our initial release. That is to say, we want to limit the number of choices a developer has when starting new projects by limiting the visible artifacts in the m2eclispe New Project Wizard. As our release engineering practices mature, we'll introduce greater degrees of freedom.
And additional consideration is that we want to use central directly as we don't currently have a repo manager in place.
Scenario Two
I package M2Eclipse inside my Eclipse-based product so that my users can make use of the Maven-Eclipse integration. I have the need to embed a list of my own archetypes inside my product so that the number of archetypes is limited to those that apply to my product. These archetypes will be pulled from a repo other than central and the list will grow over time.
EK: Bruce, this is already possible. You can exclude Central repository index from your package and instead provide index for your own repository. You can even update index deployed at your repository, so list of archetypes will be updated accordingly without reinstalling plugin
Possible Solutions
- Forego The Use of Central
- Use a catalog in a repo other than central
EK: can you please elaborate what does that mean?
- Use a catalog in a repo other than central
- Build Filtering Support into M2Eclipse
- Filtering should include support for regular expressions
EK: Bruce, can you please check if archetype catalogs would be sufficient for you? It allow you do cherry pick any archetypes, package that list and deploy it in various places, so we could allow to select those catalogs from m2eclipse wizard as listed in the next section
- Filtering should include support for regular expressions
Random questions and ideas
- How environment specific settings should be delivered to the Big Networking Company developers?
- Could add Workbench-wide configuration UI under Window / Preferences... / Maven / Archetypes that would allow to add/enable/disable archetype catalogs?
- Extension point to allow to package custom archetype catalogs as Eclipse plugins, one could deliver custom catalogs via standard Eclipse update mechanisms
- Can make "Filter" field on the Archetype selection wizard page a drop-down with pre-configured filters. For configuration can use either catalogs, configuration UI or custom Eclipse extension point
- Add multiple separate lists of archetypes into profiles of some sort so that they can be enabled/disabled
EK: Bruce, this is basically what workspace archetype configuration UI is. It also seem like you want to declare your archetype catalogs in your product. To allow that we could provide an extension point for declaring catalogs
- Allow the use of a wiki page source for a list of archetypes
EK: wiki option been superseded by archetype catalogs that are also working from the Maven CLI
- Allow the use of a list of archetypes from a URL
EK: same here. archetype catalogs can be loaded from local file o url, which also brings us to the same option
Could add a flag to repository indexes that would enable/disable searching archetypes in the given index
Screen Mockups
Also see extension point.
Unable to render embedded object: File (archetypeprefs.png) not found.
Unable to render embedded object: File (archetypecatalogs.png) not found.