Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53957

hpi bundles transitive dependencies of test scope dependencies

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I have a plugin that depends on the test jar of org.jenkins-ci.plugins.workflow:workflow-support:jar with scope test

      When I package this plugin I find that the transitive dependencies of that dependency are included in the hpi archive when they should be ignored as they come from a test dependency.

      [INFO] +- org.jenkins-ci.plugins.workflow:workflow-support:jar:tests:2.19:test
      [INFO] |  \- org.jboss.marshalling:jboss-marshalling-river:jar:1.4.12.jenkins-3:compile
      [INFO] |     \- org.jboss.marshalling:jboss-marshalling:jar:1.4.12.jenkins-3:compile
      

      this code is most likely wrong as it is filtering the individual artifacts after the building of the tree.
      This is incorrect as the exclusion should be happening before the building of the tree, or the filtering should accept that the library is a decendant of something else that has been filtered meaning it should not include this.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Pavel Roskin I suppose you mean 1.19, not 1.9. Your use of dependency:tree shows clearly that the problem is in your POM, not in the plugin. (maven-hpi-plugin simply follows Maven’s directions here about what scope a dependency is in.) It seems to stem from having a dependency on an ancient version of the git plugin which itself had a faulty POM, in turn due to a faulty POM in git-client. (As far back as I can easily follow history, this seems to have been fixed in 2013. The ssh-agent plugin’s POM does bundle sshd-core.jar, but in that case it is correct since it sets pluginFirstClassLoader: it is not using the copy from the core module. But any plugin depending on ssh-agent must exclude this dependency since Maven does not grok that situation. Maybe could be fixed by making it optional in ssh-agent, not sure.) Short of updating the git dependency, it can be worked around easily:

            diff --git a/pom.xml b/pom.xml
            index 2d6ca7b..dd133c8 100644
            --- a/pom.xml
            +++ b/pom.xml
            @@ -92,6 +92,12 @@
                         <artifactId>git</artifactId>
                         <version>2.0</version>
                         <type>jar</type>
            +            <exclusions>
            +                <exclusion>
            +                    <groupId>org.apache.sshd</groupId>
            +                    <artifactId>sshd-core</artifactId>
            +                </exclusion>
            +            </exclusions>
                     </dependency>
                     <dependency>
                         <groupId>org.jenkins-ci.plugins</groupId>
            

            What would be useful, I think, is for maven-hpi-plugin to at least issue a notice in the build log when it is bundling something other than the plugin JAR in WEB-INF/lib/*.jar. Perhaps this should at logged at info level for direct (expressed) dependencies and warning level for indirect dependencies.

            Show
            jglick Jesse Glick added a comment - Pavel Roskin I suppose you mean 1.19, not 1.9. Your use of dependency:tree shows clearly that the problem is in your POM, not in the plugin. ( maven-hpi-plugin simply follows Maven’s directions here about what scope a dependency is in.) It seems to stem from having a dependency on an ancient version of the git plugin which itself had a faulty POM, in turn due to a faulty POM in git-client . (As far back as I can easily follow history, this seems to have been fixed in 2013 . The ssh-agent plugin’s POM does bundle sshd-core.jar , but in that case it is correct since it sets pluginFirstClassLoader : it is not using the copy from the core module. But any plugin depending on ssh-agent must exclude this dependency since Maven does not grok that situation. Maybe could be fixed by making it optional in ssh-agent , not sure.) Short of updating the git dependency, it can be worked around easily: diff --git a/pom.xml b/pom.xml index 2d6ca7b..dd133c8 100644 --- a/pom.xml +++ b/pom.xml @@ -92,6 +92,12 @@ <artifactId> git </artifactId> <version> 2.0 </version> <type> jar </type> + <exclusions> + <exclusion> + <groupId> org.apache.sshd </groupId> + <artifactId> sshd-core </artifactId> + </exclusion> + </exclusions> </dependency> <dependency> <groupId> org.jenkins-ci.plugins </groupId> What would be useful, I think, is for maven-hpi-plugin to at least issue a notice in the build log when it is bundling something other than the plugin JAR in WEB-INF/lib/*.jar . Perhaps this should at logged at info level for direct (expressed) dependencies and warning level for indirect dependencies.
            Hide
            jglick Jesse Glick added a comment -

            I filed a PR for that last suggestion.

            Show
            jglick Jesse Glick added a comment - I filed a PR for that last suggestion.
            Hide
            proski Pavel Roskin added a comment -

            Thank you, Jesse Glick! I was able to fix the issue in stash notifier with sshd-core bundling by updating the git dependency.

            It's very nice to see your PR merged already!

            Show
            proski Pavel Roskin added a comment - Thank you, Jesse Glick ! I was able to fix the issue in stash notifier with sshd-core bundling by updating the git dependency. It's very nice to see your PR merged already!
            Hide
            jglick Jesse Glick added a comment -

            Note that while poking around I did discover what looks like a proper bug in the mojo: JENKINS-58771.

            Show
            jglick Jesse Glick added a comment - Note that while poking around I did discover what looks like a proper bug in the mojo: JENKINS-58771 .
            Hide
            proski Pavel Roskin added a comment -

            OK, I think I understand it. Posting here to help others understand similar issues. The dependency chain (without test dependencies) was:
             
            stashNotifier -> git 2.0 -> git-client 1.4.4 -> ssh-agent 1.3 -> sshd-core 0.8.0

            Now it is:
             
            stashNotifier 1.19 -> git 3.0.0 -> git-client 2.0.0

            git-client 2.0.0 doesn't depend on ssh-agent, so that cuts the non-test dependency chain and stops the bundling.

            The version of sshd-core (0.14.0) was determined by a shorter chain that involved test dependencies:

            stashNotifier 1.19 => plugin 3.40 -> jenkins-war 2.60.3 ~> sshd 1.11 -> sshd-core 0.14.0

            I'm using => for a child-parent relationship (which doesn't count towards the length of the dependency chain) and ~> for a test dependency.

            mvn dependency:tree was showing a shorter dependency chain, but with the scope based on analyzing the whole tree, which made it look like a test dependency was pulling in a compile dependency.

            I don't see a way to make maven omit test dependencies or to show all paths leading to a transitive dependency. It would have helped with debugging the issue.

            Show
            proski Pavel Roskin added a comment - OK, I think I understand it. Posting here to help others understand similar issues. The dependency chain (without test dependencies) was:   stashNotifier -> git 2.0 -> git-client 1.4.4 -> ssh-agent 1.3 -> sshd-core 0.8.0 Now it is:   stashNotifier 1.19 -> git 3.0.0 -> git-client 2.0.0 git-client 2.0.0 doesn't depend on ssh-agent, so that cuts the non-test dependency chain and stops the bundling. The version of sshd-core (0.14.0) was determined by a shorter chain that involved test dependencies: stashNotifier 1.19 => plugin 3.40 -> jenkins-war 2.60.3 ~> sshd 1.11 -> sshd-core 0.14.0 I'm using => for a child-parent relationship (which doesn't count towards the length of the dependency chain) and ~> for a test dependency. mvn dependency:tree was showing a shorter dependency chain, but with the scope based on analyzing the whole tree, which made it look like a test dependency was pulling in a compile dependency. I don't see a way to make maven omit test dependencies or to show all paths leading to a transitive dependency. It would have helped with debugging the issue.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              teilo James Nord
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: