a new version of Apache Commons Lang3 have been released recently which brings breaking changes for XWiki and so we need to decide how to deal with them.
Quite a few StringUtils APIs have been deprecated in favor of using a new Strings.CI or Strings.CS (CI for Case Insensitive and respectively CS for Case Sensitive) singleton instance with those methods. See also StringUtils - commons-lang3 3.18.0 javadoc.
The impact for XWiki Standard is that all the velocity calls we have to $stringutils. towards deprecated methods are generating warnings. And so it breaks the CI with the upgrade, reason why we reverted it for now. But we need to perform this upgrade, as it also contains security fixes, so the revert is really temporary and we need to find quickly a solution for dealing with this design changes.
I propose two measures, a short term and a long term one.
Long term: we create a feature-branch on the repo where we remove the hack for undeprecating the methods, and we start there performing the move to use the new methods. I called it “long term” but it’s probably only for next release (17.7.0), instead of being for current release (17.6.0).
Regarding new methods, I’m really not sure if we shouldn’t wait for [LANG-1752] Seperating ignoresCase APIs from StringUtils - ASF JIRA to be finished and closed so we deal with the deprecation once and not several times. My impression is that they might move more methods.
Also, I’m absolutely not sure what to tell people where to find methods with the new structure, it’s a mess. For example, endsWith, endsWithAny, startsWith, startsWithAny, and indexOf have all been moved and would need to be called with $stringutils.cs, but indexOfAny hasn’t been moved. I really hope that the consistency will be improved with future releases. I see three options here:
we keep the old API forever, making $stringutils more our own API
we wait until the mess has been resolved and keep the old API until then
we don’t expose Strings directly but instead expose more methods in the cs variant to also offer all methods for which in theory a case-insensitive variant could exist (for example, it doesn’t make sense to have isBlank there, but it would make sense to have indexOfAny), thereby anticipating possible future deprecations.
[Edit] I feel like this is another example where we’re exposing a third-party API as public XWiki API that we shouldn’t have exposed. Maybe we shouldn’t repeat that mistake with the Strings API and instead directly provide our own class.
+1 for short term solution. For long term I agree with @MichaelHamann that exposing third-party APIs is not a good idea (we’ll end up in the same situation when the next refactoring happens). It’s more work, but safer to provide our own class that calls commons-lang3 APIs behind the scene.