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
deps: use commons-lang3 replace commons-lang #8996
Conversation
Signed-off-by: BobDu <i@bobdu.cc>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shipping commons-lang3
in core was not intentional, and I am removing it in #8997.
I understand the design philosophy that we don't want to continue expanding the core API surface. But, can
ping @basil |
Weighing all of the above, I am still a -1 on making a special exception for Commons Lang 3. But I am not the only core maintainer, so if you feel strongly about this, you can start a broader discussion on the developer mailing list. |
Maybe we should start the discussion from a different angle. The Regarding the transition from I believe that it is more meaningful to reach a consensus on this point first. ping @basil |
Not a core maintainer here but maintaining many plugin (including API ones). I will be -1 on this PR it's againts all the work started on API plugins and dependency management on plugin side. I don't think we should do any exception on https://plugins.jenkins.io/commons-lang-api/ also exists already to keep compatibility of plugin that depends from |
Sorry, I missed the discussion that took place 2 years ago. JENKINS-67789 It seems that the community had reached a consensus at that time. To detached commons-lang from core, and make If I have misunderstood the consensus reached before, please remind me. https://www.jenkins.io/doc/book/managing/plugins/#what-is-an-implied-dependency I believe that it would certainly be the best if this goal could be achieved. Moreover, the community has already made efforts in this direction. like: #6270 How do we proceed further now? Continue to use native Java APIs to replace |
Yes, plugins are encouraged to migrate from Commons Lang 2 to Commons Lang 3 (using the Commons Lang 3 library plugin). In core we strive to use as few third-party libraries as possible in order to decrease the API surface area exposed to plugins, so there we prefer to rewrite usages of Commons Lang 2 to usages of standard Java Platform APIs. You are welcome to contribute to both efforts. |
I'm with Basil and Valentin. |
closed to support #8997 |
Note that even once consumers are migrated away from the remaining (now deprecated) core APIs that contain Commons Lang 2.x classes in their signatures, there is still the matter of core depending on Stapler, which depends on our fork of json-lib, which depends on Commons Lang 2.x. That fork of |
Create a new issue to tracking progress: https://issues.jenkins.io/browse/JENKINS-72981 |
A dependency on
commons-lang3
was declared incommons-compress
version 1.26.Jenkins core
version 2.447 upgraded tocommons-compress
1.26, and from that point onwards,commons-lang3
has effectively been present in our dependency chain.Therefore, it is safe to use
commons-lang3
replacecommons-lang
without causing any additional breaking changes.ref:
apache commons compress
apache/commons-compress@bf50b7d#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8L214
jenkins core
8d2045b
Testing done
N/A
Proposed changelog entries
Proposed upgrade guidelines
N/A
Submitter checklist
@Restricted
or have@since TODO
Javadocs, as appropriate.@Deprecated(since = "TODO")
or@Deprecated(forRemoval = true, since = "TODO")
, if applicable.eval
to ease future introduction of Content Security Policy (CSP) directives (see documentation).Desired reviewers
@mention
Before the changes are marked as
ready-for-merge
:Maintainer checklist
upgrade-guide-needed
label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).lts-candidate
to be considered (see query).