#586: Use RAT0.18 and remove commons-lang3 configuration for JDK25

[ottlinger]

Enable RAT0.18.

As RAT0.18 needs at least JDK17 I'm not sure which repos contain the actual plugin configuration, so this is a first draft PR.

Triggered by #574 @slawekjaranowski @slachiewicz

[ctubbsii]

This can't be updated yet. See my comment on #574

[ctubbsii]

This is a duplicate of #574 and can be closed.

[ctubbsii]

This should not be merged unless the minimalJavaBuildVersion is also bumped to 17.

This PR should have be closed as a duplicate of #574, which had the more detailed explanation of this in the code review comments, but for some reason, that original issue was closed, and this newer one without the discussion was left open (and subsequently approved by folks who apparently hadn't read the problems with this change).

[ctubbsii]

Suggested change

	<javaVersion>17</javaVersion>

[ctubbsii]

Alternatively, the minimalJavaBuildVersion can be set to 17, and the javaVersion can stay on an older version. The rat plugin requires 17 to run.

[slawekjaranowski]

I would like to not change javaVersion or minimalJavaBuildVersion
here we only provide a version there is not execution.

We can document it, there are an options when project will execute plugin

• set javaVersion or minimalJavaBuildVersion
• profile can also be used to execute on JDK 17+

[ctubbsii]

By not changing either of those properties, the default behavior when people use this parent POM is that executions of rat will not work.

Users will have to choose one of:

1. Override minimalJavaBuildVersion to at least 17 so that rat works, OR
2. Revert to an older Apache parent POM and manually update all the plugin versions that are managed by the parent POM with local overrides.

Option 1 is basically what I'm suggesting doing anyway. Option 2 is a terrible option.

My preference is that the minimalJavaBuildVersion default be updated to 17 in this PR, because that's the version that is required for all the plugins specified in this POM to actually work. So, it makes sense. Users don't have to update to this version of the parent POM, but those who choose to, but also want to build on an older JDK would only need to override this property, and the version properties for the rat plugin, which is much less effort than Option 2.

There is a third option:

3. The rat plugin maintainers can revert the changes they made to require Java 17 (these are relatively few), and release an update that works with Java 8.

I don't see a reason for them to do that, though. Java 8 is so old at this point, and there's no reason to build with it, since newer JDKs build Java 8 code just fine, provided the maven.compiler.release property is properly set, as this POM does for them.