Would be interesting to know why JipiJapa is depending on it. In a quick
search I couldn't spot any actual usages.
JPADependencyProcessor adds a dependency to "org.javassist", maybe that
could be avoided by having the ORM module re-export the version of JipiJipa
it is using? For that he module ZIP would have to contain a module for the
new JipiJapa version and ORM's module.xml would depend on it and re-export
2016-10-26 23:19 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
there's a conflict in the Javassist versions of the WildFly modules of
Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not
familiar with this functionality.
The module declares *both*:
- a dependency to the WildFly provided Javassist: <module
- inclusion of Hibernate's own version of Javassist: <resource-root
Having both is causing trouble as they are both visible to the
Hibernate classloader; however I couldn't score a quick win with the
testsuiste by disabling either (all tests using these modules in the
Hibernate Search testsuite fail).
I suspect the problem is that JipiJapa also depends on the <module
name="org.javassist"/>, while ORM obviously needs the more recent
version of it.
I'm not familiar with what JipiJapa's business around Javassist; could
we keep the two clearly separated?
Especially if we want to make Byte Buddy a viable alternative, I
suspect the solution is that JipiJapa should not depend on Javassist
directly, but invoke a generic instrumentation SPI on Hibernate; also
with JipiJapa not able to see Javassist at all, we'd be in control of
the one and only Javassist version visible to ORM: the one we compile
and test with.
hibernate-dev mailing list