Make JTA a provided (non-transitive) dependency
Description
Activity
Steve Ebersole January 8, 2016 at 2:59 PM
Hibernate exposes javax.transaction.Synchronization from a public API. Whether you use JTA or not, you can register a JTA Synchronization for transaction callbacks. So the JTA spec jar is a non-optional dependency. Allowing this to become non-transitive was a mistake which will be reverted: see HHH-10307.
Maël Lavault December 30, 2015 at 8:45 AM
Does this mean we have to provide JTA event if we don't need it ? We just updated to hibernate 5.0.6 and now it complains that JTA is missing, which is weird because we don't use it at all (we use hibernate through spring-transaction/spring-data-jpa)
Steve Ebersole November 17, 2015 at 4:21 PM
(2) was the route I ended up taking. (2) automatically feeds (3).
Brett Meyer November 17, 2015 at 3:29 PM
Hey @Steve Ebersole, sorry, didn't see this before now. I'd argue #3 should be the case, if it's not already – most Karaf/Fuse use cases will involve JTA anyway. Now, how that gets there is up to you. #1 would be fine, but if it needs to be #2 in order to generate #3, that's fine as well.
Steve Ebersole November 4, 2015 at 9:30 PM
@Brett Meyer It is in the real feature as of now because we expose it transitively from hibernate-core. That's what Sanne wants to change though. So as far as hibernate-osgi, the choices would be to either:
add JTA to the test dependencies
add JTA to the hibernate-osgi transitively dependencies
add JTA to the hibernate-osgi Karaf feature file.
Not sure which is "best".
Due to the proliferation of JTA artifacts under various GAVs, Hibernate exporting one as a transitive dependency can cause problems in environments where another GAV is used.
This should be marked as
providedto make sure people don't get it on classpath without explicitly asking for it.