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 <greg....@gmail.com> wrote: > Hi Lukas, > > On 2 July 2012 13:18, Lukas Theussl <ltheu...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
