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

Plugins have transitive plugin dependencies but Jenkins cannot know

    Details

    • Similar Issues:

      Description

      Plugins with a dependency on a plugin A get the plugin dependencies of A added to their class path.

      When those dependencies are removed in later versions of A, or made optional, Jenkins has no way to know that dependency ever even existed, since it only knows about what's currently installed.

      Therefore dependencies from plugins should not be made available transitively, and attempts to access such classes should fail. (For compatibility reasons, we probably need a maven-hpi-plugin option here.)


      Inspired by discussion with Daniel Spilker in https://github.com/jenkinsci/gradle-jpi-plugin/pull/92 where this behavior was actually implemented for Gradle JPI plugin.

      This seems to be a real potential problem with e.g. the matrix-project MatrixAggregatable extension effort, and similar changes that aim to make dependencies optional. They may not be considered to be optional in dependent plugins, as per the above PR discussion. See also JENKINS-44200.

      CC Jesse Glick

       

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          FWIW the NetBeans module system does not allow access to transitive dependencies—you need to declare everything you refer to in bytecode¹. The Maven-based build harness binds a special goal to (IIRC) the compile phase which reports an error if the resulting bytecode in fact refers to an undeclared dependency, since there is no way to tell Maven to disable transitive resolution of the compilation classpath.

          ¹Not quite the same as source code. You can for example use a compile-time constant from a class without leaving a trace in the bytecode. Conversely, certain Java constructions cause bytecode to refer to a class name which is not present in the source code.

          Show
          jglick Jesse Glick added a comment - FWIW the NetBeans module system does not allow access to transitive dependencies—you need to declare everything you refer to in bytecode¹. The Maven-based build harness binds a special goal to (IIRC) the compile phase which reports an error if the resulting bytecode in fact refers to an undeclared dependency, since there is no way to tell Maven to disable transitive resolution of the compilation classpath. ¹Not quite the same as source code. You can for example use a compile-time constant from a class without leaving a trace in the bytecode. Conversely, certain Java constructions cause bytecode to refer to a class name which is not present in the source code.
          Hide
          danielbeck Daniel Beck added a comment -

          surely we just need to start having people change their behavior and care about something that doesn't actually benefit them in any way, but instead creates more work

          Good luck with that.

          Even switching on an option by default will be an uphill battle, see disabled InjectedTests, disabled Javadoc lint, etc.

          Show
          danielbeck Daniel Beck added a comment - surely we just need to start having people change their behavior and care about something that doesn't actually benefit them in any way, but instead creates more work Good luck with that. Even switching on an option by default will be an uphill battle, see disabled InjectedTests, disabled Javadoc lint, etc.
          Hide
          stephenconnolly Stephen Connolly added a comment -

          surely we just need to start having people actually pay attention to dependency:analyze and get them to add the used undeclared dependencies (though part of the issue that would then cause is that we'd have more jar dependencies bundled in plugins)

          Show
          stephenconnolly Stephen Connolly added a comment - surely we just need to start having people actually pay attention to dependency:analyze and get them to add the used undeclared dependencies (though part of the issue that would then cause is that we'd have more jar dependencies bundled in plugins)

            People

            • Assignee:
              Unassigned
              Reporter:
              danielbeck Daniel Beck
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: