JENKINS-67789 commons-lang3

[nhojpatrick]

Adds apache commons-lang3 support for plugin and upgrades internal usage as well.

See JENKINS-67789.

Proposed changelog entries

• org.apache.commons:commons-lang3 support for plugins
• Internal change for jenkins to use org.apache.commons:commons-lang3 instead of commons-lang:commons-lang

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadoc, as appropriate.
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[basil]

Adding new dependencies to Jenkins core, which can be used by any plugin and must be maintained in perpetuity, creates a burden for the Jenkins core developers. Rather suggest creating a new API plugin for Commons Lang3 and consuming it via the plugin-to-plugin dependency mechanism.

[nhojpatrick]

Adding new dependencies to Jenkins core, which can be used by any plugin and must be maintained in perpetuity, creates a burden for the Jenkins core developers. Rather suggest creating a new API plugin for Commons Lang3 and consuming it via the plugin-to-plugin dependency mechanism.

I've rephrase then...

Currently core jenkins uses commons-lang:commons-lang:2.6 which was release in 2011/06/16, and is Java 1.6.0_20 bytecode. This update changes the internal code to using an actively being maintained dependency. A side affect is plugin's can upgrade if they wish too. The original dependency probably needs to raised as deprecated and I'm happy to start looking for those plugins, raising pr's to upgrade and if needed upgrade the plugin to a newer base version.

[jtnord]

I agree with Basil.
For plugin usage this should be in an API plugin.

This came up internal recently due to a plugin blowing up when config-as-code was installed and an optional transitive dependency meant an old version was consumed

Longer term commons-lang would eventually be removed from core, but that is a different issue

[basil]

Rather than migrating core's usages of Commons Lang 2 to Commons Lang 3, with the associated maintenance burden of supporting Commons Lang 3 APIs in perpetuity, it would be better to rewrite usages of Commons Lang 2 in core and core components (e.g., Stapler, Remoting, etc.) to avoid the use of Commons Lang 2 and rely instead on native Java Platform APIs, as was done for usages of Guava and JavaMail in the recent past (see JEP-233). If this is done, then Commons Lang 2 can be detached into an API plugin, with plugins migrating from the future Commons Lang 2 API plugin to the future Commons Lang 3 API plugin at their leisure. See also the ongoing migration from JavaMail to Jakarta Mail, which is being handled in similar fashion.

[nhojpatrick]

Thanks all for feedback/replies.

Regarding api-plugin do you mean something like https://plugins.jenkins.io/apache-httpcomponents-client-4-api ?
Would the api-plugin be something that could be added into the tooling bom?

Also if I'm creating this via architect, which is the best to start with mvn -U archetype:generate -Dfilter="io.jenkins.archetypes:"?
A) io.jenkins.archetypes:global-shared-library
B) io.jenkins.archetypes:empty-plugin
C) Other

[nhojpatrick]

@basil @jtnord
Rejecting my own PR, as have raised the following;
jenkins-infra/repository-permissions-updater#2372
jenkins-infra/repository-permissions-updater#2373