You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Detelin Yordanov (JIRA)" <ji...@codehaus.org> on 2008/07/17 10:46:26 UTC
[jira] Created: (MJAVADOC-198) AbstractJavadocMojo#getClasspath(..)
should use subProject's managedVersionMap
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
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
[jira] Closed: (MJAVADOC-198) AbstractJavadocMojo#getClasspath(..)
should use subProject's managedVersionMap
Posted by "Vincent Siveton (JIRA)" <ji...@codehaus.org>.
[ 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