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

[Sanne Grinovero]

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
>