You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Lukas Theussl (JIRA)" <ji...@codehaus.org> on 2008/02/05 09:27:57 UTC
[jira] Closed: (DOXIASITETOOLS-9) PathDescriptor fails to create
proper absolute paths from relative components, as expected by
DefaultDecorationModelInheritanceAssembler.convertPaths
[ 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