You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Vincent Siveton (JIRA)" <ji...@codehaus.org> on 2008/07/17 13:45:26 UTC

[jira] Closed: (MJAVADOC-198) AbstractJavadocMojo#getClasspath(..) should use subProject's managedVersionMap

     [ http://jira.codehaus.org/browse/MJAVADOC-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vincent Siveton closed MJAVADOC-198.
------------------------------------

         Assignee: Vincent Siveton
       Resolution: Fixed
    Fix Version/s: 2.5

Patch applied in r677561, snapshot deployed

> AbstractJavadocMojo#getClasspath(..) should use subProject's managedVersionMap
> ------------------------------------------------------------------------------
>
>                 Key: MJAVADOC-198
>                 URL: http://jira.codehaus.org/browse/MJAVADOC-198
>             Project: Maven 2.x Javadoc Plugin
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Detelin Yordanov
>            Assignee: Vincent Siveton
>             Fix For: 2.5
>
>         Attachments: AbstractJavadocMojo.patch
>
>
> Hi,
>    We had a problem using Eclipse artifacts that contain version qualifiers, e.g. artifact foo version 3.3.0-SomeQualifier is not resolved
> when the dependency version definition uses a version range e.g.:
> <dependency>
> <artifactId>foo<artifactId>
> <version>[3.3.0,4.0.0)</version>
> <groupId>some Group...</groupId>
> <dependency>
> We found a workaround for this described here: http://jira.codehaus.org/browse/MECLIPSE-405.
> The workaround is to use maven 2.0.9+ and define concrete versions for the eclipse artifacts in a <dependencyManagement> section of our project, thus overriding the range version definitions in some of the eclipse poms.
> e.g.:
> <dependencyManagement>
>     <dependencies>
>         <dependency>
> 	    <groupId>org.eclipse.equinox</groupId>
> 	    <artifactId>common</artifactId>
>             <version>3.3.0-v20070426</version>
> 	</dependency>
>      ....
>     </dependencies>
> <dependencyManagement>
> This helped us to build our project without getting version range issues, however when we ran javadoc:javadoc we found out that
> the javadoc dependency resolution does not take into account the <dependencyManagement> section and we still get
> the error:
> An error has occurred in JavaDocs report generation: Couldn't find a version in [3.2.0-v20060603, 3.3.0-v20070426] to match range [3.3.0,4.0.0)
>   org.eclipse.equinox:common:jar:null
> When we examined the getClasspath(..) method of AbstractJavadocMojo we found out that it uses the ArtifactResolver#resolveTransitively(..)
> method that lacks the "managedVersions" Map parameter.
> We made an according patch to use the method that specifies it, and our problem was solved.
> So the question is whether the usage of the #resolveTransitively(..) that lacks "managedVersions" parameter is intentional or not. 
> If there is no problem with it, we would be very happy if you could change this, so that we can successfully use the javadoc plugin in our project.
> Kind Regards,
>    Detelin
> 		

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