[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103820
]
William Ferguson edited comment on MNG-2290 at 8/1/07 6:34 PM:
---------------------------------------------------------------
I realise I wasn't as clear in my comment above as I could have been. So I'll
try again.
I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my
components.
I imagine the structure for the web site to look something like :
/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0
etc
I also want to keep my POMs as clear and simple as possible, so I try and put
as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url
specified in the parent (and not overridden in the child) will automatically
have the artifactId of the child appended to them. So there is no way to
achieve the folder structure specified above using any kind of url statement in
the parent POM.
I think Maven needs to *stop* automatically appending ${artifactId} to the url
and site#url of the parent POM and instead encourage specification use of the
actual url that is required, eg
http://myhost/maven-projects/${artifactId}/${version}
or whatever is required.
Now I believe versioned sites is something that the Maven group as a whole was
planning on doing themselves, so this looks like an area that needs to be
resolved.
was:
I realise I wasn't as clear in my comment above as I could have been. So I'll
try again.
I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my
components.
I imgaine the structure for the web site to look something like :
/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0
etc
I also want to keep my POMs as clear and simple as possible, so I try and put
as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url
specified in the parent (and not overridden in the child) will automatically
have the artifactId of the child appended to them. So there is no way to
achieve the folder structure specified above using any kind of url statement in
the parent POM.
I think Maven needs to *stop* automatically appending ${artifactId} to the url
and site#url of the parent POM and instead encourage specification use of the
actual url that is required, eh
http://myhost/maven-projects/${artifactId}/${version} or whatever is required.
Now I believe versioned sites is something that the Maven group as a whole was
planning on doing themselves, so this looks like an area that needs to be
resolved.
> 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
