[ 
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104030
 ] 

John Allen commented on MNG-2290:
---------------------------------

This is an issue that we've been living with for ages and continues to result 
in hassle and bugs (today: MNG-3134). 

> 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

        

Reply via email to