maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Allen (JIRA)" <j...@codehaus.org>
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
                 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

        

Mime
View raw message