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
