[jboss-jira] [JBoss JIRA] (WFLY-4517) Do not expose Infinispan bits to deployments importing the Hibernate main module

[Scott Marlow (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058986#comment-13058986 ] 

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)