My basic feedback would be similar to Jason's.
Key requirements:
- backwards compatibility with existing archetypes is a definite
requirement
- existing goal names need to continue to work, even if they are
deprecated
- if it's being designed from the ground up, it should have new
standards of testing and documentation
My main query is whether this needed a rewrite or whether it could be
done as incremental advancements on the current code base? It's
obviously a lot easier to consume that way as long as someone is
committed to reviewing and applying patches in short order.
Some more questions:
On 08/03/2007, at 10:54 AM, Raphaël Piéroni wrote:
- package mojo: to jar the created archetype
How is this different to a normal JAR that it needs it's own
packaging? Isn't it just additional resources in the lifecycle?
- sample properties mojo: to provide a sample configuration file
for an
archetype (which could be filled and used in batch mode)
What are the current needs of a configuration file? I figured that
even with the one we currently had, most of that could have been
autodiscovered from the archetype resources.
- descriptor with attributes: refactor the current archetype
descriptor to
use attributes instead of xml elements
Less is more :)
- generate multi project: to generate a project and its internal
modules
from one archetype.
Cool. I assume you are retaining the functionality I added where you
can incrementally add to a multiproject as well?
- CRUD group mojo: mojos to change the archetype groups defined in the
~/.m2/archetypes.xml
Don't really understand this, nor what archetypes.xml is for.
- Documentation: Document the workfow of user interaction, explain
the
internal plexus components
+1 :)
- integration tests and sibling: handle directories other than src/
main,
src/test, src/site. a first case would be integration tests
+1 :)
- pom.xml sibling: handle templates in the main directory. some use
case
would be readme files
- translator: create a tool to translate current archetypes into
this new
way
Wouldn't worry too much about this as loong as it remains backwards
compatible. It should be very straight forward to do by hand if the
implementation is simple enough to do it from scratch.
- archetype group metadata: create a new group metadata for
archetypes (same
way as plugins metadata) therefore we could have a archetype
packaging.
+1
- velocity tools in templates: provide the official velocity tools
to be
used by archetype creators
Sounds good too.
Thanks for taking the initiative, and responding to my concerns here.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
