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.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to