maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raphaël Piéroni" <raphaelpier...@gmail.com>
Subject Re: Archetype review
Date Mon, 21 May 2007 06:56:07 GMT
Quick answer, will answer in depth after work.

Raphaël

2007/5/21, Brett Porter <brett@apache.org>:
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message