Removed dependency on 'org.apache.commons.lang'

[cweitkamp]

• Removed dependency on org.apache.commons.lang

• bom/compile/pom.xml

• bom/compile/pom.xml

• features/karaf/openhab-tp/src/main/feature/feature.xml

• Resolve itest.bndrun

Signed-off-by: Christoph Weitkamp github@christophweitkamp.de

[cweitkamp]

OHC code is clean now. But it will completely break openHAB add-ons. Thus I did not yet remove the import from BOM nor resolved the itests.

[wborn]

The task list suggests you want to keep working on this but you did remove the WIP label?

[5iver]

ScriptUtils is only used in one JS example script in any of the helper libraries, which I have created a PR to remove. I'm doubtful there will be much of an impact to peoples' scripts. I'm sure there is a good reason, but I'm curious why this is being removed.

[cweitkamp]

The task list suggests you want to keep working on this but you did remove the WIP label?

It is more or less a reminder. In general I wanted to ask for your opinion. How should we proceed? Remove everything in OHC right now and break OH3 add-ons build or try to find a solution for add-ons. Do we currently continue to allow apache.commons.lang over there or not?

I'm sure there is a good reason, but I'm curious why this is being removed.

One of our open items on the roadmap for OH3 is to remove dependency on apache.commons in OHC. Imo nearly everything is possible to solve with plain Java 11 and the library itself is quite huge (size in MB) an a heavy payload for the framework.

[J-N-K]

We need to refactor addons anyway to remove commons-lang, right? So we could do it now, it shpuld not break anything that faces the user, so it is fully backward-compatible.

[wborn]

We can already replace all usages in the core and keep the Maven dependency for now so the OH3 add-ons port keeps working.

For some changes such as using String.isBlank Java 11 is required. So that change can't be done until the OH2 add-ons are ported and Java 11 features can be used. But other replacements that don't depend on Java 11 features can already be made on the OH2 add-ons. E.g. replacing StringUtils.join by utilizing streams.

That way this PR won't collect merge conflicts and we can slowly progress to fully removing the dependency.

[cweitkamp]

That was exactly my idea and the purpose of leaving BOM and features untouched. Resolving the itest.bndrun files can be done in scope of this PR without problems.

[wborn]

Thanks! As the changes show, the library no longer provides us with a lot of added value.

[cweitkamp]

Great. I will try to continue with org.apache.commons.io and org.apache.commons.logging.

[kaikreuzer]

Can you help me with which change org.apache.commons.codec has been removed?
It seems that something broke the add-ons port build: https://ci.openhab.org/job/openHAB-Addons-port/108/

[cweitkamp]

I think org.apache.commons.codec was a dependency of org.apache.commons.httpclient (see #1436). We never included it ourselves. Was probably resolved by mvn.

[kaikreuzer]

Hm, ok, thanks - interesting side-effect.
Hopefully not too many bindings are hit by that.

[cweitkamp]

A quick search reveals three: freebox, loxone and millheat. They are using methods to decode/encode hex strings to byte arrays. We can replace them by OHC HexUtils.

[kaikreuzer]

"We can" - I assume you are talking in majestic plural and am looking forward to your PR - thanks! 🥇

[cweitkamp]

"We" created a PR to fix it openhab/openhab-addons#7460

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/guide-binding-development-changes-for-openhab-3-from-2-5-x/104134/4

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-3-0-milestone-2-discussion/107564/131