On 10/21/2015 11:43 AM, Sanne Grinovero wrote: > On 21 October 2015 at 16:37, Scott Marlow <smar...@redhat.com> wrote: >> >> >> On 10/21/2015 10:48 AM, Sanne Grinovero wrote: >>> >>> Hi Scott, >>> I would prefer to have ORM accept instances, and so not need the >>> bi-directional dependency across modules. >>> >>> Hibernate OGM already bundles/depends on some ORM classes but it would >>> be much better for everyone if we could keep flexibility about which >>> versions exactly. >>> >>> Regarding 2LC: is the RegionFactory the only thing which is currently >>> being injected as classname rather than instance? >> >> >> Yes, that is the only classname setting that Jipijapa depends on currently. >> >>> If so I think this would be acceptable for a first preview version, >>> but I'd still prefer we could clean that up soon. >> >> >> We could start by not specifying the RegionFactory in the Jipijapa-OGM. >> >>> >>> In terms of module dependencies: Jipijapa/OGM should depend on a (user >>> selectable) slot of Hibernate OGM. The Hibernate OGM module will >>> export the dependency of Hibernate ORM which it targets, so the >>> Jipijapa/OGM module would not need to depend directly on any ORM >>> module. >> >> >> As of yet, I don't think that Jipijapa-OGM needs to depend directly on any >> OGM classes (biggest initial improvement is to specify the SCANNER so we >> automatically recognize entity classes in VFS based deployments). > > You're talking about compile time: yes you should be able to compile > Jipijapa-OGM by simply having Maven point to the correct version of > Hibernate ORM.
I was actually thinking runtime, not compile time. > > But I'm pointing out that the module XML definition should *not* > depend on the hibernate-orm main slot, but only to the slot containing > the configured Hibernate OGM module: > this way the OGM module packager can specify which ORM version to use, > and export that to clients like jipijapa-ogm and/or end users. Thanks for explaining, this makes sense. > > Thanks, > Sanne > >> >> >>> >>> Thanks, >>> Sanne >>> >>> >>> >>> On 21 October 2015 at 15:14, Scott Marlow <smar...@redhat.com> wrote: >>>> >>>> Hi, >>>> >>>> After our discussion last week about improving OGM use on WildFly (by >>>> adding a Jipijapa integration adapter for OGM), I wanted to share some >>>> feedback. >>>> >>>> A few years ago, we decided that having a 1-1 (bidirectional) dependency >>>> between ORM + the Jipijapa adapter was okay. With OGM, we need to >>>> discuss again. I think that our choices are to update ORM properties >>>> that identify class names, to also allow a class instance to be >>>> specified. This doesn't have to be all ORM integration properties but >>>> likely should include the ones currently set by Jipijapa. >>>> >>>> hibernate.cache.region.factory_class is currently used by Jipijapa to >>>> specify the name of the cache region factory class name. I think this >>>> implies that the Hibernate ORM classloader will need access to the >>>> Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, >>>> the ORM module (org.hibernate:main) depends on the >>>> org.hibernate.jipijapa-hibernate5:main module to resolve this class. >>>> >>>> Some alternatives to changing hibernate.cache.region.factory_class to >>>> allow a class to be specified: >>>> >>>> 1. OGM could bundle the ORM classes or depend on a duplicate ORM module >>>> (with a dependency on a jipi_ogm module). >>>> >>>> 2. OGM could avoid using the 2lc on WildFly. >>>> >>>> Any preferences or suggestions? >>>> >>>> Scott >>>> _______________________________________________ >>>> 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
