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" <gun...@hibernate.org> wrote: > Hi, > > 2016-10-27 4:27 GMT+02:00 Scott Marlow <smar...@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@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
