maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Archetype review
Date Mon, 21 May 2007 05:39:46 GMT
This is mostly for Raphaël, but also anyone else interested in  
Archetype dev.

So, as I understand it:
- maven-archetype-1.0.x branch is no longer needed (this was for the  
alpha series releases before the re-arrangement / refactoring that  
only got half done last year). I've removed it.
- trunk has had a number of changes made, though none very recent
- archetypeng was forked from trunk and changed drastically. It  
includes all the things that were done on trunk (Raphaël - can you  
confirm? Do you know what rev# it was forked from?)

So, I've started reviewing archetypeng as a replacement for trunk so  
that we have one place to move forward from. It's looking pretty  
good, but there are a few issues.

Here are my comments / questions on archetypeng (in my typical stream  
of conciousness, kitchen sink style):

*) Backwards compat issues / bugs

* archetype:create now prompts for input - this could cause problems  
for other users that relied on it using default values.
* archetype:create comes up empty on archetypes for o.a.m.archetypes.  
I guess this is a lack of current metadata?
* after selecting values I get "Confirm archetype  
* I don't think we should prompt for confirmation
* "Define value for version:" probably needs more explanation
* Package should still default to group ID IMO
* Running a second time retains the values selected the first time,  
which is inconsistent
* Leaving package empty causes it to fail with " The archetype  
generation must be configured here"
* Trying to generate from the webapp archetype gave: "Failed to  
generate project from the old archetype"

*) Concepts

* We'll need to change references to org.codehaus.mojo in both poms,  
code and doco, as well as references to NG
* Is the archetype descriptor required to do anything, or is it  
* The archetype descriptor seems like it's plugin configuration as  
well as the descriptor for inclusion - this seems to be a bad overlap
* I'm confused by the create-from-project goal: it seems to just  
create sources and properties, but doesn't actually produce the  
archetype? How is it meant to go from that to the final bundle?
* When I run create-from-project a second time, I get a string out of  
bounds exception
* Should the interactive part of create-from-project that generates  
the properties file be a separate goal from the one that produces an  
* Are there any examples of partial archetypes?

*) Code

* Should the archetype descriptor example be in the documentation  
instead of the model directory?
* We should come up with a better way to extend the settings file for  
use by plugins (general comment - using archetype.xml for now seems  
* not all the archetypes seem to be included in the bundles pom?
* what is the purpose of archetype-common? The code in there seems  
inconsistent in style - capitalised tag names and complicated  
statements that could be extracted from the code segments. The XSD is  
generated, but no reader/writer.
* Don't necessarily agree with the module structure - we should  
completely split out the actual archetypes, and make -core the top level
* Just a minor thing - the formatting (particularly the number of  
spaces in xml) is inconsistent which will make it hard to incorporate
* The licenses throughout are inconsistent (probably a pre-existing  
problem, Carlos recently corrected some on trunk)
* Not sure of the need for a clean goal (since I think should be written somewhere else, if at all)
* I think it'd be better to compose the execution stages of various  
calls to components rather than orchestrating mojos in the lifecycle  
- I don't see the usefulness of the mojos independent of the  
lifecycles they are declared in so it's unnecessary complexity  
(unless I'm missing something?). Looks particularly weird on create  
and create-from-project empty mojo
* Nitpicks: Exception handling, no need to set java defaults on mojo  
parameters that already have default-value
* Needs lots of Javadoc
* I think the interactivity should be externalised rather than  
conditional via the true/false flag on some methods
* The APIs seem very verbose - lots of parameters and exceptions. eg.  
what would the caller think an XmlPullParserException mean from  
* PathUtils seems like it could be replaced with something from  
* ListScanner is another duplication of code from plexus-utils - is  
there no way to reuse that?
* Is the languages hard-coded in Constants a problem?
* It might be nice to separate the maven-artifact related pieces from  
archetype-core: ie, so you could use the archetype api just by  
providing a jar file reference with no repository interaction
* The Exception classes should be suffixed with Exception

This is as far as I got here... didn't read through the code itself.

*) Documentation

* In the 'handcrafting' archetype doco, it mentions that you must use  
the type 'maven-plugin'. Is that correct? I thought it was maven- 
* In handcrafting, it says a pom is always necessary. Is that only  
for complete archetypes?
* In handcrafting, there is nothing about arbitrary source groups -  
is it possible to create these?

Thanks again for the efforts to get this critical piece of  
infrastructure finished.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message