maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Allen (JIRA)" <>
Subject [jira] Created: (DOXIASITETOOLS-9) PathDescriptor fails to create proper absolute paths from relative components, as expected by DefaultDecorationModelInheritanceAssembler.convertPaths
Date Tue, 05 Feb 2008 00:21:57 GMT
PathDescriptor fails to create proper absolute paths from relative components, as expected
by DefaultDecorationModelInheritanceAssembler.convertPaths

                 Key: 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 

PathDescriptor( new URL(
), "../../../" )

And you boil down to this call   

    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 );

And critically the last line, namely:

return new URL( baseUrl, path );

where baseUrl is the previously mentioned LHS and path is the RHS passed into the constructor

Javadoc for this baby says ( context, String spec)):

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. 

Going to RFC 2396 and we find this in relation to "5.2. Resolving Relative References to Absolute

  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.

So what happens? First of all the most right hand side path segment of the context is removed.

That turns our LHS url from:


And now it says we cat on the spec, handling the '..' etc.

So we now do this:
+ ../../../

Which results in:

Which is *INVALID* as it does not exist

What this object was trying to do was create a new URL of the form:
+ ../../../


Which it can't as the first thing 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

                assembler.assembleModelInheritance( project.getName(), decoration, parent,
                                                    parentProject.getUrl() == null ? project.getUrl()
: parentProject

And I've not seen many projects use explicit URLs of the sort

rather the convention seems to be use the path form, rather than the full index URL. i.e.:

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:
For more information on JIRA, see:


View raw message