Quick answer, will answer in depth after work. Raphaël
2007/5/21, Brett Porter <[EMAIL PROTECTED]>:
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?)
I didn't fork from a revision, but rewrite from scratch. 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
selection:org.apache.maven.archetypes/null". * 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 optional? * 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 archetype? * 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 right) * 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 archetype.properties 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 ArchetypeGenerator.generateArchetype? * PathUtils seems like it could be replaced with something from commons-io * 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- archetype? * 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. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
