[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109277
]
Jay Sachs commented on MNG-2290:
--------------------------------
I feel that there is still room for a third type of project relationship. A
number of projects not sharing a release cycle, but hosted at the same
location, with regular and predictable URLs. Certainly it's not essential, but
having the variable interpolation instead of auto-append would make it easier
to adjust URLs for all these projects, handling SVN relocates, etc. This would
definitely be valuable to me.
> Generated URLs in POMs of child modules
> ---------------------------------------
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
> Affects Versions: 2.0.4
> Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> **** commons
> **** impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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
