On 2 July 2012 14:38, Lukas Theussl <[email protected]> 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 <[email protected]> wrote: >>> Hi Lukas, >>> >>> On 2 July 2012 13:18, Lukas Theussl <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > 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]
