Answers inlined. Raphaël
2007/3/13, Brett Porter <[EMAIL PROTECTED]>:
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.
So as long as the old jars are donwloaded without selection nor configuration and as long as the generation can use the old descriptor, all is fine.
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?
OK for now i have : create, generate, clean, create-archetype, configure-creation, generate-project, configure-generation, select-archetype. the 5 last are hidden in wrapper lifecycles defined by the 2 firsts. I cant see a path of names to move from create-from-project and create. Because "create" conflicts. But it should be easy to change the names to change to create-project and generate-archetype and map the wrapper to lifecycle to create and create-from-project (as this is long to write, i would prefer generate)
> 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 have tested the main plexus components. but not the mojo executions which wraps around components. I currently making some doco. If agreed with the mojos renaming above, i will change the names just after having wrote doc enough.
> 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.
I seen it an a convenience for ide embedded to change the file (without having to know it). Do you intend to move those settings to settings.xml? I would like. I would also like to have a better metadata as those for plugin groups are not really designed for archetypes. I would like to offer a way to collect some basic information in the group metadata. That information would be used in the selection, for example if a project can be used in an existing project or not, and if it generates a project with child modules.
The translator will provide the may to enhance the metadata for the > selection. Sorry, I couldn't understand this - can you rephrase?
I can't understand too :) What i meant was that the translator component will take an existing archetype (by download) read the old descriptor, load the templates then rewrite a new descriptor based on the old one. It will also create a maven project holding the archetype (to enforce maven-plugin packaging). Therefore that project will inherit from the packaging the generation and deployment of the group metadatas which are used for selecting an archetype. Thanks,
Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
