maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Bentmann" <>
Subject Re: Comments / Ideas for MNG-3244
Date Mon, 03 Mar 2008 18:17:00 GMT
> [...] as documented says that only urls ending in / will be inherited in
> the normal way by appending the artifactid to the end of the url.

The docs at [0] got updated to say the artifact id will always be appended,
regardless of a trailing slash or not. Are there any other docs handing
around from which people might be fooled?

Also note that this unconditional appending of the artifact id seems to be
in sync with the handling of ${project.url}. Any changes to the inheritance
should be applied to both of these URLs as they are usually related to one

> My only thought is to use some other identifier at the end of the url to
> indicate NOT to prepend the artifact and to strip the indicator.

I voted on this issue by myself but I believe such an approach would be an
ugly hack. You require people to mess up their URLs. Furthermore, this
approach would be a rather obscure/proprietary URL handling. If simplicity
is on your charter, this seems like the wrong way since people would need to
read the small print before understanding this Maven speciality. The POM
element is called *url, so people will expect it to take a URL, nothing 

Another question: How would the special don't-append-marker behave in
context of multiple parent POMs? I'm not fully familar with the project
builder but wouldn't the following sequence apply:
- grandfather POM defines "url/##"
- parent POM inherits "url/##" and fixes it to "url/"
- child POM inherits "url/" and fixes it to "url/artifact-id"
Would that be intended/intuitive?

> Naturally in 2.1 we need to fix this in a better way

I might be missing a point but is there *really* need to fix the issue for
2.0.x without some helping POM addition? I mean, users (including me) can
simply specify the proper/desired URLs in each and every POM and the site
deployment is fine. Sure, this might not a convenient approach but
convenience raises no urgency for not-so-lovely approaches, IMHO.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message