My current task is now to document what i have done so far.
Answers and questions inlined. Raphaël 2007/3/12, Brett Porter <[EMAIL PROTECTED]>:
My basic feedback would be similar to Jason's. Key requirements: - backwards compatibility with existing archetypes is a definite requirement
Is backward compatibility for archetype only the recognition of the old descriptor and pathes resolution ? The selection step of the proposition can not enforce compatibility as it is based on repository-metadata (like maven-plugins). - existing goal names need to continue to work, even if they are
deprecated
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. - if it's being designed from the ground up, it should have new
standards of testing and documentation
I must admit not understaning well what has to be done here. 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.
I would say that i can't see a path of patches. Please read the proposition code to be sure. 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?
What i see here is just a jar around the created archetype's directory. I would also create a new packaging to provide the following functionnalities: - At install and deployment phases, an archetype needs the repository metadata to be updated (the same way as maven-plugin)
- 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.
What i see here is a mojo which write a sample property file to be used in the generation of the project. That sample file would contains the archetype definition, and the values of the required properties of the archetype. with those properties valuated using the archetype's default values. The properties without a default values will only be set to empty (or to "please_configure_this_property")
- 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".
- 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).
- 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.
- Documentation: Document the workfow of user interaction, explain > the > internal plexus components +1 :)
It is what i'm doning for now. i will sent a link to the generated html file as soon as i have completed it (at least wednesday and at most in 2 weeks)
- 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.
The translator will provide the may to enhance the metadata for the selection.
- 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.
Hoping my answers are sufficently explaining. Regards, Raphaël Cheers,
Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
