Dennis Lundberg wrote:
On 2011-03-14 20:28, Lukas Theussl wrote:
Dennis Lundberg wrote:
On 2011-03-13 22:38, Lukas Theussl wrote:
Dennis Lundberg wrote:
Hi
I've tracked it down to the new URIPathDescriptor class in
doxia-decoration-model.
Here are some debug output from a simple test:
base=file:///C:/Foo/
link=bar
uriPathDescriptor.getBaseURI()=file:///C:/Foo/
uriPathDescriptor.getBaseURI().normalize()=file:///C:/Foo/
uriPathDescriptor.getBaseURI().resolve(link)=file:/C:/Foo/bar
uriPathDescriptor.toString()=file:/C:/Foo/bar
As you can see resolve() and toString() (which calls the former)
doesn't
quite return what you'd expect, at least not what I expect. They strip
two slashes // from the input, rendering an invalid URI.
The test cases for the class have tests for this, but they expect the
file URI:s to have only a single slash after the first colon, like
this one
compare = new URIPathDescriptor( "file:///C:\\Foo\\bar1",
"" );
assertEquals( "file:/C:/Foo/bar1/", compare.toString() );
I think this is wrong, but perhaps Lukas can shed some light on it. In
my mind this should return "file:///C:/Foo/bar1/".
You are right, that's what I would expect as well, but apparently that's
the behavior of the resolve(link) method in java.net.URI [1]. Anyway, I
would like to understand how this affects the problem we see in the site
plugin, are you saying that these tests should fail on windows? They are
fine on jenkins [2].
It is the IT for plugins on Windows that are failing on the grid. I
can't find a similar setup in Jenkins. I'll see if I can set it up
later on.
As long as ass links are handled (resolved) in the same way by the new
class, we should be OK.
Here's what I think is happening. Somewhere the file URI:s are not
correctly "rebased" or "resolved", or maybe not handled at all. We end
up with one URI with the double slashes and one without them. When they
are compared for relativity, they are not relative to each other and
that results in an absolute link.
This happens in the IT site-inheritance in the Site Plugin, in the
module child_and_module. This has a 5 directory large difference to its
parent. The problematic links are breadcrumbs and links that are
inherited from the parent. But they cannot be relativized so they end up
being absolute links. They look like this on my machine:
<a
href="file://G/apache/maven/trunks/plugins/maven-site-plugin/target/it/site-inheritance/webhost.company.com/deploy/index.html"
class="externalLink" title="breadcrumbs /Parent">breadcrumbs /Parent</a>
<a
href="file://G/apache/maven/trunks/plugins/maven-site-plugin/target/it/site-inheritance/webhost.company.com/deploy/index.html"
class="externalLink" title="links /Parent">links /Parent</a>
I notice that they are missing a colon after "file://G" where G is my
drive letter. Perhaps this is the real root of the problem.
If I look at the content of the assembled model, the links are also
missing the colon character.
The problem is that there are only two leading slashes, there should be
either one or three, but not two.
Yes, I saw that too, and have tried and to fix this by adding
appropriate extra slashes (to make three of them). Unfortunately it
didn't help.
The link looks like this then:
<a
href="file:/G:/apache/maven/trunks/plugins/maven-site-plugin/target/it/site-inheritance/webhost.company.com/deploy/index.html"
class="externalLink" title="breadcrumbs /Parent">breadcrumbs /Parent</a>
With two slashes the G: is interpreted
as the authority component of the URI in the form
[user-info@]host[:port]
and if there is no port the colon is removed as redundant. So the
question is why there are only two slashes.
That's because the ITs are set up that way. Here's one example from that IT:
<distributionManagement>
<site>
<id>website</id>
<url>file://@project.build.directory@/it/site-inheritance/webhost.company.com/deploy/</url>
</site>
</distributionManagement>
On my Windows machine project.build.directory is
G:\apache\maven\trunks\plugins\maven-site-plugin\target
making the effective distributionManagement.site.url
file://G:/apache/maven/trunks/plugins/maven-site-plugin/target/it/site-inheritance/webhost.company.com/deploy/
However, changing it to
<url>file:///@project.build.directory@/it/site-inheritance/webhost.company.com/deploy/</url>
would most likely fail on any *nix, because it'd then have four slashes.
I added another slash and this works for me on unix, and it should also
fix the issue on windows according to your comments above. I had now the
opportunity to run the build on a friend's windows machine, but get a
different error: the @project.build.directory@ in my case is
"file:///C:/Documents and Settings/ltheussl..." which gives a
URISyntaxException because of the spaces. I think this is correct
because the user is supposed to enter a valid URI, so I don't want to
work around that in the code. So the question is if
@project.build.directory@ can be URL-encoded somehow before being
injected, or maybe just find another absolute location that works on all
platforms?
I think that we didn't see these problems before, because our own
previous URI parsing was more forgiving than the new one using the URI
class. But that's just my guess.
I have just added some more
tests [1] (note my comments in there) to check just for that but
everything passes on jenkins on windows and ubuntu...
Do we have Jenkins running maven-site-plugin with ITs on Windows?
Olivier added the site-plugin-3.x on jenkins but as a maven project,
instead of a multi-configuration project, I will ask him if we can
re-configure it.
Cheers,
-Lukas
-Lukas
[1] http://svn.apache.org/viewvc?rev=1081421&view=rev
I've created a unit test for in in doxia-document-renderer, but can't
get it to fail :-(
Thanks for looking into it!
-Lukas
[1]
http://download.oracle.com/javase/6/docs/api/java/net/URI.html#resolve(java.net.URI)
[2]
https://builds.apache.org/hudson/view/M-R/view/Maven/job/Maven-Doxia-Sitetools/
On 2011-03-12 13:17, Dennis Lundberg wrote:
I figured it was a Windows issue since you hadn't caught it before.
Thanks for the hint. I'll do some more testing to see if I can
track it
down.
On 2011-03-12 11:12, Lukas Theussl wrote:
all it's pass for me locally on branch and trunk, but I can't test on
windows. if it's a relative link issue, it should be caused by
DefaultDecorationModelInheritanceAssembler, where the link
relitivization is done (method resolvePaths()).
HTH,
-Lukas
Dennis Lundberg wrote:
Hi
The failing IT was merged from trunk in r1078835 [1], together with
the
its MSITE-159, MSITE-322, MSITE-537, site-stage-deploy.
I get the same failure on trunk locally on my Windows machine.
[1]
http://svn.apache.org/viewvc?limit_changes=0&view=revision&revision=1078835
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
