On 3/31/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
