-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected addition of commons-text-api test dependency on BOM upgrade #2484
Comments
|
Seen also here jenkinsci/bitbucket-kubernetes-credentials-plugin@42dcf84 |
Since this is a problem with |
…enkinsci#2471)" jenkinsci#2484 describes the unexpected addition of commons-text-api as a new dependency for many consumers of the plugin bill of materials. Rather than having more and more plugins adding dependencies on the commons-text-api or the commons-lang3-api plugin, let's keep the checks-api dependency at 2.0.0 instead of 2.0.1. jenkinsci/checks-api-plugin#233 is the issue reported to the checks-api plugin. Once that issue is resolved, we should be able to use more recent checks-api plugin versions. Dependency updates that had to add commons-text-api included: * jenkinsci/bitbucket-kubernetes-credentials-plugin#133 * jenkinsci/elastic-axis-plugin#309 * jenkinsci/nodelabelparameter-plugin#265 * jenkinsci/testng-plugin-plugin#244 This reverts commit 729dfb2.
Fixes jenkinsci#233 (at least partially) The plugin depends on Apache commons lang3 but did not declare it directly in the pom. Declare it in the pom with hope that will help to resolve the plugin bill of materials issue described at jenkinsci/bom#2484 (comment)
…enkinsci#2471)" jenkinsci#2484 describes the unexpected addition of commons-text-api as a new dependency for many consumers of the plugin bill of materials. Rather than having more and more plugins adding dependencies on the commons-text-api or the commons-lang3-api plugin, let's keep the checks-api dependency at 2.0.0 instead of 2.0.1. jenkinsci/checks-api-plugin#233 is the issue reported to the checks-api plugin. Once that issue is resolved, we should be able to use more recent checks-api plugin versions. Dependency updates that had to add commons-text-api included: * jenkinsci/bitbucket-kubernetes-credentials-plugin#133 * jenkinsci/elastic-axis-plugin#309 * jenkinsci/nodelabelparameter-plugin#265 * jenkinsci/testng-plugin-plugin#244 This reverts commit 729dfb2.
* Pin previous credentials-binding release for LTS profiles The most recent release of the credentials-binding plugin adds masking for base64 credentials. That's a nice improvement. Unfortunately, it causes one of the config-file-provider tests to fail. Adapt older bom profiles to "Bump credentials-binding (#2509)" by retaining the current version of the credentials binding plugin on the weekly release and pinning the previous credentials binding plugin release on the LTS releases. Could exclude the test failure on all releases, but it seemed better to be able to detect test failures from the weekly release even if we can't yet test the new version with the LTS releases. This partially reverts commit bab8257. * Revert "Bump checks-api.version from 2.0.0 to 2.0.1 in /bom-weekly (#2471)" #2484 describes the unexpected addition of commons-text-api as a new dependency for many consumers of the plugin bill of materials. Rather than having more and more plugins adding dependencies on the commons-text-api or the commons-lang3-api plugin, let's keep the checks-api dependency at 2.0.0 instead of 2.0.1. jenkinsci/checks-api-plugin#233 is the issue reported to the checks-api plugin. Once that issue is resolved, we should be able to use more recent checks-api plugin versions. Dependency updates that had to add commons-text-api included: * jenkinsci/bitbucket-kubernetes-credentials-plugin#133 * jenkinsci/elastic-axis-plugin#309 * jenkinsci/nodelabelparameter-plugin#265 * jenkinsci/testng-plugin-plugin#244 This reverts commit 729dfb2.
I think that I do not understand your conclusion, can you please elaborate. Defining dependencies in a parent pom is a key concept of maven. So if this concept does not work in our build chain I would assume that our build chain has a defect that needs to be fixed. |
Not when you are the only one in the Jenkins plugin community who is doing this and when the Maven developers have explicitly changed this behavior (including adding a test for the new behavior). Your choices are to take this up with the Maven developers or to conform to the rest of the Jenkins plugin community by removing plugin-to-plugin dependencies from |
Jenkins and plugins versions report
Environment
What Operating System are you using (both controller, and any agents involved in the problem)?
Running Java 11, Java 17, or Java 21 on Linux
Reproduction steps
Expected Results
I assumed that this bom upgrade would be like previous bom upgrades, with no changes beyond the update of the bom version number. That was the behavior for many of the other plugins that I maintain, but not for the elastic axis plugin.
Actual Results
I was surprised that a new test dependency was required in the elastic axis plugin for this bom upgrade when it has not been required in previous bom upgrades.
Anything else?
I'd like to understand the difference between previous bom releases and the most recent bom release. The most recent bom release upgraded the commons-text-api plugin but an earlier upgrade to that plugin was processed a month ago without requiring the addition of a new test dependency.
I'm also happy if the answer is "this is not a surprise" for others.
The text was updated successfully, but these errors were encountered: