Site, deployment url and inheritance

[Grégory Joseph <gr...@gmail.com>]

Hi there,

I've seen this "topic" debated many times, and still haven't figured
everything out. I was recently confused by the handling and
inheritance of urls in Maven. I think I got most of it, when it comes
to project.url.

Now, when it comes to deploying a site, I'm baffled. Up to
maven-site-plugin 2.1.1, things seem to be fairly understandable. It
wasn't exactly possible (at least to my understanding) to have
multi-module projects sites deployed in a "versioned" directory
(because ${artifactId}/${version} would be re-interpolated for every
submodule). But at least, I could do a help:effective-pom, and get the
URLs that would be used for deployment.

Now I just tried 3.1, and I'm baffled that I can't seem to be able to
completely override the distributionManagement.site.url defined by my
parent pom. Using help:effective-pom gives me the URLs I expect, and
the ones i would like Maven to use when deploying the site. However,
the plugin seems to think differently, and tries to upload to
"relativised" urls, somehow inheriting the site url defined in a
corporate parent pom, adding some levels of "../" and finally the path
i'm expecting.

It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
was fixed. Example:
* Corporate parent pom defines this site deployment url:
prot://foo/${artifactId}/${version} -- it works for this pom, and it's
a good enough default for most of our single-module projects. Not the
lack of trailing slash, btw.
* Some multi-module project defines this site deployment url:
prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
end up looking like:
prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
don't know where the double slash comes from)

So unlike one of the latest comments in MSITE-600, I'm not even trying
to change the protocol. But it seems that either the wagon (i'm using
dav, if that's relevant), or the Nexus instance I have at the
receiving end, don't cope well with those "../".

Question is two fold:
* Why is the plugin even trying to do that ? Why is it not following
the same rules as effective-pom ? How can one "preview" what urls will
be used, then ?
* How do people really deploy sites with a version number in the path,
when using a "corporate" parent pom, without redefining the site.url
for every single project ?

Thanks for any hint or tip !

Cheers,
-greg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Site, deployment url and inheritance

[Grégory Joseph <gr...@gmail.com>]

On 2 July 2012 14:38, Lukas Theussl <lt...@apache.org> wrote:
> Grégory Joseph wrote:
>> Just tried staging, and indeed, the paths in that case are correct* -

I take it back. Staging was fine… with 2.1.1.
With 3.1 I get this, for example for last module of the multi-module build
[INFO] Pushing /project-root/moduleX/target/site
[INFO]    >>> to
file:///project-root/target/staging/../../<path-defined-by-parent-distrib.site.url>/<moduleX-artifactId>
… which is wrong, since that makes
<path-defined-by-parent-distrib.site.url> end up in the project root,
and not under target/staging/...

>> but again, I'm assuming that's because the normalization is done and
>> supported by my local FS ?
>
> IIRC normalization is done by the wagon you are using for the deploy, so
> it's outside the realm of the site plugin. I seem to remember that this
> was also the reason for adding a dot component /./ in the deployment url
> because some wagons only worked like that (I might be wrong though, it's
> been a while...).
>
> OTOH, I don't quite see what the problem is, a non-normalized url is
> still a valid url and every server/file system should be able to deal
> with it. Or do you have a specific actual issue that's caused by it?
> There have been issues reported (MSITE-531, MSITE-601) but in each case
> the underlying cause was outside maven/wagon/site-plugin.

Yes I do have an issue with that, that's why I'm here for ;) The "../"
isn't resolved properly, I'm assuming on the server side -- it seems
my Nexus instance just zaps it entirely, so "a/b/../../foo" ends up in
"a/b/foo".

Anyhow - I am currently re-testing all I can, and considering going
back to 2.1.1 - not sure what my problem was with it in the first
place, that I wanted to try the newer version :D

Cheers,

-g

