Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: core, maven-hpi-plugin
-
Labels:
-
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
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.
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)
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.