Hibernate Search has many additional dependencies on top of just ORM.. would the WildFly team be happy with that? I always assumed that would not be considered acceptable.
Also with such a solution people won't have flexibility on the version; I know people don't have it with ORM either - unless they bring their own - but to make upgrades possible in existing projects it is extremely useful to be able to update one dependency at a time, which I suspect would not be possible anymore: upgrade ORM first, run the tests, upgrade Search, run the tests. Nailing down one version - by using the ORM provided by an application server - makes this harder, but nailing down both versions forces people to upgrade both at the same time: if there's an issue it will be much harder to figure out the area. Sanne On 6 June 2013 18:42, Scott Marlow <smar...@redhat.com> wrote: > On 06/06/2013 11:49 AM, Emmanuel Bernard wrote: >> On Thu 2013-06-06 11:31, Scott Marlow wrote: >>> >>> If the static Hibernate Search module, depends on a static Hibernate >>> ORM module in WildFly 8, I think that is fine, but applications >>> wouldn't be able to include their own Hibernate Search jars (since >>> the static Hibernate ORM module only sees services in the static >>> Hibernate Search module). >> >> That's one deployment and the one I did first (see my other email). >> >>> >>> For WildFly 8, do we want to allow applications to bundle its own >>> version of Hibernate Search that could work with bundled Hibernate >>> ORM jars? >> >> It's a bit confusing to me this whole business but AFAIU but if we >> could, yes that would be good. >> > > To handle application deployments that contain their own Hibernate > Search jars, we would need to make an adjustment. Instead of having the > Hibernate ORM module depend on the Hibernate Search module (this is what > we currently do in AS7 via 1-1 bidirectional dependencies), we would > need to include the Hibernate Search jars in the Hibernate ORM module. > This is specific to WildFly 8 (assuming my WF8 patch is merged in). > > If we don't put Hibernate Search into the ORM module, we will face the > same blocking issue that I saw very late on AS7, which is the JipiJapa > integration code module (used to be in AS7 codebase) depends on the > static Hibernate ORM module which conflicts with the Hibernate ORM jars > loaded by the application classloader. > > Also, keep in mind that In AS7, there was no JipiJapa project, so > applications couldn't easily include the JipiJapa integration classes > (point being that there were several blocking issues that prevented > Hibernate 4.x jars from being in the deployment). Of course, Hibernate > 3 jars were different as there is no Hibernate 3 static module in AS8 > (so applications could include Hibernate 3 jars). > > There were some other ways of dealing with service loading mentioned on > the "stinking donkey" thread [1] last year, but I'm not sure if any of > the alternatives would help application deployments to include Hibernate > ORM/Search/other jars. > > [1] > http://jboss-as7-development.1055759.n5.nabble.com/Modularity-is-the-spawn-of-Lucifer-and-a-stinking-donkey-td5697958.html > _______________________________________________ > 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
