Maven Javadoc Plugin
  1. Maven Javadoc Plugin
  2. MJAVADOC-198

AbstractJavadocMojo#getClasspath(..) should use subProject's managedVersionMap

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.4
    • Fix Version/s: 2.5
    • Labels:
      None
    • Flags:
      Patch

      Description

      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

        Activity

        Detelin Yordanov created issue -
        Hide
        Siveton Vincent added a comment -

        Patch applied in r677561, snapshot deployed

        Show
        Siveton Vincent added a comment - Patch applied in r677561, snapshot deployed
        Siveton Vincent made changes -
        Field Original Value New Value
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s 2.5 [ 14120 ]
        Assignee Vincent Siveton [ siveton ]
        Mark Thomas made changes -
        Project Import Sun Apr 05 11:56:47 UTC 2015 [ 1428235007093 ]
        Mark Thomas made changes -
        Workflow jira [ 12722436 ] Default workflow, editable Closed status [ 12762443 ]
        Mark Thomas made changes -
        Patch Submitted Yes [ 10763 ]
        Flags Patch [ 10430 ]
        Mark Thomas made changes -
        Project Import Mon Apr 06 00:11:46 UTC 2015 [ 1428279106587 ]
        Mark Thomas made changes -
        Workflow jira [ 12960113 ] Default workflow, editable Closed status [ 12997000 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        2h 59m 1 Siveton Vincent 17/Jul/08 07:44

          People

          • Assignee:
            Siveton Vincent
            Reporter:
            Detelin Yordanov
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development