[hibernate-dev] [OGM] WildFly modules imposing versions
I’ve upgraded the OGM demo to OGM 5.1 Final (from CR1). Again I’ve got deployment errors because it does not find the specific search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment. Is that the behavior we want? Do we want the OGM module to impose specific versions of Hibernate Search to work? I don’t even use Hibernate Search for the demo… How can we improve things? Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] WildFly modules imposing versions
I'll have a look,I would expect that modules with the same family would work. I suspect we used the specific version instead of the family version somewhere, I'll check Davide On Tue, Mar 7, 2017 at 9:43 AM, Emmanuel Bernard wrote: > I’ve upgraded the OGM demo to OGM 5.1 Final (from CR1). > > Again I’ve got deployment errors because it does not find the specific search > version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment. > Is that the behavior we want? Do we want the OGM module to impose specific > versions of Hibernate Search to work? I don’t even use Hibernate Search for > the demo… > > How can we improve things? > > Emmanuel > ___ > 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
Re: [hibernate-dev] [OGM] WildFly modules imposing versions
Hibernate Search was meant to be an *optional* dependency of Hibernate OGM core: - org.hibernate.ogm.cfg.impl.HibernateSearchIntegration.searchIsAvailable() However there's an import statement which slipped into the OgmEntityPersister, just for the sake of javadoc linking. I'm not sure if that might be a problem, but it could be worth making sure we compile all OGM core w/o Search on the classpath. So that's about *real* runtime requirements. For modules it depends on the module descriptors: the `org.hibernate.ogm` module has an *optional* dependency to the Hibernate Search module, so not having the module should be fine. However, there is a non-official[1] Hibernate Search module included in the OGM distribution, so you should have the right module already. Also remember that JipiJapa might automatically include the Hibernate Search "main" slot from WildFly. AFAIK this should only happen if any entity is marked @Indexed - so it shouldn't affect you since you're not using it, but I never tested for the not-include requirement. You might want to exclude the WildFly copy Hibernate Search explicitly by setting: - wildfly.jpa.hibernate.search.module=none or set it to the OGM specific module. - wildfly.jpa.hibernate.search.module=org.hibernate.search.orm:5.6.1.Final-orm51 [1] "non-official" as in that's not the Hibernate Search module released by the Hibernate Search project, it's a re-packaging which happens during the OGM build. > How can we improve things? I suspect we need to work on JipiJapa, better tests & docs. The main problems though are caused by the desire of using an ORM version which is not the one from WildFly, maybe we should just avoid that - or work with WildFly to make ORM upgrades easier. On 7 March 2017 at 09:43, Emmanuel Bernard wrote: > I’ve upgraded the OGM demo to OGM 5.1 Final (from CR1). > > Again I’ve got deployment errors because it does not find the specific search > version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment. > Is that the behavior we want? Do we want the OGM module to impose specific > versions of Hibernate Search to work? I don’t even use Hibernate Search for > the demo… > > How can we improve things? > > Emmanuel > ___ > 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
Re: [hibernate-dev] [OGM] WildFly modules imposing versions
> However there's an import statement which slipped into the > OgmEntityPersister, just for the sake of javadoc linking. I'm not sure > if that might be a problem, but it could be worth making sure we > compile all OGM core w/o Search on the classpath. The imported type is not referenced in the class file as the type isn't used in code, so this will not cause problems. But the import is actually even wrong, as OGM's ErrorHandler type should be linked here, not the one from HSEARCH. 2017-03-07 11:36 GMT+01:00 Sanne Grinovero : > Hibernate Search was meant to be an *optional* dependency of Hibernate OGM > core: > - org.hibernate.ogm.cfg.impl.HibernateSearchIntegration.searchIsAvailable() > > However there's an import statement which slipped into the > OgmEntityPersister, just for the sake of javadoc linking. I'm not sure > if that might be a problem, but it could be worth making sure we > compile all OGM core w/o Search on the classpath. > > So that's about *real* runtime requirements. > > For modules it depends on the module descriptors: > > the `org.hibernate.ogm` module has an *optional* dependency to the > Hibernate Search module, so not having the module should be fine. > > However, there is a non-official[1] Hibernate Search module included > in the OGM distribution, so you should have the right module already. > > Also remember that JipiJapa might automatically include the Hibernate > Search "main" slot from WildFly. AFAIK this should only happen if any > entity is marked @Indexed - so it shouldn't affect you since you're > not using it, but I never tested for the not-include requirement. You > might want to exclude the WildFly copy Hibernate Search explicitly by > setting: > > - wildfly.jpa.hibernate.search.module=none > > or set it to the OGM specific module. > > - > wildfly.jpa.hibernate.search.module=org.hibernate.search.orm:5.6.1.Final-orm51 > > [1] "non-official" as in that's not the Hibernate Search module > released by the Hibernate Search project, it's a re-packaging which > happens during the OGM build. > >> How can we improve things? > > I suspect we need to work on JipiJapa, better tests & docs. The main > problems though are caused by the desire of using an ORM version which > is not the one from WildFly, maybe we should just avoid that - or work > with WildFly to make ORM upgrades easier. > > > On 7 March 2017 at 09:43, Emmanuel Bernard wrote: >> I’ve upgraded the OGM demo to OGM 5.1 Final (from CR1). >> >> Again I’ve got deployment errors because it does not find the specific >> search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment. >> Is that the behavior we want? Do we want the OGM module to impose specific >> versions of Hibernate Search to work? I don’t even use Hibernate Search for >> the demo… >> >> How can we improve things? >> >> Emmanuel >> ___ >> 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 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] WildFly modules imposing versions
On 7 March 2017 at 10:47, Gunnar Morling wrote: >> However there's an import statement which slipped into the >> OgmEntityPersister, just for the sake of javadoc linking. I'm not sure >> if that might be a problem, but it could be worth making sure we >> compile all OGM core w/o Search on the classpath. > > The imported type is not referenced in the class file as the type > isn't used in code, so this will not cause problems. > > But the import is actually even wrong, as OGM's ErrorHandler type > should be linked here, not the one from HSEARCH. Right, I figured that. I was just fixing it.. > > 2017-03-07 11:36 GMT+01:00 Sanne Grinovero : >> Hibernate Search was meant to be an *optional* dependency of Hibernate OGM >> core: >> - org.hibernate.ogm.cfg.impl.HibernateSearchIntegration.searchIsAvailable() >> >> However there's an import statement which slipped into the >> OgmEntityPersister, just for the sake of javadoc linking. I'm not sure >> if that might be a problem, but it could be worth making sure we >> compile all OGM core w/o Search on the classpath. >> >> So that's about *real* runtime requirements. >> >> For modules it depends on the module descriptors: >> >> the `org.hibernate.ogm` module has an *optional* dependency to the >> Hibernate Search module, so not having the module should be fine. >> >> However, there is a non-official[1] Hibernate Search module included >> in the OGM distribution, so you should have the right module already. >> >> Also remember that JipiJapa might automatically include the Hibernate >> Search "main" slot from WildFly. AFAIK this should only happen if any >> entity is marked @Indexed - so it shouldn't affect you since you're >> not using it, but I never tested for the not-include requirement. You >> might want to exclude the WildFly copy Hibernate Search explicitly by >> setting: >> >> - wildfly.jpa.hibernate.search.module=none >> >> or set it to the OGM specific module. >> >> - >> wildfly.jpa.hibernate.search.module=org.hibernate.search.orm:5.6.1.Final-orm51 >> >> [1] "non-official" as in that's not the Hibernate Search module >> released by the Hibernate Search project, it's a re-packaging which >> happens during the OGM build. >> >>> How can we improve things? >> >> I suspect we need to work on JipiJapa, better tests & docs. The main >> problems though are caused by the desire of using an ORM version which >> is not the one from WildFly, maybe we should just avoid that - or work >> with WildFly to make ORM upgrades easier. >> >> >> On 7 March 2017 at 09:43, Emmanuel Bernard wrote: >>> I’ve upgraded the OGM demo to OGM 5.1 Final (from CR1). >>> >>> Again I’ve got deployment errors because it does not find the specific >>> search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment. >>> Is that the behavior we want? Do we want the OGM module to impose specific >>> versions of Hibernate Search to work? I don’t even use Hibernate Search for >>> the demo… >>> >>> How can we improve things? >>> >>> Emmanuel >>> ___ >>> 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 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
