Update commons-beanutils to 1.11.0

[juanluisrp]

Pins commons-beanutils to 1.11.0 in the root dependencyManagement, so that all modules resolve the same, current version.

Why

commons-beanutils is never declared directly. It arrives transitively through three introducers, each pulling a different version:

Introducer	Declared in	Pulls
net.sf.json-lib:json-lib:2.4	common/pom.xml	1.8.0
commons-digester:1.6	core/pom.xml, web/pom.xml	1.6
com.github.sommeri:less4j:1.8.4	wro4j/pom.xml	1.8.3

Maven nearest-wins then resolves a different version per module. Before this change, dependency:tree across the 39 reactor modules reports:

16 commons-beanutils:1.6
10 commons-beanutils:1.8.0
 1 commons-beanutils:1.8.3
 1 commons-beanutils:1.9.4

After:

28 commons-beanutils:1.11.0

1.11.0 is the latest release of the 1.x line. The 2.x line is not an option here: it lives under a different coordinate (org.apache.commons:commons-beanutils2), has only milestone releases, and repackages to org.apache.commons.beanutils2, so the third-party jars that consume it would not link against it.

commons-collections is unaffected: it resolves to 3.2.2 both before and after.

commons-digester stays at 1.6

Removing it looks tempting, since nothing in GeoNetwork's own source references it, but it is required at runtime. jzkit-service uses org.apache.commons.digester.Digester in XMLImpl, and the jzkit-service pom published to the OSGeo repository declares no dependencies at all, so GeoNetwork has to supply digester by hand. JZkitApplicationContext.xml is imported unconditionally from config-spring-geonetwork.xml, and XMLImpl builds its Digester instances during bean initialisation, so dropping the declaration breaks startup. The dependencyManagement entry overrides the transitive resolution regardless, so digester no longer drags 1.6 along.

Testing

• mvn clean install -DskipTests — all 39 modules build.
• Unit tests for common, domain, core, services and web — 561 tests, no failures or errors.
• The exploded WAR contains a single commons-beanutils-1.11.0.jar.
• The two direct PropertyUtils.getProperty callers in XslUtil (nested dotted paths over a Jackson-parsed map, the null branch for absent keys, and a key named class) and the json-lib paths (Xml.getJSON, Xml.getXmlFromJSON, ObjectJSONUtils.extractFieldFromJSONString, JSONObject.fromObject) were exercised under both 1.8.0 and 1.11.0, with identical results. This matters because 1.9.4 and later suppress the class property by default.
• Ran the application with Jetty against Elasticsearch. The SRU explain endpoint returns its full explain record, which is rendered from JZKit configuration loaded through Digester, confirming that digester 1.6 works against the newer beanutils. No NoClassDefFoundError or NoSuchMethodError in the logs.