To get some clarification: When using solely JDBC, what is required at runtime: a) the JTA API packages only b) JTA API and implementation c) none of the above ? 2016-01-06 16:12 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <steve(a)hibernate.org&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

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 <steve(a)hibernate.org&gt; 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.vlad(a)gmail.com&gt; > 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 <steve(a)hibernate.org&gt; >> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>

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 <steve(a)hibernate.org&gt;: > 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.vlad(a)gmail.com&gt; > 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 <steve(a)hibernate.org&gt; >> 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.vlad(a)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 <steve(a)hibernate.org&gt; >>>> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

I'll put it this way Gunnar, as a user would you prefer: 1) org.hibernate.Transaction#addCallback( org.hibernate.TransactionCallback ) 2) org.hibernate.Transaction#addCallback( javax.transaction.Synchronization ) ? On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > 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 <gunnar(a)hibernate.org&gt; > 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 <steve(a)hibernate.org&gt;: >> > 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.vlad(a)gmail.com&gt; >> > 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 <steve(a)hibernate.org&gt; >> >> 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.vlad(a)gmail.com&gt; >> >>> 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 <steve(a)hibernate.org&gt; >> >>>> 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(a)lists.jboss.org >> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>>> >> >>>> >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

Haha, we'll agree to disagree on that I guess :) On Wed, Jan 6, 2016 at 11:48 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > I'd prefer 1). The less dependencies I need, the better. > > 2016-01-06 18:36 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > I'll put it this way Gunnar, as a user would you prefer: > > > > 1) org.hibernate.Transaction#addCallback( > org.hibernate.TransactionCallback > > ) > > 2) org.hibernate.Transaction#addCallback( > javax.transaction.Synchronization > > ) > > > > ? > > > > > > > > On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> > >> 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 <gunnar(a)hibernate.org&gt; > >> 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 <steve(a)hibernate.org&gt;: > >>> > 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.vlad(a)gmail.com&gt; > >>> > 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 < > steve(a)hibernate.org&gt; > >>> >> 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.vlad(a)gmail.com&gt; > >>> >>> 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 < > steve(a)hibernate.org&gt; > >>> >>>> 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(a)lists.jboss.org > >>> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> >>>>> > >>> >>>> > >>> >> > >>> > _______________________________________________ > >>> > hibernate-dev mailing list > >>> > hibernate-dev(a)lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >