[hibernate-dev] HHH-10307 - JTA dependency

[Steve Ebersole]

Scott Marlow... do you have any idea why we'd not just use
javax.transaction:jta ?

Brett Meyer... ^^ maybe something OSGi-related (because of manifests)?

On Thu, Jan 7, 2016 at 8:32 AM Steve Ebersole <steve at hibernate.org> wrote:

> 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
>>
>