The JTA API is a tiny jar. I am not so concerned with "users working with JDBC exclusively" being "surprised" that JTA is needed. JTA's Synchronization is a well understood pattern.
On Wed, Jan 6, 2016 at 11:22 AM Gunnar Morling <gun...@hibernate.org> wrote: > I can see how users working with JDBC exclusively can be surprised by > the fact that the JTA API is still needed. I think it boils down to > these options: > > 1) Push back the need for JTA types to the case of actually using JTA > (e.g. by splitting up the CoreMessageLogger interface etc.) > > In my experience classes (such as org.hibernate.Transaction) can be > loaded also if they contain method signatures with absent types (e.g. > registerSynchronization()), as long as these methods are not accessed > (e.g. invoked or obtained via Class#getDeclaredMethods()). Plain > imports are irrelevant (I don't think they are even present a concept > in byte code), actual access of methods/fields with missing types will > cause errors. So this could be doable, assuming that ORM itself > doesn't work with JTA types in the case of JDBC-only. > > 2) If that's not feasible, JTA is non-optional really, leaving us to > decide whether a) to "suggest" a JTA API version by transitively > exposing it (which the user then still could replace) or b) always > require the user to provide it. > > My personal preference would be 1) (assuming it is sensibly doable), > followed by 2a) followed by 2b). Granted, 1) may be hard to test and > also I am not sure whether that behaviour I described is guaranteed by > the spec or only is exposed by specific JVMs. > > --Gunnar > > > > 2016-01-06 17:59 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > > There is nothing "EE AS" specific in any of those jars I mentioned. They > > are all simply different jars of the JTA API. Every EE spec has the same > > problem. That is the point you are missing. > > > > TBH I forget the history as to why the JBoss's JTA jar (again, nothing > > JBoss specific there, just the JTA API) was used rather than > > javax.transaction:jta. That predates our move to git and would require > > some digging. Later we moved from the JBoss JTA jar to the Geronimo > > version because the JBoss one had some problem in its OSGi metadata > > (the javax.transaction:jta > > jar provides zero OSGi metadata btw). > > > > > > > > On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <mihalcea.v...@gmail.com> > > wrote: > > > >> I thought it was just the javax dependency. > >> Supplying all those Java EE AS dependency is something else, as you > >> pointed out. > >> > >> Adding some separate modules with those dependencies is not an option > >> either: hibernate-wildfly, hibernate-geronimo, etc? > >> > >> Vlad > >> > >> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <st...@hibernate.org> > >> wrote: > >> > >>> Vlad, the issue is not "someone doesn't want it". In fact, for the > most > >>> part because of our decision to use the JTA contracts in our API "(not) > >>> wanting it" is not really an option. > >>> > >>> The issue here is the proliferation of JTA jars (maven coords). We > have > >>> the Geronimo jars, the JBoss/WildFly jars, etc. So the concerns is > when > >>> someone wants to use one of the jars other than the one we provide > >>> transitively. Yes, the result is the same: they still need to exclude > the > >>> one we provide transitively. > >>> > >>> I have argued this for ages... I think this is a fundamental missing > >>> construct in Maven dependency mappings: the ability to say "remap" all > >>> references to a particular spec jar coord to another. Gradle luckily > >>> allows users to do that (granted somewhat verbosely), Maven simply > does not. > >>> > >>> > >>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea <mihalcea.v...@gmail.com > > > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> Since the Hibernate core relies on the JTA dependency, I think we > >>>> shouldn't provide that dependency. > >>>> When someone doesn't want it he should explicitly mark that (e.g. > Maven > >>>> exclude). > >>>> This way we can also address the parent issue: > >>>> https://hibernate.atlassian.net/browse/HHH-10178 > >>>> > >>>> Vlad > >>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <st...@hibernate.org> > >>>> wrote: > >>>> > >>>>> HHH-10307[1] is another issue we need to get some consensus on. > >>>>> Initially > >>>>> we had removed JTA as a transitive dependency, but that is not really > >>>>> valid. We need to discuss alternatives and options. > >>>>> > >>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307 > >>>>> > >>>> _______________________________________________ > >>>>> hibernate-dev mailing list > >>>>> hibernate-dev@lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>> > >>>> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
