[
http://jira.codehaus.org/browse/DOXIASITETOOLS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIASITETOOLS-9.
--------------------------------------
Assignee: Lukas Theussl
Resolution: Won't Fix
This behavior is correct according to the rfc specs:
http://www.ietf.org/rfc/rfc2396.txt (see eg the example given in App D).
If you want the "1" to be interpreted as a hierarchical component (ie as a
directory on a filesystem), you need to append a slash in the end:
{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}
which is a recommended practice for web URLs anyway, see eg
http://www.standardzilla.com/2007/07/09/dont-forget-your-trailing-slash/
> 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
> Assignee: Lukas Theussl
>
> 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
