As I understand it; the current rule implements implicit URLs as
${parent.url}/${project.artifactId}
For example:
scm
connection${parentPOM.scm.connection}/${project.artifactId}/connection
...
/scm
Where parentPOM is a made-up symbol denoting an upward search for the
pom property that follows (scm.connection).
So, how about the following suggestion:
The Super POM contains this kind of definition for all URLs where this
rule applies today. When the effective POM
is computed for a sub-project it uses the closest url definition that
contains the symbol parentPOM. If none is
found expect the def in super pom, this one is used and the rule applies
as it always has.
On the other hand, if one decides to put an url expression containing
parentPOM into a POM of type 'pom',
then there is a new definition and will be used. That means, we have a
way to define how sub-project urls should
be constructed. I would be delighted if I could define an expression as
${parentPOM.scm.connection}/${project.name}/trunk
There is a residual problem, however: I cannot define both an url
expansion expression and an actual url expression
that is intended to be used in sub-projects. The easiest solution, is
just to have two organization poms, the top-most
pom contains the url expansion expressions (overriding the rule from the
super pom) and the one beneath is the
original org pom, containing actual urls that will be used in the
expansions further down.
I'm convinced there are other more elegant solutions. However, the
suggestion above would be fairly easy to implement
without breaking existing code and poms (or require a POM version
increment), but still provide a way for org-pom
designers to tweak the url expansions the way they want.
Comments / Objections ???
Cheers,
Jens
VUB Stefan Seidel skrev:
I agree, it is a bit too late to change this behaviour now. Maybe some
other suffix like $ or ${fixed} or you-name-it could be the cure. Then
all existing builds would continue to work and if someone would not
want the artifact id appended, they can add the special character.
Stefan
Brian E. Fox wrote:
The discussion in the issue revolves around the fact that changing this
behavior to as documented will break every build where there isn't a /
at the end. It's not apparent how to fix this without hosing tons of
unsuspecting users.
--Brian
-Original Message-
From: VUB Stefan Seidel [mailto:[EMAIL PROTECTED] Sent: Thursday,
February 21, 2008 6:03 AM
To: Maven Users List
Subject: Re: maven appends sub-project artifactId to urls - Please help
I added a comment to http://jira.codehaus.org/browse/MNG-3244.
You may want to add you votes. Apparently, it was originally planned
to not append the artifact id unless the URL would end with a /.
Stefan
Ben Lidgey wrote:
-Original Message-
From: VUB Stefan Seidel [mailto:[EMAIL PROTECTED]
Sent: 21 February 2008 09:52
To: Maven Users List
Subject: Re: maven appends sub-project artifactId to urls -
Please help
Hi Jens,
you are complaining about an essential feature of maven.
Having maven automatically extend the urls, scm urls, site
urls etc. with the list of parent artifact ids is crucial for
multi-module projects. No-one would want to enter this
information again and again through several levels of child
modules which are hosted within a common directory tree. I
agree that the docs are not clear about it, at least I
couldn't find it documented. I see your point, and there are
other problems, like when the directory name of a sub-module
is not equal to the artifact id, but in general it is an
important feature.
How to disable - I don't know. Maybe you will need to file
two things in
JIRA: a documentation request and a feature request to disable it.
HTH,
Stefan
We have a similar problem to Jens as our projects are structured in
Eclipse friendly structure, e.g.
ParentProject
- pom.xml
ChildProject1
- pom.xml
- src/java etc
ChildProject2
- pom.xml
- src/java etc
Which is different to the standard Maven dir structure, e.g.
ParentProject
- pom.xml
- ChildProject1
- pom.xml
- src/java etc
- ChildProject2
- pom.xml
- src/java etc
It would make sense to me to be able to specify a different naming
strategy, perhaps the Maven one is used as a default, but you could
define a different naming strategy and set that to be used instead, e.g.
scm namingStrategy=org.apache.maven.scm.FlatTreeNamingStrategy
...
/scm
That doesn't append artifactIds. Then if people had other weird and
whacky ways of structuring projects they could write custom naming
strategies to behave in accordance with their structures.
Ben
This e-mail is confidential and intended solely for the use of the
individual(s) to whom it is addressed. Any views or opinions expressed
are those of the author. If you are not the intended recipient, please
be advised that any use, dissemination, printing or copying of this
email is strictly prohibited.
