Uploaded image for project: 'Maven Javadoc Plugin'
  1. Maven Javadoc Plugin
  2. MJAVADOC-450

Artifacts with a classifier are ignored when looking for resources in dependencies

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.10.3
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Environment:
    • Flags:
      Patch

      Description

      When adding a an artifact with a classifier to the dependencies of the maven-javadoc-plugin, this artifact is not used when trying to resolve dependencies.
      The symptom is that a message like

      [WARNING] Unable to find the resource 'path/to/resource'. Using default Javadoc resources.

      is displayed, even though the resource "path/to/resource" is present in a JAR listed in the plugin dependencies.

      The reason for this seems to be that the code resolving the artifact does not consider the specified classifier: The class JavadocPathArtifact does not have a field for the classifier and consequently, the classifier is not set when building the JavadocPathArtifact in AbstractJavadocMojo.getResource (AbstractJavadocMojo.java:5307).

      The solution is adding a classifier field to JavadocPathArtifact and using this classifier in AbstractJavadocMojo.createAndResolveArtifact. However, I think there is also bug in that method because it uses createProjectArtifact when it should probably use createArtifactWithClassifier. createProjectArtifact always refers to the POM, so in the end the pom.xml is added to the classpath which never makes sense.

      1. MJAVADOC-450.patch
        2 kB
        Sebastian Marsching

        Activity

        Hide
        smarsching Sebastian Marsching added a comment -

        I attached a patch that fixes the problem for me.

        The patch uses a slightly different approach than outlined in the issue description. Changing AbstractJavadocMojo.createAndResolveArtifact and JavadocPathArtifact seemed to have too much side effects. With my very limited knowledge of the code I cannot guarantee that this would not break anything.

        The patch only modifies AbstractJavadocMojo.getResource and uses the straight-forward way of using the dependency information to resolve a dependency artifact. For fixing the resource loading from dependencies, this patch is sufficient.

        I still think that createAndResolveArtifact's behavior of always resolving to the pom.xml is not correct. At least in some places, it is used in a way that does not seem compatible with this behavior. However, my knowledge of the whole plugin code is too limited to understand what the desired outcome would be in these cases (resolving to the referenced project source directory or resolving to the "default" artifact of the referenced project).

        I think that my patch is so simple that it is not protected under any copyright laws, but for practical purposes, I hereby declare that I release it to the public domain.

        Show
        smarsching Sebastian Marsching added a comment - I attached a patch that fixes the problem for me. The patch uses a slightly different approach than outlined in the issue description. Changing AbstractJavadocMojo.createAndResolveArtifact and JavadocPathArtifact seemed to have too much side effects. With my very limited knowledge of the code I cannot guarantee that this would not break anything. The patch only modifies AbstractJavadocMojo.getResource and uses the straight-forward way of using the dependency information to resolve a dependency artifact. For fixing the resource loading from dependencies, this patch is sufficient. I still think that createAndResolveArtifact's behavior of always resolving to the pom.xml is not correct. At least in some places, it is used in a way that does not seem compatible with this behavior. However, my knowledge of the whole plugin code is too limited to understand what the desired outcome would be in these cases (resolving to the referenced project source directory or resolving to the "default" artifact of the referenced project). I think that my patch is so simple that it is not protected under any copyright laws, but for practical purposes, I hereby declare that I release it to the public domain.

          People

          • Assignee:
            Unassigned
            Reporter:
            smarsching Sebastian Marsching
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development