HSEARCH-4940 Use "Jakarta Batch" instead of "JSR-352"/"Batch for Java" in POM and documentation of JSR-352 artifacts

[marko-bekhta]

https://hibernate.atlassian.net/browse/HSEARCH-4940

Hey Yoann,
From what it looks, we've missed the javax->jakarata update for a CDI (see [HSEARCH-4940 Make sure that batch beans are correctly registered within CDI]) 😔
I've updated that service file and bean names too, but with these changes EntityManagerFactoryRegistry emfRegistryin JobContextSetupListener is injected as JBeretEntityManagerFactoryRegistry (previously it was just null), which leads to failures since the PersistenceUnitAccessor#entityManagerFactory == null
The "fix" in HSEARCH-4940 Fallback to ActiveSessionFactoryRegistry makes the tests pass, but I'd still expect that the correct way to solve this would be to make PersistenceUnitAccessor#entityManagerFactory != null ... Not sure how to get there though 😔😃 ...

besides the bug, do we want to change the java module names + packages for these modules or should we leave them as they are?
Opening as a draft since need a better fix for the bug ^

[yrodiere]

I've updated that service file and bean names too, but with these changes EntityManagerFactoryRegistry emfRegistryin JobContextSetupListener is injected as JBeretEntityManagerFactoryRegistry (previously it was just null), which leads to failures since the PersistenceUnitAccessor#entityManagerFactory == null

I don't get what you mean... Maybe we should discuss this on Zulip?

besides the bug, do we want to change the java module names + packages for these modules or should we leave them as they are?

I'd change the java module names + packages. It's a breaking change (which needs to be documented), but I've checked and these modules are not productized yet, so we can break this in a major like 7.0.

[marko-bekhta]

I've left the "incorrect" service file name as well. With JBeret upgrade the listener was added through CDI even though the reference was incorrect. They've added some code that would check if the bean is present by a reference in the bean manager and if not try to use the reference as a class name and lookup beans by that class. So we were ending up getting the listener through the CDI and as a result, working with the JBeret registry which led to test failures in the end.

Added all the notes to https://hibernate.atlassian.net/browse/HSEARCH-4966

[yrodiere]

Seems you need to update dependencies in the reports module:

[ERROR] Failed to execute goal on project hibernate-search-reports: Could not resolve dependencies for project org.hibernate.search:hibernate-search-reports:pom:7.0.0-SNAPSHOT: The following artifacts could not be resolved: org.hibernate.search:hibernate-search-mapper-orm-batch-jsr352-core:jar:7.0.0-SNAPSHOT (absent), org.hibernate.search:hibernate-search-mapper-orm-batch-jsr352-jberet:jar:7.0.0-SNAPSHOT (absent): Could not find artifact org.hibernate.search:hibernate-search-mapper-orm-batch-jsr352-core:jar:7.0.0-SNAPSHOT -> [Help 1]

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
20 Code Smells

82.3% Coverage
0.4% Duplication