On 31 Mar 07, at 12:08 PM 31 Mar 07, Heinrich Nirschl wrote:
On 3/31/07, Jason van Zyl <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
