PathDescriptor fails to create proper absolute paths from relative components,
as expected by DefaultDecorationModelInheritanceAssembler.convertPaths
-----------------------------------------------------------------------------------------------------------------------------------------------------
Key: DOXIASITETOOLS-9
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-9
Project: Maven Doxia Site Tools
Issue Type: Bug
Affects Versions: 1.0-alpha-10
Environment: 2.0.8
Reporter: John Allen
PathDescriptor is either incorrectly implemented for handling the building of
URLs from relativePaths.
A call to
{code}
PathDescriptor( new URL(
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
), "../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png" )
{code}
And you boil down to this call
{code}
private static final URL buildUrl( final URL baseUrl, final String path )
throws MalformedURLException
{
if ( baseUrl == null )
{
throw new MalformedURLException( "Base is null!" );
}
if ( path == null )
{
return baseUrl;
}
if ( baseUrl.getProtocol().equals( "file" ) )
{
return new File( baseUrl.getFile(), path ).toURL();
}
if ( path.startsWith( "/" ) && baseUrl.getPath().endsWith( "/" ) )
{
return new URL( baseUrl, path.substring( 1 ) );
}
return new URL( baseUrl, path );
}
{code}
And critically the last line, namely:
{code}
return new URL( baseUrl, path );
{code}
where baseUrl is the previously mentioned LHS and path is the RHS passed into
the constructor
Javadoc for this baby says (java.net.URL.URL(URL context, String spec)):
{quote}
Otherwise, the path is treated as a relative path and is appended to the
context path, as described in RFC2396. Also, in this case, the path is
canonicalized through the removal of directory changes made by occurences of
".." and ".".
For a more detailed description of URL parsing, refer to RFC2396.
{quote}
Going to RFC 2396 and we find this in relation to "5.2. Resolving Relative
References to Absolute Form"
{quote}
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.
{quote}
So what happens? First of all the most right hand side path segment of the
context is removed.
That turns our LHS url from:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
to:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins
And now it says we cat on the spec, handling the '..' etc.
So we now do this:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins
+ ../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
Which results in:
http://projects.apt.fs.fujitsu.com/com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
Which is *INVALID* as it does not exist
What this object was trying to do was create a new URL of the form:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
+ ../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
i.e.:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
Which it can't as the first thing java.net.URL.URL(URL context, String spec)
does is strip the most right hand side segment from the context URL because it
expects it to be a resource, such as foo.jpg.
This bug was found during site creation, where we try and assemble the
descriptor using inherited site.xmls that have banners in them; the original
LHS input URL used in this description (or URL context if you prefer) comes
from the project.getURL() in AbstractSiteRenderingMojo.getDecorationModel
{code}
assembler.assembleModelInheritance( project.getName(),
decoration, parent, project.getUrl(),
parentProject.getUrl() ==
null ? project.getUrl() : parentProject
.getUrl()
{code}
And I've not seen many projects use explicit URLs of the sort
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1/index.html
rather the convention seems to be use the path form, rather than the full index
URL. i.e.:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
So you can not inherit things such as banners etc (there are tickets
outstanding for that)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
