Hi
Answers inlined.
2007/3/23, Brett Porter <[EMAIL PROTECTED]>:
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
