commons 4 api plugin

[Radek Antoniuk]

Hi,

Jenkins currently has https://github.com/jenkinsci/commons-lang3-api-plugin but there are some useful methods added in 4.x that I'd like to use.

Is there any plan to create a new plugin version of this or should I go ahead..?

Was there any reason the current plugin was called lang3 instead of just lang and following the semver accordingly?

Cheers,

Radek

[Winter, Markus]

What you link is commons-collections4 that is not related to commons-lang3

And commons-lang3 uses different packages than commons-lang (version2) so we need both plugins 

Feel free to create a wrapper plugin for commons.collections4, there are a few plugins that use commons.collections4 so they could benefit as well

---

From: jenkin...@googlegroups.com <jenkin...@googlegroups.com> on behalf of Radek Antoniuk <radek.a...@gmail.com>
Sent: Friday, May 23, 2025 11:21 AM
To: Jenkins Developers <jenkin...@googlegroups.com>
Subject: commons 4 api plugin

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/4203a578-8cf5-4aec-9890-22f03fd6eeabn%40googlegroups.com.

[Radek Antoniuk]

> And commons-lang3 uses different packages than commons-lang (version2) so we need both plugins 

It's normal for major semver-sioned libraries to be incompatible in some way (e.g. in the package name). 

Usually, when new major release is released, the child projects should move to that version gradually and in case a bugfix is needed, it's just released from the same repository under respective verison. Just making sure, if that was a conscious decision to support 2 (and 3 if I create lang4) major releases instead of  having them in one commons-lang that would just publish respective sem versions? 

Am I guessing correctly that this is in order to simplify the plugin release process (even though not following normal semver repository practices)? 

On the other hand, I see that https://github.com/jenkinsci/commons-lang-api-plugin has no activity at all, so I'm wondering if that should not be archived in favor of commons-lang3-api-plugin? I see that only lang3 is used in the bom.

[Winter, Markus]

To repeat myself, there is no version 4 for commons-lang

You refer to commons-collections which is something totally different. So, an api plugin would be named commons-collections4-api

Technically commons-lang2 and commons-lang3 are different things, they are published with different artifact IDs.

And we need 2 different plugins. There can always be only one version of a plugin installed.

There is no activity in the commons-lang-api plugin because commons-lang v2 is end of life and there have been no new releases since over a decade. Interestingly there are no dependencies to the plugin currently. But Jenkins core still packages the library and thus makes it API of Jenkins. And there are many plugins which make use of the classes relying on Jenkins core providing them. So what core could do is no longer shipping commons-lang and create an implied dependency to the lang2 api plugin.

Of course it would be good if all the plugins that use lang2 via core would migrate to lang3 but reality is that probably not all plugins are well maintained, or they are abandoned or up for adoption.

---

From: jenkin...@googlegroups.com <jenkin...@googlegroups.com> on behalf of Radek Antoniuk <radek.a...@gmail.com>

Sent: Monday, May 26, 2025 1:18 PM
To: Jenkins Developers <jenkin...@googlegroups.com>
Subject: Re: commons 4 api plugin

To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/5f09669c-c2a2-4685-aa86-aa7276e4938an%40googlegroups.com.

[Radek Antoniuk]

Got it, all clear, thanks for patience - issue submitted.

I now understood that the current agreement is to follow the plugin naming scheme that follows the Java package naming scheme.  With that in mind, perhaps this should be reflected in the https://www.jenkins.io/doc/developer/publishing/style-guides/ guide as a short new "Plugin Wrappers" section?