[JENKINS-58771] Consider plugin dependencies with test scope to consider whether bundling a dependency is needed #140
Conversation
…der whether bundling a dependency is needed
|
Inspired by jenkinsci/kubernetes-plugin#592 I suppose. |
There was a problem hiding this comment.
Have you tested against jenkinsci/kubernetes-plugin#592 and/or jenkinsci/workflow-cps-global-lib-plugin#75?
| @@ -487,13 +488,16 @@ public void buildWebapp(MavenProject project, File webappDirectory) | |||
|
|
|||
| Set<MavenArtifact> artifacts = getProjectArtfacts(); | |||
|
|
|||
| // Also capture test dependencies | |||
| Set<MavenArtifact> dependencyArtifacts = getDirectDependencyArtfacts(); | |||
There was a problem hiding this comment.
This will certainly help, though I doubt it will cover every possible case, since this gets only direct and not transitive dependencies. There is a different method for getting resolved transitive dependencies at test scope, but I am afraid it requires to mojo to be configured to resolve to test scope (not just compile), which might cause other unwanted effects. Probably this is good enough for now, until a more exotic situation is discovered.
There was a problem hiding this comment.
Yes, I went for the simplest solution for now as I think it will think the most common cases.
|
Already had tried against jenkinsci/kubernetes-plugin#592, also gave a try with jenkinsci/workflow-cps-global-lib-plugin#75 and it works fine, no longer need to use the exclusion. |
…solves the issue cleanly.
* ssh-credentials 1.18 * fix bundled dependencies that shouldn't be packaged (jenkinsci/maven-hpi-plugin#140 doesn't cover all use cases)
JENKINS-58771
Plugin artifacts are determined only from project artifacts, which captures only dependencies with compile/runtime scopes.
In some cases, it can happen that transitive dependencies are resolved via a test-scoped trail, causing unexpected dependencies to be packaged in the resulting hpi.