You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Raphaël Piéroni <ra...@gmail.com> on 2007/03/08 19:54:54 UTC
[Archetypes] plugin proposition
Hi all,
Here is the resent of a mail i sent on dev@mojo.
I would like to introduce the work i have done so far concerning archetypes.
I have improved the current archetype mecanism by adding
- the interactive selection of the archetype to create a project from
- the interactive configuration of the archetype to create a project from
- the interactive configuration of the archetype created from a project
To acheive this i needed to refactor the archetype descriptor and workflow.
I must admit having stole some code from current implementation :).
You can checkout the sources in the mojo sandbox. Just beware when
checking out the sources in Windows, the source tree is quite deep and
breaks.
I will be happy to have some feedback about it.
The plugins comes with a little pack of archetypes.
The core goals are :
- generate: to generate a project from an archetype
- create: to create an archetype from a project
This first implementation have som limitations as the archetypes are for
now mono-project.
I copy my current todo list for starting point to discuss about :
- package mojo: to jar the created archetype
- sample properties mojo: to provide a sample configuration file for an
archetype (which could be filled and used in batch mode)
- descriptor with attributes: refactor the current archetype descriptor to
use attributes instead of xml elements
- generate multi project: to generate a project and its internal modules
from one archetype.
- create multi project: to create one archetype from a project with modules
- CRUD group mojo: mojos to change the archetype groups defined in the
~/.m2/archetypes.xml
- Documentation: Document the workfow of user interaction, explain the
internal plexus components
- integration tests and sibling: handle directories other than src/main,
src/test, src/site. a first case would be integration tests
- 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
- archetype group metadata: create a new group metadata for archetypes (same
way as plugins metadata) therefore we could have a archetype packaging.
- velocity tools in templates: provide the official velocity tools to be
used by archetype creators
The plugin don't have backward compatibility yet.
Regards,
Raphaël
Re: [Archetypes] plugin proposition
Posted by Jason van Zyl <ja...@maven.org>.
On 8 Mar 07, at 10:54 AM 8 Mar 07, Raphaël Piéroni wrote:
> Hi all,
>
> Here is the resent of a mail i sent on dev@mojo.
>
> I would like to introduce the work i have done so far concerning
> archetypes.
> I have improved the current archetype mecanism by adding
> - the interactive selection of the archetype to create a project from
As long as this is not bound to the archetype mechanism. There should
be no interactivity interfaces touching archetype. A simple Map/
Properties should all should be fed in. I will look at the code but
no coupling to input mechanisms.
> - the interactive configuration of the archetype to create a
> project from
> - the interactive configuration of the archetype created from a
> project
>
Same goes for these two things. Do not bind the interaction to the
core. You can do it in the Mojo but not in archetype itself.
> To acheive this i needed to refactor the archetype descriptor and
> workflow.
> I must admit having stole some code from current implementation :).
>
> You can checkout the sources in the mojo sandbox. Just beware when
> checking out the sources in Windows, the source tree is quite deep and
> breaks.
>
> I will be happy to have some feedback about it.
>
> The plugins comes with a little pack of archetypes.
> The core goals are :
> - generate: to generate a project from an archetype
> - create: to create an archetype from a project
>
Cool.
> This first implementation have som limitations as the archetypes
> are for
> now mono-project.
>
> I copy my current todo list for starting point to discuss about :
>
> - package mojo: to jar the created archetype
> - sample properties mojo: to provide a sample configuration file
> for an
> archetype (which could be filled and used in batch mode)
> - descriptor with attributes: refactor the current archetype
> descriptor to
> use attributes instead of xml elements
> - generate multi project: to generate a project and its internal
> modules
> from one archetype.
> - create multi project: to create one archetype from a project with
> modules
> - CRUD group mojo: mojos to change the archetype groups defined in the
> ~/.m2/archetypes.xml
> - Documentation: Document the workfow of user interaction, explain
> the
> internal plexus components
> - integration tests and sibling: handle directories other than src/
> main,
> src/test, src/site. a first case would be integration tests
> - 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
> - archetype group metadata: create a new group metadata for
> archetypes (same
> way as plugins metadata) therefore we could have a archetype
> packaging.
> - velocity tools in templates: provide the official velocity tools
> to be
> used by archetype creators
I would put this list in JIRA under a new component in ARCHETYPE if
you have not already.
>
>
> The plugin don't have backward compatibility yet.
I have some thoughts on this and should be easy to support.
Jason.
>
> Regards,
>
> Raphaël
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
The first draft of the doco is updated (same place) with explains on mojos
and internal design.
But this doesn't prevent from reading the sources :-) (for more design
information).
My next step is now sorting the todo list and enhance with suggestions.
Jason gave me karma on the current archetype jira.
But i would need some tactical advice on using it
Do i need to create a 2.0 version of the components and start creating issus
with the tudu list ?
or shoudl i rather use the mojo jira ?
I guess issues can be moved from projects in jira.
Regards.
Raphaël
2007/3/14, Raphaël Piéroni <ra...@gmail.com>:
>
> A late addition.
> I just commited a start of doco. which could be seen at
> http://mojo.codehaus.org/maven-archetypeng/
>
> Raphael
>
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
A late addition.
I just commited a start of doco. which could be seen at
http://mojo.codehaus.org/maven-archetypeng/
Raphael
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Answers inlined.
Raphaël
2007/3/13, Brett Porter <br...@apache.org>:
>
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [Archetypes] plugin proposition
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Oups,
I forgotten to say that archetypes is the first foot a developper starts for
using maven.
This is why i'm concerned about archetypes.
I also see archetypes a examples of using maven (for example the axistools)
Raphaël
2007/3/12, Raphaël Piéroni <ra...@gmail.com>:
>
> My current task is now to document what i have done so far.
>
> Answers and questions inlined.
>
> Raphaël
>
> 2007/3/12, Brett Porter <brett@apache.org >:
> >
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
My current task is now to document what i have done so far.
Answers and questions inlined.
Raphaël
2007/3/12, Brett Porter <br...@apache.org>:
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [Archetypes] plugin proposition
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Hi
It seems, i have reached the alpha release point with
revision 4046.
Regards,
Raphaël
2007/4/25, Brett Porter <br...@apache.org>:
> Well, it sounds like you've got some more working happening now. What
> I'd suggest is that you get it to the point where you think it is
> ready for an alpha release - that would be a good point to replace
> the existing code.
>
> - Brett
>
> On 13/04/2007, at 7:57 PM, Raphaël Piéroni wrote:
>
> > Hi,
> >
> > feel free to steal the code from mojo.
> > but please, let me be informed as i could still contribute with
> > patches.
> >
> > Raphaël
> >
> > 2007/4/9, Brett Porter <br...@apache.org>:
> >> I think we should continue to use ARCHETYPE and start planning
> >> towards a 1.0 with the new code base. The current JIRA will need a
> >> clean up to see what issues are still relevant in the new code base,
> >> of course.
> >>
> >> - Brett
> >>
> >> On 09/04/2007, at 5:02 AM, Franz Allan Valencia See wrote:
> >>
> >> > Curious,..
> >> >
> >> > Where is the jira issue(s) for this? ..Can't seem to find them :-)
> >> >
> >> > Thanks,
> >> > Franz
> >> >
> >> > On 4/1/07, Milos Kleint <mk...@gmail.com> wrote:
> >> >>
> >> >> On 4/1/07, Jason van Zyl <ja...@maven.org> wrote:
> >> >> >
> >> >> > On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
> >> >> >
> >> >> > >>
> >> >> > >
> >> >> > > exactly this is a showstopper for me in the current archetype
> >> >> when I
> >> >> > > attempted to create an archetype for netbeans module
> >> >> development. I
> >> >> > > need to place Bundle.properties and layer.xml file in
> >> >> resources into
> >> >> > > the proper package.
> >> >> > >
> >> >> >
> >> >> > That's fine all we need is the right examples to work against.
> >> >> But in
> >> >> > your case do you just need the final distributable to have
> >> >> resources
> >> >> > in the same package as the classes or do you actually need to
> >> >> > archetype to mix resources with the sources?
> >> >>
> >> >> having the resources in the right place at runtime is fine. I know
> >> >> about targetPath element in resource definition, however I'd
> >> rather
> >> >> stay away from that.
> >> >>
> >> >> Often people will need to use both the META-INF/services path
> >> and the
> >> >> package named path like: org/codehaus/mevenide/netbeans/xxx.xxx
> >> >> and it
> >> >> becomes non-obvious where to put the services when you define the
> >> >> targetPath.
> >> >>
> >> >> On top of that localization bundles come here as well, these are
> >> >> to be
> >> >> placed in package named path as well, so there's one
> >> >> Bundle.properties
> >> >> for for eac package in the module + some gifs etc. And the form
> >> >> editor
> >> >> in the IDE is not capable of handling the shortened paths. Also
> >> the
> >> >> module development file templates can have problems with it.
> >> >>
> >> >> Milos
> >> >>
> >> >>
> >> >> >
> >> >> > Jason.
> >> >> >
> >> >> > > Milos
> >> >> > >
> >> >> > >
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [Archetypes] plugin proposition
Posted by Brett Porter <br...@apache.org>.
Well, it sounds like you've got some more working happening now. What
I'd suggest is that you get it to the point where you think it is
ready for an alpha release - that would be a good point to replace
the existing code.
- Brett
On 13/04/2007, at 7:57 PM, Raphaël Piéroni wrote:
> Hi,
>
> feel free to steal the code from mojo.
> but please, let me be informed as i could still contribute with
> patches.
>
> Raphaël
>
> 2007/4/9, Brett Porter <br...@apache.org>:
>> I think we should continue to use ARCHETYPE and start planning
>> towards a 1.0 with the new code base. The current JIRA will need a
>> clean up to see what issues are still relevant in the new code base,
>> of course.
>>
>> - Brett
>>
>> On 09/04/2007, at 5:02 AM, Franz Allan Valencia See wrote:
>>
>> > Curious,..
>> >
>> > Where is the jira issue(s) for this? ..Can't seem to find them :-)
>> >
>> > Thanks,
>> > Franz
>> >
>> > On 4/1/07, Milos Kleint <mk...@gmail.com> wrote:
>> >>
>> >> On 4/1/07, Jason van Zyl <ja...@maven.org> wrote:
>> >> >
>> >> > On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
>> >> >
>> >> > >>
>> >> > >
>> >> > > exactly this is a showstopper for me in the current archetype
>> >> when I
>> >> > > attempted to create an archetype for netbeans module
>> >> development. I
>> >> > > need to place Bundle.properties and layer.xml file in
>> >> resources into
>> >> > > the proper package.
>> >> > >
>> >> >
>> >> > That's fine all we need is the right examples to work against.
>> >> But in
>> >> > your case do you just need the final distributable to have
>> >> resources
>> >> > in the same package as the classes or do you actually need to
>> >> > archetype to mix resources with the sources?
>> >>
>> >> having the resources in the right place at runtime is fine. I know
>> >> about targetPath element in resource definition, however I'd
>> rather
>> >> stay away from that.
>> >>
>> >> Often people will need to use both the META-INF/services path
>> and the
>> >> package named path like: org/codehaus/mevenide/netbeans/xxx.xxx
>> >> and it
>> >> becomes non-obvious where to put the services when you define the
>> >> targetPath.
>> >>
>> >> On top of that localization bundles come here as well, these are
>> >> to be
>> >> placed in package named path as well, so there's one
>> >> Bundle.properties
>> >> for for eac package in the module + some gifs etc. And the form
>> >> editor
>> >> in the IDE is not capable of handling the shortened paths. Also
>> the
>> >> module development file templates can have problems with it.
>> >>
>> >> Milos
>> >>
>> >>
>> >> >
>> >> > Jason.
>> >> >
>> >> > > Milos
>> >> > >
>> >> > >
>> >>
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Hi,
feel free to steal the code from mojo.
but please, let me be informed as i could still contribute with patches.
Raphaël
2007/4/9, Brett Porter <br...@apache.org>:
> I think we should continue to use ARCHETYPE and start planning
> towards a 1.0 with the new code base. The current JIRA will need a
> clean up to see what issues are still relevant in the new code base,
> of course.
>
> - Brett
>
> On 09/04/2007, at 5:02 AM, Franz Allan Valencia See wrote:
>
> > Curious,..
> >
> > Where is the jira issue(s) for this? ..Can't seem to find them :-)
> >
> > Thanks,
> > Franz
> >
> > On 4/1/07, Milos Kleint <mk...@gmail.com> wrote:
> >>
> >> On 4/1/07, Jason van Zyl <ja...@maven.org> wrote:
> >> >
> >> > On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
> >> >
> >> > >>
> >> > >
> >> > > exactly this is a showstopper for me in the current archetype
> >> when I
> >> > > attempted to create an archetype for netbeans module
> >> development. I
> >> > > need to place Bundle.properties and layer.xml file in
> >> resources into
> >> > > the proper package.
> >> > >
> >> >
> >> > That's fine all we need is the right examples to work against.
> >> But in
> >> > your case do you just need the final distributable to have
> >> resources
> >> > in the same package as the classes or do you actually need to
> >> > archetype to mix resources with the sources?
> >>
> >> having the resources in the right place at runtime is fine. I know
> >> about targetPath element in resource definition, however I'd rather
> >> stay away from that.
> >>
> >> Often people will need to use both the META-INF/services path and the
> >> package named path like: org/codehaus/mevenide/netbeans/xxx.xxx
> >> and it
> >> becomes non-obvious where to put the services when you define the
> >> targetPath.
> >>
> >> On top of that localization bundles come here as well, these are
> >> to be
> >> placed in package named path as well, so there's one
> >> Bundle.properties
> >> for for eac package in the module + some gifs etc. And the form
> >> editor
> >> in the IDE is not capable of handling the shortened paths. Also the
> >> module development file templates can have problems with it.
> >>
> >> Milos
> >>
> >>
> >> >
> >> > Jason.
> >> >
> >> > > Milos
> >> > >
> >> > >
> >> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [Archetypes] plugin proposition
Posted by Brett Porter <br...@apache.org>.
I think we should continue to use ARCHETYPE and start planning
towards a 1.0 with the new code base. The current JIRA will need a
clean up to see what issues are still relevant in the new code base,
of course.
- Brett
On 09/04/2007, at 5:02 AM, Franz Allan Valencia See wrote:
> Curious,..
>
> Where is the jira issue(s) for this? ..Can't seem to find them :-)
>
> Thanks,
> Franz
>
> On 4/1/07, Milos Kleint <mk...@gmail.com> wrote:
>>
>> On 4/1/07, Jason van Zyl <ja...@maven.org> wrote:
>> >
>> > On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
>> >
>> > >>
>> > >
>> > > exactly this is a showstopper for me in the current archetype
>> when I
>> > > attempted to create an archetype for netbeans module
>> development. I
>> > > need to place Bundle.properties and layer.xml file in
>> resources into
>> > > the proper package.
>> > >
>> >
>> > That's fine all we need is the right examples to work against.
>> But in
>> > your case do you just need the final distributable to have
>> resources
>> > in the same package as the classes or do you actually need to
>> > archetype to mix resources with the sources?
>>
>> having the resources in the right place at runtime is fine. I know
>> about targetPath element in resource definition, however I'd rather
>> stay away from that.
>>
>> Often people will need to use both the META-INF/services path and the
>> package named path like: org/codehaus/mevenide/netbeans/xxx.xxx
>> and it
>> becomes non-obvious where to put the services when you define the
>> targetPath.
>>
>> On top of that localization bundles come here as well, these are
>> to be
>> placed in package named path as well, so there's one
>> Bundle.properties
>> for for eac package in the module + some gifs etc. And the form
>> editor
>> in the IDE is not capable of handling the shortened paths. Also the
>> module development file templates can have problems with it.
>>
>> Milos
>>
>>
>> >
>> > Jason.
>> >
>> > > Milos
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Franz Allan Valencia See <fr...@gmail.com>.
Curious,..
Where is the jira issue(s) for this? ..Can't seem to find them :-)
Thanks,
Franz
On 4/1/07, Milos Kleint <mk...@gmail.com> wrote:
>
> On 4/1/07, Jason van Zyl <ja...@maven.org> wrote:
> >
> > On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
> >
> > >>
> > >
> > > exactly this is a showstopper for me in the current archetype when I
> > > attempted to create an archetype for netbeans module development. I
> > > need to place Bundle.properties and layer.xml file in resources into
> > > the proper package.
> > >
> >
> > That's fine all we need is the right examples to work against. But in
> > your case do you just need the final distributable to have resources
> > in the same package as the classes or do you actually need to
> > archetype to mix resources with the sources?
>
> having the resources in the right place at runtime is fine. I know
> about targetPath element in resource definition, however I'd rather
> stay away from that.
>
> Often people will need to use both the META-INF/services path and the
> package named path like: org/codehaus/mevenide/netbeans/xxx.xxx and it
> becomes non-obvious where to put the services when you define the
> targetPath.
>
> On top of that localization bundles come here as well, these are to be
> placed in package named path as well, so there's one Bundle.properties
> for for eac package in the module + some gifs etc. And the form editor
> in the IDE is not capable of handling the shortened paths. Also the
> module development file templates can have problems with it.
>
> Milos
>
>
> >
> > Jason.
> >
> > > Milos
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Hi,
I didn't expected so many answers :)
for archetype, there is two process:
- generation of a project from an archetype
- creation of an archetype from a project
The generation reads the descriptor and files in jar to
generate the project's files. The required properties
are used as extra configuration in the velocity context
for files which are filtered. Some of the files of the
archetype are packaged (this means the packageName is
used in directory); some files are not filtered (like
images). Both of those two aspects of files can be combined.
Some archetypes generates complete projects and some
only enhance projects features (like adding the usage
of a particular plugin).
The creation is where some guess is made. It should guess:
- if the project has modules or not
- for each the root project (and optionaly modules)
it should guess which files are packaged, which are
filetered.
the packaged files are those located
in directory (relative to the project or module)
"src/X/L" with X is main, test, ... and L is contained
in a list of known languages (read public final static
String languages).
the filtered files are those named with a particular
extension (mostly we should check for well known non-
filtered file like images, sounds)
After this explain (which mostly was done for me to
settle my ideas) i will now answer.
1. About JVZ's comment:
"But as far as any sources, resources and any filtering
what is done in the POM for the Archetype project is how
the prototype generated from that Archetype should end up."
What i imagined was some archetype tree when deployed in
repository like this:
an-archetype.pom (only a minimal pom)
an-archetype.jar
+ META-INF/maven/archetype.xml (the proposed descriptor)
+ archetype-resources (the archetype files - which
contains the generated project's pom)
What i understand of the comment is a tree like this
an-archetype.pom
an-archetype.jar
+ MATA-INF/maven/archetype.xml (only describe the required properties)
+ archetype-resources (idem but poms hold the descriptor for modules,
filtered/packaged files)
I am agree that if the fileSets can be expressed in
the project's pom (and modules' poms) with full features
(packaged/filtered) therefore these elements are no longer needed
in the descriptor. If the required properties can be somehow moved
in the generated project's pom it can be removed from the descriptor.
But i can't see how to move the properties and fileSets from
the descriptor (and defined in the generated projects poms)
whithout leaving, in the generated projects, some information
about the fact that it was first an archetype (which could confuse a
first time maven user).
And also the descriptor also has to express
the possibility to have a uncomplete archeype (which adds some plugin
usage in the project in which the archetype is used and some files
in the project directory tree).
If any one can show how to achieve this?
2. About Heinrich's comment
I am agree, but must admit that i wasn't even thinking about such thing
as plugins knowledge for the archetype plugin (which is unfeasable
because all the potential plugins should be taken into account even
before they are specified nor really exist)
3. About Eric's comment
"Why not make the properties just like they are in the pom/settings - for
consistency?
<propKey>default value</propKey>"
Only because my proposition is easyer for me to write the code given the
current implementation. I am somehow lazy sometimes.
"Why are 'filtered' and 'packaged' attributes, but 'directory' is not? I'm
not against attributes, per se, but what is the criteria for one versus the
other?"
It is totaly arbitrary :) . The only real reason i can imagine is that
these attributes are boolean and the directory is a string (which can
contains char forbidden in an xml attribute - but i'm not sure on this)
4. About JVZ's comment
"Also, as Velocity is being used,
anything you escaped (i.e. something like ${foo} ) would not be
interpolated by the Archetype generation process."
It is for this feature that the required properties are defined.
5. About the convention-configuration aspect
The problem is to have fileSets defining somthing
obvious like directory=src/main/java.
What about having some special fileSets which contains some convention
and have regular fileSets to provide all the configuration desired?
I have in mind:
<fileSets>
<sourceSet language="csharp" test="true" filtered="true">
<!--default language is java, default test is false, default filtered is true
files are packaged and generated in src/X/language X=main or test-->
<includes/>
</sourceSet>
<resourceSet directory="modello" test="true" filtered="false"/>
<!--default directory is resources, default test is false, default
filtered is true
files are not packaged and generated in src/X/directory X=main or test-->
<includes/>
</resourceSet>
<siteSet filtered="true">
<includes/>
</siteSet>
<fileSet/><!-- idem proposition-->
</fileSets>
I only removed the source, resource, site sets to remove some complexity.
Here i stop for today.
An issue i still see is the algorithm of guessing the files (by categorisation)
to create a project from an archetype. The generation process is straitforward
(what the real spellling ?) given the creation process is made.
I hope to make sense and not offend anyone for obvious or naïve though
Regards,
Raphaël
Re: [Archetypes] plugin proposition
Posted by Milos Kleint <mk...@gmail.com>.
On 4/1/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
>
> >>
> >
> > exactly this is a showstopper for me in the current archetype when I
> > attempted to create an archetype for netbeans module development. I
> > need to place Bundle.properties and layer.xml file in resources into
> > the proper package.
> >
>
> That's fine all we need is the right examples to work against. But in
> your case do you just need the final distributable to have resources
> in the same package as the classes or do you actually need to
> archetype to mix resources with the sources?
having the resources in the right place at runtime is fine. I know
about targetPath element in resource definition, however I'd rather
stay away from that.
Often people will need to use both the META-INF/services path and the
package named path like: org/codehaus/mevenide/netbeans/xxx.xxx and it
becomes non-obvious where to put the services when you define the
targetPath.
On top of that localization bundles come here as well, these are to be
placed in package named path as well, so there's one Bundle.properties
for for eac package in the module + some gifs etc. And the form editor
in the IDE is not capable of handling the shortened paths. Also the
module development file templates can have problems with it.
Milos
>
> Jason.
>
> > Milos
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Jason van Zyl <ja...@maven.org>.
On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
>>
>
> exactly this is a showstopper for me in the current archetype when I
> attempted to create an archetype for netbeans module development. I
> need to place Bundle.properties and layer.xml file in resources into
> the proper package.
>
That's fine all we need is the right examples to work against. But in
your case do you just need the final distributable to have resources
in the same package as the classes or do you actually need to
archetype to mix resources with the sources?
Jason.
> Milos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Milos Kleint <mk...@gmail.com>.
On 3/31/07, Heinrich Nirschl <he...@gmail.com> wrote:
> On 3/31/07, Jason van Zyl <ja...@maven.org> wrote:
> >
> > On 31 Mar 07, at 12:08 PM 31 Mar 07, Heinrich Nirschl wrote:
> >
> > > On 3/31/07, Jason van Zyl <ja...@maven.org> wrote:
> > >>
> > >> On 31 Mar 07, at 10:07 AM 31 Mar 07, Raphaël Piéroni wrote:
> > >>
> > >> > Hi here comes a new proposition for the future descriptor.
> > >> >
> > >> > I made it the most simpler i can think.
> > >> >
> > >> > Please comment it.
> > >> >
> > >>
> > >> I think it duplicates too much that's in the POM. The POM should be
> > >> the model that used for Archetype wherever possible and an ancillary
> > >> model should only be used where absolutely necessary. But as far as
> > >> any sources, resources and any filtering what is done in the POM for
> > >> the Archetype project is how the prototype generated from that
> > >> Archetype should end up.
> > >
> > > I don't think it is feasible in all cases to take out the information
> > > from the pom.
> >
> > I didn't say in all cases.
> >
> > > For example, the archetype author may want to put some
> > > resources into the specified package, while others have already the
> > > correct place. The pom does not allow to express this.
> >
> > Sorry, I don't grok this sentence. Give me an example.
>
> Some resources should have an absolute position in the classpath, an
> example being log4j.properties which is normally in the root of the
> classpath (default package).
> Other resources, like for example hibernate mappings, should be in the
> same package as the class they belong to.
> This means, in an archetype it must be possible to control which
> resource files get prefixed by the package and which don't. It is
> hard, if not impossible, to make the decision automatically.
>
exactly this is a showstopper for me in the current archetype when I
attempted to create an archetype for netbeans module development. I
need to place Bundle.properties and layer.xml file in resources into
the proper package.
Milos
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Heinrich Nirschl <he...@gmail.com>.
On 3/31/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 31 Mar 07, at 12:08 PM 31 Mar 07, Heinrich Nirschl wrote:
>
> > On 3/31/07, Jason van Zyl <ja...@maven.org> wrote:
> >>
> >> On 31 Mar 07, at 10:07 AM 31 Mar 07, Raphaël Piéroni wrote:
> >>
> >> > Hi here comes a new proposition for the future descriptor.
> >> >
> >> > I made it the most simpler i can think.
> >> >
> >> > Please comment it.
> >> >
> >>
> >> I think it duplicates too much that's in the POM. The POM should be
> >> the model that used for Archetype wherever possible and an ancillary
> >> model should only be used where absolutely necessary. But as far as
> >> any sources, resources and any filtering what is done in the POM for
> >> the Archetype project is how the prototype generated from that
> >> Archetype should end up.
> >
> > I don't think it is feasible in all cases to take out the information
> > from the pom.
>
> I didn't say in all cases.
>
> > For example, the archetype author may want to put some
> > resources into the specified package, while others have already the
> > correct place. The pom does not allow to express this.
>
> Sorry, I don't grok this sentence. Give me an example.
Some resources should have an absolute position in the classpath, an
example being log4j.properties which is normally in the root of the
classpath (default package).
Other resources, like for example hibernate mappings, should be in the
same package as the class they belong to.
This means, in an archetype it must be possible to control which
resource files get prefixed by the package and which don't. It is
hard, if not impossible, to make the decision automatically.
>
> >
> > For filtering, one would like to have the control if a file is
> > filtered during the project generation by the archetype. This is not
> > expressed in the pom either.
>
> This we could do by a naming convention, either in the file name or
> in a directory with a certain name. Also, as Velocity is being used,
> anything you escaped (i.e. something like ${foo} ) would not be
> interpolated by the Archetype generation process.
Naming conventions, if they are not very intuitive, are exactly the
kind of magic that keeps you busy for a while if things don't work as
expected.
I agree, escaping would be a solution for the filtering problem.
However, if there is a lot to escape it may be simpler, to do some
extra configuration.
>
> >
> > Another example are files pulled in by plugins. The archetype plugin
> > would have to understand the behavior of these plugins if there is no
> > additional configuration.
>
> Example?
The javadoc plugin expects some files in ${basedir}/src/main/javadoc
(For a related problem with the current archetype plugin see
ARCHETYPE-62). The package.html file should get prefixed by the
package.
>
> >
> > I like Raphaël's proposal very much. It is easy to understand,
> > flexible, and there are no surprises for the archetype author. The
> > author is in control. If there is too much magic involved one has a
> > very hard time to fix things when the magic goes wrong. Sparse
> > documentation makes the situation even worse.
>
> I'm not against a descriptor, I just don't want information
> duplicated where it doesn't have to be. Ideally the archetype should
> be easy to create, test, and provide easy prototyping capabilities.
> But I would much rather see standard directories to control the
> behavior of a given resource i.e. like filtering. Ideally I would
> like like anyone to have to see the descriptor at all. Using some
> conventions the Archetype will just be created correctly.
I see your point. But I fear, due to the complexity there will always
be cases where the automatic selection of the set of files, filtering,
or package prefixing makes the wrong guess. If this happens, it can be
the cause of long experiments for finding a workaround.
In any case, the configuration should win over the convention. If the
archetype author explicitly specifies certain behavior, this should be
honored.
Henry.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Jason van Zyl <ja...@maven.org>.
On 31 Mar 07, at 12:08 PM 31 Mar 07, Heinrich Nirschl wrote:
> On 3/31/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>> On 31 Mar 07, at 10:07 AM 31 Mar 07, Raphaël Piéroni wrote:
>>
>> > Hi here comes a new proposition for the future descriptor.
>> >
>> > I made it the most simpler i can think.
>> >
>> > Please comment it.
>> >
>>
>> I think it duplicates too much that's in the POM. The POM should be
>> the model that used for Archetype wherever possible and an ancillary
>> model should only be used where absolutely necessary. But as far as
>> any sources, resources and any filtering what is done in the POM for
>> the Archetype project is how the prototype generated from that
>> Archetype should end up.
>
> I don't think it is feasible in all cases to take out the information
> from the pom.
I didn't say in all cases.
> For example, the archetype author may want to put some
> resources into the specified package, while others have already the
> correct place. The pom does not allow to express this.
Sorry, I don't grok this sentence. Give me an example.
>
> For filtering, one would like to have the control if a file is
> filtered during the project generation by the archetype. This is not
> expressed in the pom either.
This we could do by a naming convention, either in the file name or
in a directory with a certain name. Also, as Velocity is being used,
anything you escaped (i.e. something like ${foo} ) would not be
interpolated by the Archetype generation process.
>
> Another example are files pulled in by plugins. The archetype plugin
> would have to understand the behavior of these plugins if there is no
> additional configuration.
Example?
>
> I like Raphaël's proposal very much. It is easy to understand,
> flexible, and there are no surprises for the archetype author. The
> author is in control. If there is too much magic involved one has a
> very hard time to fix things when the magic goes wrong. Sparse
> documentation makes the situation even worse.
I'm not against a descriptor, I just don't want information
duplicated where it doesn't have to be. Ideally the archetype should
be easy to create, test, and provide easy prototyping capabilities.
But I would much rather see standard directories to control the
behavior of a given resource i.e. like filtering. Ideally I would
like like anyone to have to see the descriptor at all. Using some
conventions the Archetype will just be created correctly.
Jason.
>
> Henry.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Heinrich Nirschl <he...@gmail.com>.
On 3/31/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 31 Mar 07, at 10:07 AM 31 Mar 07, Raphaël Piéroni wrote:
>
> > Hi here comes a new proposition for the future descriptor.
> >
> > I made it the most simpler i can think.
> >
> > Please comment it.
> >
>
> I think it duplicates too much that's in the POM. The POM should be
> the model that used for Archetype wherever possible and an ancillary
> model should only be used where absolutely necessary. But as far as
> any sources, resources and any filtering what is done in the POM for
> the Archetype project is how the prototype generated from that
> Archetype should end up.
I don't think it is feasible in all cases to take out the information
from the pom. For example, the archetype author may want to put some
resources into the specified package, while others have already the
correct place. The pom does not allow to express this.
For filtering, one would like to have the control if a file is
filtered during the project generation by the archetype. This is not
expressed in the pom either.
Another example are files pulled in by plugins. The archetype plugin
would have to understand the behavior of these plugins if there is no
additional configuration.
I like Raphaël's proposal very much. It is easy to understand,
flexible, and there are no surprises for the archetype author. The
author is in control. If there is too much magic involved one has a
very hard time to fix things when the magic goes wrong. Sparse
documentation makes the situation even worse.
Henry.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Jason van Zyl <ja...@maven.org>.
On 31 Mar 07, at 10:07 AM 31 Mar 07, Raphaël Piéroni wrote:
> Hi here comes a new proposition for the future descriptor.
>
> I made it the most simpler i can think.
>
> Please comment it.
>
I think it duplicates too much that's in the POM. The POM should be
the model that used for Archetype wherever possible and an ancillary
model should only be used where absolutely necessary. But as far as
any sources, resources and any filtering what is done in the POM for
the Archetype project is how the prototype generated from that
Archetype should end up.
> Regards,
>
> Raphaël
>
>
> <archetype id="archetype-artifact-id" partial="true|false" >
> <!-- id is mandatory and partial is optional (defaults to false)
> -->
> <requiredProperties>
> <!--
> optional element as common required properties are
> groupId, artifactId, version and package
> (aliased with packageName when calling the mojo)
> -->
> <!-- maybe in flat mode -->
> <requiredProperty key="propKey" default-value="string to
> replace" />
> <!-- key is mandatory and default-value is optional -->
> </requiredProperties>
What are some examples of these?
> <fileSets>
> <!-- maybe in flat mode -->
> <fileSet filtered="true|false" packaged="true|false" />
> <!-- filtered is optional (defaults to true) -->
> <!-- packaged is optional (defaults to true) -->
> <directory>src/main/java</directory>
> <!-- directory is mandatory -->
> <includes>
> <include>**/*.java</include>
> </includes>
> <!-- includes is optional (defaults to "**/*") -->
> <excludes>
> <exclude>Main.java</exclude>
> </excludes>
> <!-- excludes is optional (defaults to "") -->
> </fileSet>
> <!--
> the generated project's pom.xml file don't have to
> be defined in the fileSet as it is mandatory to have
> this file for a maven project (even partial ones)
> and therefore, the generation will always try to generate
> one using filters on it.
> -->
> </file-sets>
I think any of this should be taken directly from the POM for the
project in question.
> <modules>
> <!-- modules is optional -->
> <module id="module-artifact-id">
> <!-- id is mandatory -->
> <fileSets/>
> <!-- fileSets is the same as in archetype -->
> <modules/>
> <!-- modules is the same as in archetype -->
> </module>
> </modules>
Again, here this should be taken from the POM.
Jason.
> </archetype>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Eric Redmond <er...@gmail.com>.
On 3/31/07, Raphaël Piéroni <ra...@gmail.com> wrote:
>
> Hi here comes a new proposition for the future descriptor.
>
> I made it the most simpler i can think.
>
> Please comment it.
>
> Regards,
>
> Raphaël
>
>
> <archetype id="archetype-artifact-id" partial="true|false" >
> <!-- id is mandatory and partial is optional (defaults to false) -->
> <requiredProperties>
> <!--
> optional element as common required properties are
> groupId, artifactId, version and package
> (aliased with packageName when calling the mojo)
> -->
> <!-- maybe in flat mode -->
> <requiredProperty key="propKey" default-value="string to replace"
> />
> <!-- key is mandatory and default-value is optional -->
> </requiredProperties>
Why not make the properties just like they are in the pom/settings - for
consistency?
<propKey>default value</propKey>
<fileSets>
> <!-- maybe in flat mode -->
> <fileSet filtered="true|false" packaged="true|false" />
Why are 'filtered' and 'packaged' attributes, but 'directory' is not? I'm
not against attributes, per se, but what is the criteria for one versus the
other?
<!-- filtered is optional (defaults to true) -->
> <!-- packaged is optional (defaults to true) -->
> <directory>src/main/java</directory>
> <!-- directory is mandatory -->
> <includes>
> <include>**/*.java</include>
> </includes>
> <!-- includes is optional (defaults to "**/*") -->
> <excludes>
> <exclude>Main.java</exclude>
> </excludes>
> <!-- excludes is optional (defaults to "") -->
> </fileSet>
> <!--
> the generated project's pom.xml file don't have to
> be defined in the fileSet as it is mandatory to have
> this file for a maven project (even partial ones)
> and therefore, the generation will always try to generate
> one using filters on it.
> -->
> </file-sets>
> <modules>
> <!-- modules is optional -->
> <module id="module-artifact-id">
> <!-- id is mandatory -->
> <fileSets/>
> <!-- fileSets is the same as in archetype -->
> <modules/>
> <!-- modules is the same as in archetype -->
> </module>
> </modules>
> </archetype>
>
--
Eric Redmond
http://codehaus.org/~eredmond
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Hi here comes a new proposition for the future descriptor.
I made it the most simpler i can think.
Please comment it.
Regards,
Raphaël
<archetype id="archetype-artifact-id" partial="true|false" >
<!-- id is mandatory and partial is optional (defaults to false) -->
<requiredProperties>
<!--
optional element as common required properties are
groupId, artifactId, version and package
(aliased with packageName when calling the mojo)
-->
<!-- maybe in flat mode -->
<requiredProperty key="propKey" default-value="string to replace" />
<!-- key is mandatory and default-value is optional -->
</requiredProperties>
<fileSets>
<!-- maybe in flat mode -->
<fileSet filtered="true|false" packaged="true|false" />
<!-- filtered is optional (defaults to true) -->
<!-- packaged is optional (defaults to true) -->
<directory>src/main/java</directory>
<!-- directory is mandatory -->
<includes>
<include>**/*.java</include>
</includes>
<!-- includes is optional (defaults to "**/*") -->
<excludes>
<exclude>Main.java</exclude>
</excludes>
<!-- excludes is optional (defaults to "") -->
</fileSet>
<!--
the generated project's pom.xml file don't have to
be defined in the fileSet as it is mandatory to have
this file for a maven project (even partial ones)
and therefore, the generation will always try to generate
one using filters on it.
-->
</file-sets>
<modules>
<!-- modules is optional -->
<module id="module-artifact-id">
<!-- id is mandatory -->
<fileSets/>
<!-- fileSets is the same as in archetype -->
<modules/>
<!-- modules is the same as in archetype -->
</module>
</modules>
</archetype>
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Hi,
Refactored to use almost the same behaviour as archetype-1.0-alpha-4.
The ones made are:
- goals names create and create-from-project,
- propagate on old code when resolving to an old archetype during create goal.
What is not backward compatible:
- the ${remoteRepositories} property is not used,
- the create-from-project goal doesn't use the old code.
I have uploaded a snapshot on http://snapshots.repository.codehaus.org/
and have a little updated the documentation
(http://mojo.codehaus.org/maven-archetypeng/).
Please have a look and try it.
Yet to be done :
- refactor descriptor with attributes and simplify templating
- generation and creation of multimodule
- use archetype-registry to remember old archetypes and versions
- use archetype-registry to remember the archetype repositories
Far future:
- move archetype-groups from registry to settings
- archetype packaging with site report on required
properties and sample tree of generated files
Regards,
Raphaël
> >
> > So to summarise the needed actions:
> > 1. backward compatibility of names
> > 2. backward compatibility on old descriptor and downloading
> > 3. backward compat on command line option (-D)
> > 4. backward compat on behaviour (but the prompting is by default
> > unless called with -B)
Re: [Archetypes] plugin proposition
Posted by Brett Porter <br...@apache.org>.
On 24/03/2007, at 4:24 AM, Raphaël Piéroni wrote:
>> This looks very good. The only thing I noticed was that the goal
>> names were still the same, which I think in the earlier mail we were
>> going to change?
>
> Exactly, but i wanted to first document. The complete refactor of the
> names implies the refactor in the doco.
np.
>
> So to summarise the needed actions:
> 1. backward compatibility of names
> 2. backward compatibility on old descriptor and downloading
> 3. backward compat on command line option (-D)
> 4. backward compat on behaviour (but the prompting is by default
> unless called with -B)
Yes - and all of these should be achievable by keeping the current
mojos, and wrapping them around the new components.
>
>> - Do you see people needing to create these descriptors often? It
>> seemed a lot of it could be discovered, maybe even annotated?
> As i saw the process of creating is:
> 1. create a project
> 2. call create from project goal (which creates a descriptor)
> 3. review the generated archetype
> 4. optionnaly change the descriptor and templates (even new templates)
> 5. store the archetype in SCM
> 6. deploy it
>
> This proposition is to permit templates in other groups than the
> currently defined in the archetypeng's one. I had a better one (at the
> end of this mail)
This sounds good. Adding annotations as a way to control the
descriptor to minimise (4) as a future step might be a good idea.
>
>> - would there be the possibility to use patterns a lot to describe
>> these, rather than individual files as is shown in this example?
>
> Have you an example ?
> an atempt:
> <template binary="true"
> include="**/*.png"/> <!--default to **/*-->
> <template exclude="**/*~"/> <!-- default to empty-->
That's the sort of thing I was thinking of, though the descriptor
should probably be structured around this sort of concept.
Consistency with the assembly plugin as a way to describe files might
be a good goal.
>
>> - I don't quite understand the purpose of first/second/third level
>> groups. Can you explain this some more?
> I changed it to other-group.
> The purpose is to provide a way to have template groups defined in
> directories not taken by wired groups.
This is sounding a little over-complicated, and I'm not sure how it
differs from the above if filesets are available. Do the groups
delineate anything other than the templates used and the path they
are used on?
From my limited understanding, it seems like the whole thing could
be replaced by:
<templates>
<template include="src/main/java/**" binary="false"
encoding="UTF-8" />
...
</templates>
Though I'm not sure template is even the best terminology here,
especially given the png example you gave earlier - these really
sound more like plain filesets, where some files are enabled for
velocity processing?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Hi
Answers inlined.
2007/3/23, Brett Porter <br...@apache.org>:
> Hi,
>
> Sorry for being sluggish :)
>
> On 21/03/2007, at 8:41 AM, Raphaël Piéroni wrote:
>
> > Hi,
> >
> > Do any one had the time to comment the sources and/or the first doco
> > http://mojo.codehaus.org/maven-archetypeng ?
>
> This looks very good. The only thing I noticed was that the goal
> names were still the same, which I think in the earlier mail we were
> going to change?
Exactly, but i wanted to first document. The complete refactor of the
names implies the refactor in the doco.
>
> BTW, as far as JIRA goes, I'd definitely use ARCHETYPE with a new
> version. Frankly, if you can make this backwards compat, I'd go with
> this as the basis for archetype 1.0.
>
> The way I'd see this moving forward:
> - get archetypeng to the point that you think it is a suitable drop
> in replacement for the current archetype stuff (ie, backwards
> compatible, as feature complete as the last release)
So to summarise the needed actions:
1. backward compatibility of names
2. backward compatibility on old descriptor and downloading
3. backward compat on command line option (-D)
4. backward compat on behaviour (but the prompting is by default
unless called with -B)
> - propose to move it into apache svn as a replacement for current
> (make sure any changes that might have been applied since you started
> don't need to be applied to yours too - though I think we've held off)
> - work towards 1.0-beta-1 release and use ARCHETYPE JIRA.
>
> >
> > Here is a proposition of refactored descriptor which attemps
> > to introduce: the use of attributes, the possibility to copy files,
> > and customised template groups (root, 1->3° level).
> >
> > Please feel free to comment this naive proposition.
> > Unless homogenous desire, i whould have dropped the 1° and 2°
> > levels templates.
>
> Looks sane to me, but I have some questions:
> - Do you see people needing to create these descriptors often? It
> seemed a lot of it could be discovered, maybe even annotated?
As i saw the process of creating is:
1. create a project
2. call create from project goal (which creates a descriptor)
3. review the generated archetype
4. optionnaly change the descriptor and templates (even new templates)
5. store the archetype in SCM
6. deploy it
This proposition is to permit templates in other groups than the
currently defined in the archetypeng's one. I had a better one (at the
end of this mail)
> - would there be the possibility to use patterns a lot to describe
> these, rather than individual files as is shown in this example?
Have you an example ?
an atempt:
<template binary="true"
include="**/*.png"/> <!--default to **/*-->
<template exclude="**/*~"/> <!-- default to empty-->
> - I don't quite understand the purpose of first/second/third level
> groups. Can you explain this some more?
I changed it to other-group.
The purpose is to provide a way to have template groups defined in
directories not taken by wired groups.
As an example templates defined in sources-groups must reside in
archetype-resources/src/main/<language-name> directory in the
archetype's jar and such templates are generated in
src/main/<language-name>/<package defined by -D>/ directory.
The template path is then added to those directories.
With other-groups you can define the starting path to . ./first-level
./first-level/second-level ./first-level/second-level/third-level as
desired. You can also choose to have package resolution or not.
Maybe a better way should be to leave the starting path in one property.
Here is a complete example:
<?xml version="1.0" encoding="UTF-8"?>
<archetype partial="true" ><!--default value is false-->
<name>Archetype Name</name>
<required-properties>
<required-property>
<key>propertyKey</key>
<default-value>Default value</default-value>
</required-property>
</required-properties>
<sources-groups>
<sources-group language="java" ><!--default value-->
<templates>
<template encoding="UTF-8" binary="false"><!--default values-->
<path>App.java</path>
</template>
</templates>
</sources-group>
</sources-groups>
<test-sources-groups>
<test-sources-group>
<templates>
<template>
<path>AppTest.java</path>
</template>
</templates>
</test-sources-group>
</test-sources-groups>
<resources-groups>
<resources-group directory="resources"><!--default value-->
<templates>
<template>
<path>app.properties</path>
</template>
</templates>
</resources-group>
</resources-groups>
<test-resources-groups>
<test-resources-group>
<templates>
<template>
<path>test/app.properties</path>
</template>
</templates>
</test-resources-group>
</test-resources-groups>
<site-group>
<templates>
<template>
<path>apt/index.apt</path>
</template>
</templates>
</site-group>
<other-groups>
<other-group>
<templates>
<template>
<path>.classpath</path>
</template>
</templates>
</other-group>
<other-group>
<first-level>project-repository</first-level>
<templates>
<template binary="true">
<path>com/company/project/1.0/project-1.0/project-1.0.jar</path>
</template>
</templates>
</other-group>
<other-group packaged="false" ><!--default value-->
<first-level>src</first-level>
<second-level>environment</second-level>
<templates>
<template>
<path>production.env.sh</path>
</template>
</templates>
</other-group>
<other-group packaged="true" >
<first-level>src</first-level>
<second-level>it</second-level>
<third-level>java</third-level>
<templates>
<template>
<path>AppITTest.java</path>
</template>
</templates>
</other-group>
</other-groups>
<projects>
<project>
<module>subproject-artifact-id</module>
</project>
<sources-groups/>
<test-sources-groups/>
<resources-groups/>
<test-resources-groups/>
<site-group/>
<other-groups/>
</projects>
</archetype>
I would like to settle this proposition before coding as it can be a
big amount of work to refactor.
>
> Thanks again!
>
> - Brett
It is pleasure to create something that seems usefull.
thanks for the audience :)
Raphaël
Re: [Archetypes] plugin proposition
Posted by Brett Porter <br...@apache.org>.
Hi,
Sorry for being sluggish :)
On 21/03/2007, at 8:41 AM, Raphaël Piéroni wrote:
> Hi,
>
> Do any one had the time to comment the sources and/or the first doco
> http://mojo.codehaus.org/maven-archetypeng ?
This looks very good. The only thing I noticed was that the goal
names were still the same, which I think in the earlier mail we were
going to change?
BTW, as far as JIRA goes, I'd definitely use ARCHETYPE with a new
version. Frankly, if you can make this backwards compat, I'd go with
this as the basis for archetype 1.0.
The way I'd see this moving forward:
- get archetypeng to the point that you think it is a suitable drop
in replacement for the current archetype stuff (ie, backwards
compatible, as feature complete as the last release)
- propose to move it into apache svn as a replacement for current
(make sure any changes that might have been applied since you started
don't need to be applied to yours too - though I think we've held off)
- work towards 1.0-beta-1 release and use ARCHETYPE JIRA.
>
> Here is a proposition of refactored descriptor which attemps
> to introduce: the use of attributes, the possibility to copy files,
> and customised template groups (root, 1->3° level).
>
> Please feel free to comment this naive proposition.
> Unless homogenous desire, i whould have dropped the 1° and 2°
> levels templates.
Looks sane to me, but I have some questions:
- Do you see people needing to create these descriptors often? It
seemed a lot of it could be discovered, maybe even annotated?
- would there be the possibility to use patterns a lot to describe
these, rather than individual files as is shown in this example?
- I don't quite understand the purpose of first/second/third level
groups. Can you explain this some more?
Thanks again!
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Hi,
Do any one had the time to comment the sources and/or the first doco
http://mojo.codehaus.org/maven-archetypeng ?
Here is a proposition of refactored descriptor which attemps
to introduce: the use of attributes, the possibility to copy files,
and customised template groups (root, 1->3° level).
Please feel free to comment this naive proposition.
Unless homogenous desire, i whould have dropped the 1° and 2° levels templates.
<?xml version="1.0" encoding="UTF-8"?>
<archetype partial="true" >
<name>Archetype Name</name>
<required-properties>
<required-property>
<key>propertyKey</key>
<default-value>Default value</default-value>
</required-property>
</required-properties>
<sources-groups>
<sources-group language="java" >
<templates>
<template encoding="UTF-8" binary="false">
<path>App.java</path>
</template>
</templates>
</sources-group>
</sources-groups>
<test-sources-groups>
<test-sources-group language="java" >
<templates>
<template encoding="UTF-8" binary="false">
<path>AppTest.java</path>
</template>
</templates>
</test-sources-group>
</test-sources-groups>
<resources-groups>
<resources-group directory="resources">
<templates>
<template encoding="UTF-8" binary="false">
<path>app.properties</path>
</template>
</templates>
</resources-group>
</resources-groups>
<test-resources-groups>
<test-resources-group directory="resources">
<templates>
<template encoding="UTF-8" binary="false">
<path>test(app.properties</path>
</template>
</templates>
</test-resources-group>
</test-resources-groups>
<site-group>
<templates>
<template encoding="UTF-8" binary="false">
<path>apt/index.apt</path>
</template>
</templates>
</site-group>
<root-group>
<templates>
<template encoding="UTF-8" binary="false">
<path>.classpath</path>
</template>
</templates>
</root-group>
<first-level-groups>
<first-level-group>
<first-level>project-repository</first-level>
<templates>
<template binary="true">
<path>com/company/project/1.0/project-1.0/project-1.0.jar</path>
</template>
</templates>
</first-level-group>
</first-level-groups>
<second-level-groups>
<second-level-group>
<first-level>src</first-level>
<second-level>environment</second-level>
<templates>
<template encoding="UTF-8" binary="false">
<path>production.env.sh</path>
</template>
</templates>
</second-level-group>
</second-level-groups>
<third-level-groups>
<third-level-group packaged="true" >
<first-level>src</first-level>
<second-level>it</second-level>
<third-level>java</third-level>
<templates>
<template encoding="UTF-8" binary="false">
<path>AppITTest.java</path>
</template>
</templates>
</third-level-group>
</third-level-groups>
<projects>
<project>
<module>project-artifact-id</module>
</project>
<sources-groups>
...
</sources-groups>
<test-sources-groups>
...
</test-sources-groups>
<resources-groups>
...
</resources-groups>
<test-resources-groups>
...
</test-resources-groups>
<site-group>
...
</site-group>
<root-group>
...
</root-group>
<first-level-groups>
...
</first-level-groups>
<second-level-groups>
...
</second-level-groups>
<third-level-groups>
...
</third-level-groups>
</projects>
</archetype>
Regards,
Raphaël
Re: [Archetypes] plugin proposition
Posted by Ole Ersoy <ol...@gmail.com>.
Awesome!
Incidentally does your plugin have the ability to evaluate the maven name
element when it processes the archetype templates?
There is a patch for the current archetype plugin here:
http://jira.codehaus.org/browse/ARCHETYPE-55
But if yours does it already, I'm skipping the patching and just using
yours :-)
Thanks,
- Ole
Raphaël Piéroni wrote:
> Hi,
>
> I added it on my todo list.
>
> Raphaël
>
> 2007/3/19, Ole Ersoy <ol...@gmail.com>:
>> Hi Raphael,
>>
>> Sounds like you are doing some terrific work.
>>
>> If you have time, could you please take a look at this bug:
>>
>> http://jira.codehaus.org/browse/MNG-2856
>>
>> When the current archetype plugin processes png images, it changes them,
>> and makes the unreadable.
>>
>> I think if we add a <binary> element (possibly contained in the
>> <resources> container element) to the archetype.xml descriptor,
>> which tells the plugin to just copy those resources, the issue gets
>> fixed.
>>
>> Cheers,
>> - Ole
>>
>>
>>
>> Raphaël Piéroni wrote:
>> > Hi all,
>> >
>> > Here is the resent of a mail i sent on dev@mojo.
>> >
>> > I would like to introduce the work i have done so far concerning
>> > archetypes.
>> > I have improved the current archetype mecanism by adding
>> > - the interactive selection of the archetype to create a project from
>> > - the interactive configuration of the archetype to create a
>> project from
>> > - the interactive configuration of the archetype created from a
>> project
>> >
>> > To acheive this i needed to refactor the archetype descriptor and
>> > workflow.
>> > I must admit having stole some code from current implementation :).
>> >
>> > You can checkout the sources in the mojo sandbox. Just beware when
>> > checking out the sources in Windows, the source tree is quite deep and
>> > breaks.
>> >
>> > I will be happy to have some feedback about it.
>> >
>> > The plugins comes with a little pack of archetypes.
>> > The core goals are :
>> > - generate: to generate a project from an archetype
>> > - create: to create an archetype from a project
>> >
>> > This first implementation have som limitations as the archetypes
>> are for
>> > now mono-project.
>> >
>> > I copy my current todo list for starting point to discuss about :
>> >
>> > - package mojo: to jar the created archetype
>> > - sample properties mojo: to provide a sample configuration file
>> for an
>> > archetype (which could be filled and used in batch mode)
>> > - descriptor with attributes: refactor the current archetype
>> > descriptor to
>> > use attributes instead of xml elements
>> > - generate multi project: to generate a project and its internal
>> modules
>> > from one archetype.
>> > - create multi project: to create one archetype from a project with
>> > modules
>> > - CRUD group mojo: mojos to change the archetype groups defined in the
>> > ~/.m2/archetypes.xml
>> > - Documentation: Document the workfow of user interaction, explain
>> the
>> > internal plexus components
>> > - integration tests and sibling: handle directories other than
>> src/main,
>> > src/test, src/site. a first case would be integration tests
>> > - 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
>> > - archetype group metadata: create a new group metadata for archetypes
>> > (same
>> > way as plugins metadata) therefore we could have a archetype
>> packaging.
>> > - velocity tools in templates: provide the official velocity tools
>> to be
>> > used by archetype creators
>> >
>> >
>> > The plugin don't have backward compatibility yet.
>> >
>> > Regards,
>> >
>> > Raphaël
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Archetypes] plugin proposition
Posted by Raphaël Piéroni <ra...@gmail.com>.
Hi,
I added it on my todo list.
Raphaël
2007/3/19, Ole Ersoy <ol...@gmail.com>:
> Hi Raphael,
>
> Sounds like you are doing some terrific work.
>
> If you have time, could you please take a look at this bug:
>
> http://jira.codehaus.org/browse/MNG-2856
>
> When the current archetype plugin processes png images, it changes them,
> and makes the unreadable.
>
> I think if we add a <binary> element (possibly contained in the
> <resources> container element) to the archetype.xml descriptor,
> which tells the plugin to just copy those resources, the issue gets fixed.
>
> Cheers,
> - Ole
>
>
>
> Raphaël Piéroni wrote:
> > Hi all,
> >
> > Here is the resent of a mail i sent on dev@mojo.
> >
> > I would like to introduce the work i have done so far concerning
> > archetypes.
> > I have improved the current archetype mecanism by adding
> > - the interactive selection of the archetype to create a project from
> > - the interactive configuration of the archetype to create a project from
> > - the interactive configuration of the archetype created from a project
> >
> > To acheive this i needed to refactor the archetype descriptor and
> > workflow.
> > I must admit having stole some code from current implementation :).
> >
> > You can checkout the sources in the mojo sandbox. Just beware when
> > checking out the sources in Windows, the source tree is quite deep and
> > breaks.
> >
> > I will be happy to have some feedback about it.
> >
> > The plugins comes with a little pack of archetypes.
> > The core goals are :
> > - generate: to generate a project from an archetype
> > - create: to create an archetype from a project
> >
> > This first implementation have som limitations as the archetypes are for
> > now mono-project.
> >
> > I copy my current todo list for starting point to discuss about :
> >
> > - package mojo: to jar the created archetype
> > - sample properties mojo: to provide a sample configuration file for an
> > archetype (which could be filled and used in batch mode)
> > - descriptor with attributes: refactor the current archetype
> > descriptor to
> > use attributes instead of xml elements
> > - generate multi project: to generate a project and its internal modules
> > from one archetype.
> > - create multi project: to create one archetype from a project with
> > modules
> > - CRUD group mojo: mojos to change the archetype groups defined in the
> > ~/.m2/archetypes.xml
> > - Documentation: Document the workfow of user interaction, explain the
> > internal plexus components
> > - integration tests and sibling: handle directories other than src/main,
> > src/test, src/site. a first case would be integration tests
> > - 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
> > - archetype group metadata: create a new group metadata for archetypes
> > (same
> > way as plugins metadata) therefore we could have a archetype packaging.
> > - velocity tools in templates: provide the official velocity tools to be
> > used by archetype creators
> >
> >
> > The plugin don't have backward compatibility yet.
> >
> > Regards,
> >
> > Raphaël
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [Archetypes] plugin proposition
Posted by Ole Ersoy <ol...@gmail.com>.
Hi Raphael,
Sounds like you are doing some terrific work.
If you have time, could you please take a look at this bug:
http://jira.codehaus.org/browse/MNG-2856
When the current archetype plugin processes png images, it changes them,
and makes the unreadable.
I think if we add a <binary> element (possibly contained in the
<resources> container element) to the archetype.xml descriptor,
which tells the plugin to just copy those resources, the issue gets fixed.
Cheers,
- Ole
Raphaël Piéroni wrote:
> Hi all,
>
> Here is the resent of a mail i sent on dev@mojo.
>
> I would like to introduce the work i have done so far concerning
> archetypes.
> I have improved the current archetype mecanism by adding
> - the interactive selection of the archetype to create a project from
> - the interactive configuration of the archetype to create a project from
> - the interactive configuration of the archetype created from a project
>
> To acheive this i needed to refactor the archetype descriptor and
> workflow.
> I must admit having stole some code from current implementation :).
>
> You can checkout the sources in the mojo sandbox. Just beware when
> checking out the sources in Windows, the source tree is quite deep and
> breaks.
>
> I will be happy to have some feedback about it.
>
> The plugins comes with a little pack of archetypes.
> The core goals are :
> - generate: to generate a project from an archetype
> - create: to create an archetype from a project
>
> This first implementation have som limitations as the archetypes are for
> now mono-project.
>
> I copy my current todo list for starting point to discuss about :
>
> - package mojo: to jar the created archetype
> - sample properties mojo: to provide a sample configuration file for an
> archetype (which could be filled and used in batch mode)
> - descriptor with attributes: refactor the current archetype
> descriptor to
> use attributes instead of xml elements
> - generate multi project: to generate a project and its internal modules
> from one archetype.
> - create multi project: to create one archetype from a project with
> modules
> - CRUD group mojo: mojos to change the archetype groups defined in the
> ~/.m2/archetypes.xml
> - Documentation: Document the workfow of user interaction, explain the
> internal plexus components
> - integration tests and sibling: handle directories other than src/main,
> src/test, src/site. a first case would be integration tests
> - 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
> - archetype group metadata: create a new group metadata for archetypes
> (same
> way as plugins metadata) therefore we could have a archetype packaging.
> - velocity tools in templates: provide the official velocity tools to be
> used by archetype creators
>
>
> The plugin don't have backward compatibility yet.
>
> Regards,
>
> Raphaël
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org