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 <sa...@hibernate.org> wrote: > Ok well that's also odd isn't it? > > > On 27 Oct 2016 10:38, "Gunnar Morling" <gun...@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 <sa...@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" <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