Comments / Ideas for MNG-3244

[Brian E Fox]

MNG-3244 is one of the most popular issues in the queue for 2.0.9 (was
also in 2.0.8 but got bumped). The issue is that url inheritance 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
trouble is that fixing it this way is going to break tons of builds (I
know because I tried the patch and then lots of stuff broke and had to
revert it). So clearly / won't work as an indicator. Doing nothing is
also not going to work.

 

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.
Something like:

 

url-blahblah// or url-blahblah/## becomes url-blahblah.

 

Naturally in 2.1 we need to fix this in a better way, probably with a
flag in the pom and we would deprecate this behavior immediately.
Comments or other ideas?

[Benjamin Bentmann]

> [...] 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
other.

> 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
else.

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.


Benjamin


[0] http://maven.apache.org/guides/mini/guide-site.html


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian E Fox]

>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?

Probably not, but we changed the docs because of this issue.

>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
>other.

Yes, this applies to all urls

>> 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

>else.

I agree it's not the greatest. But I see it quite often being an issue
in practice and the users talk about it a lot. The benefit to this
approach is it leaves alone the urls for people who want/expect the
current behavior. Only those looking to work around it would need to use
this (and seek out the answer)

>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?

So normally you would get: url/parent/child. Here you should get
/url/artifact-id because it was declared in the child. If you omitted
the url in the child you would get /url/ (people do this because url
contains a property already )

>> 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.

It's not a sense of urgency really, it's that if we decide not to fix it
in 2.0.x, it probably means close to a year before 2.1 could be in full
production in most places.

It doesn't affect me, but I am trying to come to a conclusion now rather
than kick this forward another release.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

> >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?
>
> So normally you would get: url/parent/child. Here you should get
> /url/artifact-id because it was declared in the child. If you omitted
> the url in the child you would get /url/ (people do this because url
> contains a property already )

I couldn't follow your reasoning: How would the child know that its URL
should be "url/" when
a) it omitted the URL in its POM for the sake of inheritance from parent
b) the URL of parent was resolved to "url/" via inheritance from grandfather

As I understand your proposal, the don't-append-marker would vanish after
the first inheritance step, re-enabling the default behavior for all
descendant POMs?


Benjamin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian E Fox]

>As I understand your proposal, the don't-append-marker would vanish
after
>the first inheritance step, re-enabling the default behavior for all
>descendant POMs?

You're right, it probably won't work that way. I was thinking the
behavior info would be available throughout the inheritance process, but
removed after...but then you couldn't inherit from a deployed pom.

I'm not convinced adding a flag to the pom will help because we have so
many different urls (site, scm, distro) and I don't think a global
switch for all of them is what people want.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 04/03/2008, at 6:22 AM, Brian E. Fox wrote:

>
>> As I understand your proposal, the don't-append-marker would vanish
> after
>> the first inheritance step, re-enabling the default behavior for all
>> descendant POMs?
>
> You're right, it probably won't work that way. I was thinking the
> behavior info would be available throughout the inheritance process,  
> but
> removed after...but then you couldn't inherit from a deployed pom.

It's ugly, but there is a workaround for this now in respecifying the  
URLs in the child POMs. It's a pain but it's not the end of the world  
and I'd say better than adding even more voodoo.

I'd also like to take the time to apologise for adding this behaviour,  
it seemed like a good idea at the time...

> I'm not convinced adding a flag to the pom will help because we have  
> so
> many different urls (site, scm, distro) and I don't think a global
> switch for all of them is what people want.


In the attributes branch we have different model readers for different  
versions and can presumably have different semantics as people update  
through the versions. I would say that's the best way to go - keep  
behaving the same way as now for 4.0.0 POMs, and come up with a better  
solution for people that choose to use 4.1.0 POMs (once they are in  
place).

My 2c.

Cheers,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jallen]

Don't forget what I learnt from Lukas Theussl regarding DOXIASITETOOLS-9, specifically the fact that URLs *should* have trailing slashes when referring to a 'directory':-  

lukas theussl wrote:

This behavior is correct according to the rfc specs: http://www.ietf.org/rfc/rfc2396.txt (see eg the example given in App D).

If you want the "1" to be interpreted as a hierarchical component (ie as a directory on a filesystem), you need to append a slash in the end:

PathDescriptor( new URL( http://www.foo.com/foo/bar/1/ ), "../../images/banner-lhs.png" )

which is a recommended practice for web URLs anyway, see eg http://www.standardzilla.com/2007/07/09/dont-forget-your-trailing-slash/


RFC 2396, "5.2. Resolving Relative References to Absolute Form"

    6) If this step is reached, then we are resolving a relative-path
    reference. The relative path needs to be merged with the base
    URI's path. Although there are many ways to do this, we will
    describe a simple method using a separate string buffer.

    a) All but the last segment of the base URI's path component is
    copied to the buffer. In other words, any characters after the
    last (right-most) slash character, if any, are excluded.

On 04/03/2008, at 6:22 AM, Brian E. Fox wrote:

>
>> As I understand your proposal, the don't-append-marker would vanish
> after
>> the first inheritance step, re-enabling the default behavior for all
>> descendant POMs?
>
> You're right, it probably won't work that way. I was thinking the
> behavior info would be available throughout the inheritance process,  
> but
> removed after...but then you couldn't inherit from a deployed pom.

It's ugly, but there is a workaround for this now in respecifying the  
URLs in the child POMs. It's a pain but it's not the end of the world  
and I'd say better than adding even more voodoo.

I'd also like to take the time to apologise for adding this behaviour,  
it seemed like a good idea at the time...

> I'm not convinced adding a flag to the pom will help because we have  
> so
> many different urls (site, scm, distro) and I don't think a global
> switch for all of them is what people want.


In the attributes branch we have different model readers for different  
versions and can presumably have different semantics as people update  
through the versions. I would say that's the best way to go - keep  
behaving the same way as now for 4.0.0 POMs, and come up with a better  
solution for people that choose to use 4.1.0 POMs (once they are in  
place).

My 2c.

Cheers,
Brett

--
Brett Porter
[e-mail]
http://blogs.exist.com/bporter/


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

[Brian E Fox]

>It's ugly, but there is a workaround for this now in respecifying the  
>URLs in the child POMs. It's a pain but it's not the end of the world  
>and I'd say better than adding even more voodoo.

Most people would say this isn't an acceptable workaround.

>I would say that's the best way to go - keep  
>behaving the same way as now for 4.0.0 POMs, and come up with a better

>solution for people that choose to use 4.1.0 POMs (once they are in  
>place).

I'm leaning this way but I was hoping we could find some solution. It is
a popular issue and I'd hate to just punt it. Anyone else have a
suggestion?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Paul Benedict-2]

I find it strange that software would react differently simply because
someone upgraded the POM version. It should act differently if a different
setting is specified.

My recommendation is:
1) Solve it the correct way. Change the plugin/component to generate the
paths in the fashion intended. Allow a configuration setting to revert
behavior.
2) In the superpom, default to the new plugin/component version.
3) If corporations want the old behavior, they can override it in their
corporate pom.

Paul

On Fri, Mar 7, 2008 at 3:30 PM, Brian E. Fox <brianf@...>
wrote:

>
> >It's ugly, but there is a workaround for this now in respecifying the
> >URLs in the child POMs. It's a pain but it's not the end of the world
> >and I'd say better than adding even more voodoo.
>
> Most people would say this isn't an acceptable workaround.
>
> >I would say that's the best way to go - keep
> >behaving the same way as now for 4.0.0 POMs, and come up with a better
>
> >solution for people that choose to use 4.1.0 POMs (once they are in
> >place).
>
> I'm leaning this way but I was hoping we could find some solution. It is
> a popular issue and I'd hate to just punt it. Anyone else have a
> suggestion?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Brian E Fox]

Paul,
These suggestions mean it gets bumped to 2.1

-----Original Message-----
From: paulus.benedictus@... [mailto:paulus.benedictus@...]
On Behalf Of Paul Benedict
Sent: Friday, March 07, 2008 10:34 PM
To: Maven Developers List
Subject: Re: Comments / Ideas for MNG-3244

I find it strange that software would react differently simply because
someone upgraded the POM version. It should act differently if a
different
setting is specified.

My recommendation is:
1) Solve it the correct way. Change the plugin/component to generate the
paths in the fashion intended. Allow a configuration setting to revert
behavior.
2) In the superpom, default to the new plugin/component version.
3) If corporations want the old behavior, they can override it in their
corporate pom.

Paul

On Fri, Mar 7, 2008 at 3:30 PM, Brian E. Fox <brianf@...>
wrote:

