[jboss-jira] [JBoss JIRA] (WFLY-4517) Do not expose Infinispan bits to deployments importing the Hibernate main module
[
https://issues.jboss.org/browse/WFLY-4517?page=com.atlassian.jira.plugin....
]
Scott Marlow commented on WFLY-4517:
------------------------------------
Currently, we have:
org.hibernate:main which has hibernate-core, hibernate-infinispan,
hibernate-entitymanager
If we move hibernate-infinispan to a separate static module, the application classpath
will still only contain the org.hibernate:main static module, which happens not contain
the hibernate-infinispan classes anymore but I assume would still reference them.
In other words, org.hibernate.main currently is a {hibernate-core, hibernate-infinispan,
hibernate-entitymanager} and has a reference to org.infinispan:main. If I understand this
jira correctly, the change will be that org.hibernate.main is a {hibernate-code,
hibernate-entitymanager} and has a reference to hibernate-infinspan (which has a reference
to org.infinispan:main).
Do not expose Infinispan bits to deployments importing the Hibernate
main module
--------------------------------------------------------------------------------
Key: WFLY-4517
URL: https://issues.jboss.org/browse/WFLY-4517
Project: WildFly
Issue Type: Enhancement
Components: JPA / Hibernate
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
This is mainly a follow up to
https://bugzilla.redhat.com/show_bug.cgi?id=1202911
But also a consequence of difficulties I had with Hibernate Search (which depends on both
latest Infinispan and the Hibernate version in WildFly), and Hibernate OGM (which requires
Hibernate ORM but has strong coupling with specific versions of Infinispan).
The gist of the problem is that the module org.hibernate:main includes the integration
code with Infinispan for second level caching.
While I agree people will want to enable the second level caching, I don't think they
should be exposed to it, so I'll propose some changes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)