>>
>> * with the strange bug that "https://nexus.domain.org/xyz" was
>> converted to targetstaging/http/s.domain.org/xyz ...
>
> that looks weird indeed, if you have a test case I will look at it.
>
> -Lukas
>
>>
>> On 2 July 2012 13:57, Grégory Joseph <gr...@gmail.com> wrote:
>>> Hi Lukas,
>>>
>>> On 2 July 2012 13:18, Lukas Theussl <lt...@apache.org> wrote:
>>>> Grégory Joseph wrote:
>>>>> It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
>>>>> was fixed. Example:
>>>>> * Corporate parent pom defines this site deployment url:
>>>>> prot://foo/${artifactId}/${version} -- it works for this pom, and it's
>>>>> a good enough default for most of our single-module projects. Not the
>>>>> lack of trailing slash, btw.
>>>>> * Some multi-module project defines this site deployment url:
>>>>> prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
>>>>> end up looking like:
>>>>> prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
>>>>> don't know where the double slash comes from)
>>>>
>>>> Normalizing this is exactly the same as
>>>> prot://foo/xuq/lolcats/${version},
>>>
>>> It *should* be, but by using those URLs as-is, Maven relies on the
>>> receiving end to do the normalization.
>>> And I'm still wondering why it bothers doing that in the first place ;)
>>>
>>>> so the deployment location should be
>>>> correct. Did you try site:stage to check?
>>>
>>> How is that helping ? I am not worried about inter-module links -
>>> those indeed seem to work - but about why the parent's urls are taken
>>> into account in the first place, and if there's a good reason for
>>> that, then I wonder why normalization doesn't happen on the Maven
>>> side.
>>>
>>> Cheers,
>>>
>>> -g
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Site, deployment url and inheritance

[Lukas Theussl <lt...@apache.org>]

Grégory Joseph wrote:
> Just tried staging, and indeed, the paths in that case are correct* -
> but again, I'm assuming that's because the normalization is done and
> supported by my local FS ?

IIRC normalization is done by the wagon you are using for the deploy, so
it's outside the realm of the site plugin. I seem to remember that this
was also the reason for adding a dot component /./ in the deployment url
because some wagons only worked like that (I might be wrong though, it's
been a while...).

OTOH, I don't quite see what the problem is, a non-normalized url is
still a valid url and every server/file system should be able to deal
with it. Or do you have a specific actual issue that's caused by it?
There have been issues reported (MSITE-531, MSITE-601) but in each case
the underlying cause was outside maven/wagon/site-plugin.

> 
> -g
> 
> * with the strange bug that "https://nexus.domain.org/xyz" was
> converted to targetstaging/http/s.domain.org/xyz ...

that looks weird indeed, if you have a test case I will look at it.

-Lukas

> 
> On 2 July 2012 13:57, Grégory Joseph <gr...@gmail.com> wrote:
>> Hi Lukas,
>>
>> On 2 July 2012 13:18, Lukas Theussl <lt...@apache.org> wrote:
>>> Grégory Joseph wrote:
>>>> It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
>>>> was fixed. Example:
>>>> * Corporate parent pom defines this site deployment url:
>>>> prot://foo/${artifactId}/${version} -- it works for this pom, and it's
>>>> a good enough default for most of our single-module projects. Not the
>>>> lack of trailing slash, btw.
>>>> * Some multi-module project defines this site deployment url:
>>>> prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
>>>> end up looking like:
>>>> prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
>>>> don't know where the double slash comes from)
>>>
>>> Normalizing this is exactly the same as
>>> prot://foo/xuq/lolcats/${version},
>>
>> It *should* be, but by using those URLs as-is, Maven relies on the
>> receiving end to do the normalization.
>> And I'm still wondering why it bothers doing that in the first place ;)
>>
>>> so the deployment location should be
>>> correct. Did you try site:stage to check?
>>
>> How is that helping ? I am not worried about inter-module links -
>> those indeed seem to work - but about why the parent's urls are taken
>> into account in the first place, and if there's a good reason for
>> that, then I wonder why normalization doesn't happen on the Maven
>> side.
>>
>> Cheers,
>>
>> -g
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Site, deployment url and inheritance

[Grégory Joseph <gr...@gmail.com>]

Just tried staging, and indeed, the paths in that case are correct* -
but again, I'm assuming that's because the normalization is done and
supported by my local FS ?

-g

* with the strange bug that "https://nexus.domain.org/xyz" was
converted to targetstaging/http/s.domain.org/xyz ...

On 2 July 2012 13:57, Grégory Joseph <gr...@gmail.com> wrote:
> Hi Lukas,
>
> On 2 July 2012 13:18, Lukas Theussl <lt...@apache.org> wrote:
>> Grégory Joseph wrote:
>>> It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
>>> was fixed. Example:
>>> * Corporate parent pom defines this site deployment url:
>>> prot://foo/${artifactId}/${version} -- it works for this pom, and it's
>>> a good enough default for most of our single-module projects. Not the
>>> lack of trailing slash, btw.
>>> * Some multi-module project defines this site deployment url:
>>> prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
>>> end up looking like:
>>> prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
>>> don't know where the double slash comes from)
>>
>> Normalizing this is exactly the same as
>> prot://foo/xuq/lolcats/${version},
>
> It *should* be, but by using those URLs as-is, Maven relies on the
> receiving end to do the normalization.
> And I'm still wondering why it bothers doing that in the first place ;)
>
>> so the deployment location should be
>> correct. Did you try site:stage to check?
>
> How is that helping ? I am not worried about inter-module links -
> those indeed seem to work - but about why the parent's urls are taken
> into account in the first place, and if there's a good reason for
> that, then I wonder why normalization doesn't happen on the Maven
> side.
>
> Cheers,
>
> -g

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Site, deployment url and inheritance

[Grégory Joseph <gr...@gmail.com>]

Hi Lukas,

On 2 July 2012 13:18, Lukas Theussl <lt...@apache.org> wrote:
> Grégory Joseph wrote:
>> It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
>> was fixed. Example:
>> * Corporate parent pom defines this site deployment url:
>> prot://foo/${artifactId}/${version} -- it works for this pom, and it's
>> a good enough default for most of our single-module projects. Not the
>> lack of trailing slash, btw.
>> * Some multi-module project defines this site deployment url:
>> prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
>> end up looking like:
>> prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
>> don't know where the double slash comes from)
>
> Normalizing this is exactly the same as
> prot://foo/xuq/lolcats/${version},

It *should* be, but by using those URLs as-is, Maven relies on the
receiving end to do the normalization.
And I'm still wondering why it bothers doing that in the first place ;)

> so the deployment location should be
> correct. Did you try site:stage to check?

How is that helping ? I am not worried about inter-module links -
those indeed seem to work - but about why the parent's urls are taken
into account in the first place, and if there's a good reason for
that, then I wonder why normalization doesn't happen on the Maven
side.

Cheers,

-g

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Site, deployment url and inheritance

[Lukas Theussl <lt...@apache.org>]

Grégory Joseph wrote:
> Hi there,
> 
> I've seen this "topic" debated many times, and still haven't figured
> everything out. I was recently confused by the handling and
> inheritance of urls in Maven. I think I got most of it, when it comes
> to project.url.
> 
> Now, when it comes to deploying a site, I'm baffled. Up to
> maven-site-plugin 2.1.1, things seem to be fairly understandable. It
> wasn't exactly possible (at least to my understanding) to have
> multi-module projects sites deployed in a "versioned" directory
> (because ${artifactId}/${version} would be re-interpolated for every
> submodule). But at least, I could do a help:effective-pom, and get the
> URLs that would be used for deployment.
> 
> Now I just tried 3.1, and I'm baffled that I can't seem to be able to
> completely override the distributionManagement.site.url defined by my
> parent pom. Using help:effective-pom gives me the URLs I expect, and
> the ones i would like Maven to use when deploying the site. However,
> the plugin seems to think differently, and tries to upload to
> "relativised" urls, somehow inheriting the site url defined in a
> corporate parent pom, adding some levels of "../" and finally the path
> i'm expecting.
> 
> It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
> was fixed. Example:
> * Corporate parent pom defines this site deployment url:
> prot://foo/${artifactId}/${version} -- it works for this pom, and it's
> a good enough default for most of our single-module projects. Not the
> lack of trailing slash, btw.
> * Some multi-module project defines this site deployment url:
> prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
> end up looking like:
> prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
> don't know where the double slash comes from)

Normalizing this is exactly the same as
prot://foo/xuq/lolcats/${version}, so the deployment location should be
correct. Did you try site:stage to check?

-Lukas

> 
> So unlike one of the latest comments in MSITE-600, I'm not even trying
> to change the protocol. But it seems that either the wagon (i'm using
> dav, if that's relevant), or the Nexus instance I have at the
> receiving end, don't cope well with those "../".
> 
> Question is two fold:
> * Why is the plugin even trying to do that ? Why is it not following
> the same rules as effective-pom ? How can one "preview" what urls will
> be used, then ?
> * How do people really deploy sites with a version number in the path,
> when using a "corporate" parent pom, without redefining the site.url
> for every single project ?
> 
> Thanks for any hint or tip !
> 
> Cheers,
> -greg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org