[hibernate-dev] HHH-10307 - JTA dependency

[Steve Ebersole]

Haha,  we'll agree to disagree on that I guess :)

On Wed, Jan 6, 2016 at 11:48 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> I'd prefer 1). The less dependencies I need, the better.
>
> 2016-01-06 18:36 GMT+01:00 Steve Ebersole <steve at 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 <steve at 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 <gunnar at 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 <steve at 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.vlad at 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 <steve at 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.vlad at 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 at 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 at lists.jboss.org
> >>> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >>>>>
> >>> >>>>
> >>> >>
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>