[
http://jira.codehaus.org/browse/ARCHETYPE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269881#action_269881
]
Stevo Slavic commented on ARCHETYPE-350:
----------------------------------------
Module's name in it's aggregator pom, and module directory name have to match.
Some plugins by default (if I recall well for links to work site plugin does)
additionally expect that module directory name matches module artifactId. So by
default, all 3 have to match.
Current archetype plugin (2.0) from archetype descriptor
(archetype-metadata.xml) uses module dir attribute for source directory name,
for module name in aggregator pom, and for destination directory within
aggregator module. It uses module id attribute only for artifactId variable.
IMO it should use module dir attribute only for the source directory name, and
use id attribute for module name in aggregator pom, for destination directory
name, and for artifactId variable.
I agree that module name attribute, if specified, should be used, instead of id
attribute value, as module name and destination directory name within
aggregator.
+1 for parameter (like rootArtifactId) expansion within module attributes of
archetype descriptor.
> Proposal for making (sub-)module handling more flexible with regards to
> folder names
> ------------------------------------------------------------------------------------
>
> Key: ARCHETYPE-350
> URL: http://jira.codehaus.org/browse/ARCHETYPE-350
> Project: Maven Archetype
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Marc Wirth
> Attachments: module_name.patch
>
>
> We have a use-case where we want modules to use the artifact ID of the parent
> as prefix, but the modules folder should only use the "suffix" to keep
> overall paths short (without becoming too redundant.)
> To make configuration more flexible I've changed the implementation so that
> the "name" of a module is used to define the output folder where the module
> is created and that it is run through velocity so that arbitrary properties
> can be defined. Please check the attached patch file.
> For example with this patch we could use a archetype-metadata definition
> like:
> {code}
> <requiredProperty key="subArtifactId">
> ...
> <module id="${rootArtifactId}.${subArtifactId}" dir="__rootArtifactId__.sub"
> name="${subArtifactId}">
> {code}
> to generate the module (from {{__rootArtifactId__.sub}} in the archetype-zip)
> into a folder that only consists of the module name, but having the
> rootArtifact ID plus the module name as its artifactId.
> I don't have a testcase specifically for this, but at least it doesn't break
> the existing fileset-archetype tests.
> While looking through the relevant code I've tried to clean up a few other
> oddities (artifactId is reset so log output would print a potentially wrong
> id, what looked like a mixup of replacements in Strings with ${x} or __x__
> delimiters to me).
> Also,
> http://maven.apache.org/archetype/maven-archetype-plugin/specification/archetype-metadata.html
> says "The attributes name, id and dir of the module are used to determine
> the directory where to generate that module's files, they also are used to
> determine the artifactId of the Maven project corresponding to this module."
> but actually the name attribute was never used during generation (only set
> during creation, same value as the id). To distinguish the source location
> within the archetype, i.e. the dir-attribute, from the destination I used the
> name attribute to define the output directory name.
> What do you think about that?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
