On 12/03/2007, at 3:36 AM, Raphaël Piéroni wrote:
Is backward compatibility for archetype only the recognition of the
old
descriptor and pathes resolution ?
yes, if you generate from an old archetype you get the same thing as
if you create now.
The selection step of the proposition can not enforce compatibility
as it is
based on repository-metadata (like maven-plugins).
Selection was tied up in the old goal, so as long as that's
compatible, the new one can do what it wants.
I have some trouble with this as:
old goals are: create and create-from-project
and the new mapping proposed is generate instead of create and create
instead of create-from-project.
I would also note that in the jira the components are : creator for
create-from-project and generator for create.
How about keeping create as the deprecated goal with old parameters,
and then have generate and package/make/build/create-from-project/
something-else?
I must admit not understaning well what has to be done here.
Last year we agreed to a certain level of tests and documentation.
I'm digging it up anyway.
Basically, it just needs to have tests and docs :)
I would say that i can't see a path of patches. Please read the
proposition
code to be sure.
ok
- descriptor with attributes: refactor the current archetype
> descriptor to
> use attributes instead of xml elements
Less is more :)
By current i mean the current in the proposition.
I don't understand the subtlety of "less is more".
Sorry, was agreeing. It's good to have less to write in the descriptor.
- 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?
The main problem here is an archetype of a multiproject. like the
ear (ejb)
archetype.
And also to create suche an archetype from an existing project.
The current proposition can generate a project in partial mode, and
also
generate a subproject in an existing project (and insert a parent
element in
the generated pom - and a module in the parent project).
cool, that's the bit I was looking for.
- 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.
Archetype.xml is a file which holds the list of archetype groups
(just like
the pluginGroups in tsettings.xml)
That mojo will only be used to change the xml file. this mojo is
only for
convenience and will not be really important.
I'm not sure the mojo is worth it - quicker to just edit the file.
Do you intend to move those settings to settings.xml?
The translator will provide the may to enhance the metadata for the
selection.
Sorry, I couldn't understand this - can you rephrase?
Thanks,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
