[hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

[Scott Marlow]

Only a WildFly deployment unit processor (DUP) can add dependencies to
an application deployment.  Jipijapa is not a DUP.

On Thu, Oct 27, 2016 at 6:12 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Ok well that's also odd isn't it?
>
>
> On 27 Oct 2016 10:38, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>>
>> No, JPADependencyProcessor - which is adding the dependency - is part of
>> "wildfly-jpa", not "jipijapa-hibernate".
>>
>>
>> 2016-10-27 11:23 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>> We could fix 1) as well by incorporating the sources for
>>> jipijapa-hibernate52 in ORM.
>>>
>>> I think it belongs within Hibernate, as it won't be the last time that a
>>> new ORM version requires some adaptation of bootstrap.
>>>
>>>
>>> On 27 Oct 2016 09:51, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> 2016-10-27 4:27 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>>>
>>>> >
>>>> > > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM
>>>> > > module
>>>> > (the WF module) export Javassist.  Not the application.
>>>> >
>>>>
>>>> Right, Hibernate ORM's module should be the one exposing it, not the
>>>> application nor JipiJapa.
>>>>
>>>> This allows the ORM module to expose the right version of Javassist (or
>>>> none at all eventually) without requiring JipiJapa to have the knowledge
>>>> about this. As things stand, Javassist can be considered as part of
>>>> ORM's
>>>> API, hence it's module.xml should be the one making it available to the
>>>> user.
>>>>
>>>> Of course eventually we don't want to expose Javassist at all, but as
>>>> long
>>>> as we do, the ORM module should be in charge of doing so.
>>>>
>>>> > >
>>>> >
>>>> > I agree, that is what our WF pull request did, which I think is an
>>>> > incremental improvement but that wasn't approved for the reason I
>>>> > gave.
>>>> >
>>>>
>>>> I don't quite get the reasoning here. We all agree that Javassist
>>>> shouldn't
>>>> be exposed at all (and there is good progress being made towards this by
>>>> using ByteBuddy).
>>>>
>>>> But as long as we do, leaving this responsibility to the ORM module is
>>>> the
>>>> right thing to do IMO. E.g. what if a JPA provider doesn't need
>>>> Javassist
>>>> at all? Still JipiJapa would currently add it to the deployment.
>>>>
>>>> I've done the following changes locally:
>>>>
>>>> 1) Altered JPADependencyProcessor to not add the Javassist dependency to
>>>> the deployment
>>>> 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist
>>>> 3) Added a new module for the latest Javassist
>>>> 4) Altered module.xml of ORM itself to depend on that new module *and*
>>>> re-export it
>>>>
>>>> With all this in place, the tests in Hibernate Search pass successfully.
>>>>
>>>> Scott, do you think we can try another PR with that? Again, it doesn't
>>>> change things in terms of exposure of Javassist to the application (it
>>>> is
>>>> exposed, just as it was before). But it puts the responsibility for
>>>> doing
>>>> so to ORM's module, allowing us (via the ORM module ZIP we provide) to
>>>> expose a newer Javassist version as needed.
>>>>
>>>> Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change
>>>> that
>>>> needs to be done on the WF side, at least I don't see how this could be
>>>> overridden?
>>>>
>>>> I.e. the module ZIP is rather pointless atm. and we don't have a good
>>>> way
>>>> to put the latest ORM into WF user's hands. Would be nice to change
>>>> this.
>>>>
>>>> >> Is the ORM testsuite building the WildFly app server from source?
>>>> > >
>>>> > >
>>>> > > Good god no :)
>>>> > >
>>>> > >
>>>> > >>
>>>> > >> Other option would be to use ByteBuddy to generate proxies instead
>>>> > >> of
>>>> > >> Javassist to eliminate the application dependency on the Javassist
>>>> > >> runtime classes.
>>>> > >
>>>> > >
>>>> > >
>>>> > > Rafael Winterhalter is actually pretty far along on defining support
>>>> > > for
>>>> > Byte Buddy in Hibernate[1].  So that might soon be an option.
>>>> > >
>>>> > > [1] https://hibernate.atlassian.net/browse/HHH-11152
>>>> > >
>>>> > +100 :)
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>