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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
