I'd prefer 1). The less dependencies I need, the better.
2016-01-06 18:36 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > 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 <st...@hibernate.org> 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 <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
