On 14 January 2014 11:23, Hardy Ferentschik <ha...@hibernate.org> wrote: > > On 14 Jan 2014, at 00:06, Sanne Grinovero <sa...@hibernate.org> wrote: > >> as you might already know by following the WildFly developer's mailing >> list, most of the Hibernate Search jars and dependencies (Lucene) are >> now included in the application server as modules. > > Right. Still not sure whether this is such a great idea, but I guess it is > too late.
Not sure either, but worst case we have our own release, so there probably are no negative aspects (?). More on this below. >> Just a couple of small adjustments are needed to make it possible for >> Hibernate users to also take advantage of it, so I'd think we should >> make these adjustments to make it more useful? >> >> This is what I'm thinking: >> - The hibernate-search-orm jar is missing (an essential jar for our purposes) >> -> add a module > > +1 Does this really need a separate module? It's probably not strictly needed, but I think it's preferable so that people can use a different version of it. Also, it's our tested configuration. >> - No additional analyzers are included >> -> see how optional modules work, so that - while we won't ship all >> those dependencies - it's still easy to add when you need one > > Is there some info about “optional” modules? I find information about modules > in general hard to find. I wasn't aware of it either, I just learned about it in the face to face meeting. Need to try it out though.. > >> - Jipijapa should help? >> -> should we make Hibernate Search available to deployments >> whenever Hibernate ORM is made available? > > Per default? So if there are no indexed entities nothing happens and if there > are > Search gets automatically enabled? Is this what you are saying? Yes. Should be great for usability. > >> - Get it to a reasonable version: it's including 4.5.0.Alpha2 now >> -> we need to release a Beta soon, any volunteer? I'm stuck on an >> island with extremely slow connectivity. > > I can do a release. Just wondering whether it should be a CR already? > The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we > already upgraded now > to 4.3.0.Final (just not released yet). So it would really be time to get > 4.5.0.Final out. > We could cut a CR release and if nothing comes up promote it to 4.5 final in > a couple of weeks. We also have the Infinispan indexmanager on the roadmap. All work was done a year ago already, and the Infinispan issues which prevented me to merge it at the time are fixed, so I should only need to rebase it. I would love to merge it, but let's set a deadline for it.. if I can't make it we release without it again :-( Also I'm worried about HSEARCH-1260 and Guillaume's report. It would be nice to get rid of those issues by applying the cleanup I've suggested on that thread. I fundamentally agree that if we don't address these quickly, we should aim at a quick Final, still let's not rush it too much as WildFly doesn't stricly need a Final from us (or at least I wasn't asked for one). > >> - Contribute some integration tests to WildFly: there aren't any >> today verifying the included modules > > +1 > >> What shall we do about our modules distribution? I think it would be >> nice to continue maintaining that, so that we can make frequent >> releases and that would allow users to use a different version than >> what they would get in WildFly - if they want to. > > Not sure. The module won’t be a pure drop-in anymore. Now the module needs > to make sure that existing module(s) get properly “reconfigured”. What I mean > is that > we might have to do more than extracting a tar ball. We might need to > remove/change > existing files as well. Is it not easier to provide instructions on how to > update the exiting modules? Changing existing modules is highly discouraged and creates problems to potentially deploying other frameworks who depend on it: there should be a way to override the version that a specific deployment wants to use. This way, we can make it a "pure drop-in", without changing any existing files. > Unfortunately, this comes at a non optimal point in time. Not only will it > take time from the > Lucene 4 migration (aka Search 5), but if Search 4.x gets included now we > probably will get very > quickly people asking on how to use Search 5 with Wildfly. If nothing else a > lot of dependencies > change at this point. It won’t be a simple replace of a single jar +1, that's why I think we should keep _also_ releasing our own modules. > Will/Can CapeDwarf and clustering also switch to Search 5 once we start > making releases? We're going to make it very interesting for them, so I'm sure they'll find a solution :-) Very likely, next version of WildFly will use 5, but now that it's approaching a Final version, it's probably not too bad that we provide a stable version. -- Sanne > > —Hardy > _______________________________________________ > 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