>
> >It's ugly, but there is a workaround for this now in respecifying the
> >URLs in the child POMs. It's a pain but it's not the end of the world
> >and I'd say better than adding even more voodoo.
>
> Most people would say this isn't an acceptable workaround.
>
> >I would say that's the best way to go - keep
> >behaving the same way as now for 4.0.0 POMs, and come up with a
better
>
> >solution for people that choose to use 4.1.0 POMs (once they are in
> >place).
>
> I'm leaning this way but I was hoping we could find some solution. It
is
> a popular issue and I'd hate to just punt it. Anyone else have a
> suggestion?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Paul Benedict-2]

Why does the configuration option require a bump in version? If behavior can
be retrograded, it is a perfect fit for 2.0.x as well. Sorry I don't
understand better.

Paul


On Fri, Mar 7, 2008 at 9:35 PM, Brian E. Fox <brianf@...>
wrote:

> Paul,
> These suggestions mean it gets bumped to 2.1
>
> -----Original Message-----
> From: paulus.benedictus@... [mailto:paulus.benedictus@...]
> On Behalf Of Paul Benedict
> Sent: Friday, March 07, 2008 10:34 PM
> To: Maven Developers List
> Subject: Re: Comments / Ideas for MNG-3244
>
> I find it strange that software would react differently simply because
> someone upgraded the POM version. It should act differently if a
> different
> setting is specified.
>
> My recommendation is:
> 1) Solve it the correct way. Change the plugin/component to generate the
> paths in the fashion intended. Allow a configuration setting to revert
> behavior.
> 2) In the superpom, default to the new plugin/component version.
> 3) If corporations want the old behavior, they can override it in their
> corporate pom.
>
> Paul
>
> On Fri, Mar 7, 2008 at 3:30 PM, Brian E. Fox <brianf@...>
> wrote:
>
> >
> > >It's ugly, but there is a workaround for this now in respecifying the
> > >URLs in the child POMs. It's a pain but it's not the end of the world
> > >and I'd say better than adding even more voodoo.
> >
> > Most people would say this isn't an acceptable workaround.
> >
> > >I would say that's the best way to go - keep
> > >behaving the same way as now for 4.0.0 POMs, and come up with a
> better
> >
> > >solution for people that choose to use 4.1.0 POMs (once they are in
> > >place).
> >
> > I'm leaning this way but I was hoping we could find some solution. It
> is
> > a popular issue and I'd hate to just punt it. Anyone else have a
> > suggestion?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Benjamin Bentmann]

> Why does the configuration option require a bump in version?

The primary place for configurations regarding the build is the POM. A
new option means a change to the POM schema, a new schema means to bump the
version.

> it is a perfect fit for 2.0.x as well.

Besides, you proposed to break the current behavior by defaulting to "the
correct way" (btw, "correct" appears to be wrong term here, it's merely a
matter of supporting different use cases equally easy). Breaking changes
should not happen for a maintenance release like Maven 2.0.x.


Benjamin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Paul Benedict-2]

I think I've been misunderstood. I am referring to the <configuration>
element that can contain whatever is necessary for configuration. If the
site is generated through a plugin, then by all means, configure the plugin.
See my first response.

Paul

On Sat, Mar 8, 2008 at 3:05 AM, Benjamin Bentmann <benjamin.bentmann@...>
wrote:

> > Why does the configuration option require a bump in version?
>
> The primary place for configurations regarding the build is the POM. A
> new option means a change to the POM schema, a new schema means to bump
> the
> version.
>
> > it is a perfect fit for 2.0.x as well.
>
> Besides, you proposed to break the current behavior by defaulting to "the
> correct way" (btw, "correct" appears to be wrong term here, it's merely a
> matter of supporting different use cases equally easy). Breaking changes
> should not happen for a maintenance release like Maven 2.0.x.
>
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Benjamin Bentmann]

> I think I've been misunderstood. I am referring to the <configuration>
> element that can contain whatever is necessary for configuration.

Oh, I see, but...

> If the site is generated through a plugin, then by all means, configure
> the plugin.

... this issue is about site deployment, not site generation. And the URLs
controlling site deployment are subject to the ModelInheritanceAssembler. I
mean, once the build gets to the Site Plugin it's too late because the
plugin cannot distinguish whether a URL was specified explicitly by the user
or implicitly via Maven. This is not about fixing the Site Plugin, it's a
core thing.


Benjamin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...