Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0.4
-
None
Description
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
- provider
- core
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.
Attachments
Issue Links
- is superceded by
-
MNG-3244 inherited site url not properly handling parameters
- Closed
- relates to
-
MNG-3134 DefaultModelInheritence::assembleDistributionInheritence should be childPathAdjustment aware
- Closed
- supercedes
-
MNG-2219 artifactId appended to URL in scm reports. Problem apparently comes from the core.
- Closed