TOMEE-4657 - use the modular EclipseLink JPA artifact instead of the uber-jar

[jungm]

Problem

On a stock TomEE 11 Plume server, every Bean Validation path that reads validation.xml or a constraint-mapping XML descriptor fails.

Plume depends on org.eclipse.persistence:eclipselink, a monolithic artifact that bundles MOXy alongside the JPA runtime and registers a jakarta.xml.bind.JAXBContextFactory service. MOXy therefore wins the ServiceLoader lookup over the JAXB RI that Plume also ships. MOXy cannot unmarshal through the SAX UnmarshallerHandler chain Apache BVal uses (SchemaManager#unmarshal), so descriptor parsing fails with DOMException: NAMESPACE_ERR.

Two details worth noting, since the Jira description gets them slightly wrong:

• JAXBContext.newInstance itself succeeds under MOXy. The failure happens later, when the unmarshaller receives SAX events.
• BVal's namespace rewriting is not the trigger. A native 3.0 validation.xml, which needs no rewriting, fails identically.

Fix

Plume needs a JPA provider, not a JAXB one, so depend on the modular org.eclipse.persistence.jpa artifact instead.

It brings the JPA runtime plus persistence.core and jpa.jpql, keeps the jakarta.persistence.spi.PersistenceProvider service, and leaves MOXy, SDO, JPA-RS and the Oracle platforms out of the distribution. jaxb-runtime becomes the only JAXBContextFactory provider in Plume, so no system property pin is required.

Shipped Plume lib/ after the change:

org.eclipse.persistence.jpa-5.0.1.jar
org.eclipse.persistence.core-5.0.1.jar
org.eclipse.persistence.jpa.jpql-5.0.1.jar

jaxb-runtime-4.0.4.jar -> org.glassfish.jaxb.runtime.v2.JAXBContextFactory   (sole provider)

Verification

Both run against a clean build of the Plume distribution:

TCK	Result
Jakarta Persistence 3.2.1	2134 tests, 0 failures, 0 errors, plus the signature test — unchanged from the previous baseline
Jakarta Validation 3.1.1	1049 tests, 0 failures, signature test 0 failures — with no jakarta.xml.bind.JAXBContextFactory pin configured

The validation run is the one that closes the issue: the TCK harness previously needed a jakarta.xml.bind.JAXBContextFactory system property to pass, and that workaround is no longer necessary.

The persistence run covers the regression risk of dropping the uber-jar. All 17 EclipseLink classes TomEE imports are present in the modular set, and nothing reaches the removed JPA-RS/SDO/Oracle classes reflectively.

Notes for reviewers

• Requires a clean build to observe. The plume work dir keeps previously staged jars, so an incremental build can still package the old uber-jar and make it look like the change had no effect.
• boms/tomee-plume/pom.xml is regenerated by GenerateBoms during the build; the only other change there is asm-analysis and asm-util dropping out, since they came in via the uber-jar.
• This removes MOXy from Plume entirely. Anyone deliberately relying on MOXy as their JAXB provider on Plume would be affected, so it may deserve a release note.

🤖 Generated with Claude Code