2010/3/16 Emmanuel Bernard <emman...@hibernate.org>: > > On 16 mars 2010, at 20:05, Hardy Ferentschik wrote: > >> On Tue, 16 Mar 2010 15:38:40 -0300, Emmanuel Bernard >> <emman...@hibernate.org> wrote: >> >>> What's the list of all potential modules? Then let's see if we want to >>> minimize some or create bundles >>> >>> hibernate-search-core >> >> Here I had in mind to use just hibernate-search so that the main artifact >> keeps its name. >> >>> hibernate-search-hibernate >> >> Not sure what you envision to go in there. I did not have this on the list >> and I am not quite sure >> what would be in there. > > All the Hibernate specific APIs (FullTextQuery, FullTextSession) > >> >>> hibernate-search-jpa >> >> This is the one I want to avoid, since we really don't have any specific JPA >> code. The only use we have >> of JPA at the moment is that we use @Id as document id in case @DocumentId >> is not specified. This use >> is, however, via reflection and we never actually load any javax.persistence >> classes. In the testsuite >> we are making of course heavy use of JPA to build our tests. I might have an >> idea on how to deal with >> this. I don't think we need this module. > > All the JPA specific APIs (FullTextQuery, FullTextSession) > > That being said, I'm ok with merging some modules (the previous two are good > candidates) > >> >>> hibernate-search-jms >>> hibernate-search-jgroups >>> hibernate-search-infinispan >> >> I guess it makes sense to start creating modules for the different >> clustering solutions. I think >> this three modules will also make it more transparent what you need if you >> want to use clustering >> >>> hibernate-search-util >> >> I guess we could create this module, but I would like to avoid it. I guess I >> would then rather split >> out the test into a hibernate-search-testsuite > > Four options here: > - do this -util module > - do a -testsuite module > - do the test artifact (Sanne's current commit) > - do not split the 3 util classes out > > So far I think the last two solutions are the less annoying >
I don't feel comfortable in having the testing in a different module than what it's supposed to test, will be hard to prevent circular dependencies even if it was relating to some utilities. We don't have that much testing utilities, and as Emmanuel said before there's the chance of somebody committing without noticing a test failing in another module. >> >>> hibernate-search-testutil >> >> Ok I'm still confused about the differences between a hibernate-search-testutil and the "-util" module mentioned on the previous point. ? >> >>> hibernate-search-perftest >> >> I guess we could do this as well. >> >> >>> anything else? >> >> What did we decide on the solr analyzer framework? > > I want to make it a mandatory dependency. I made a mistake in putting it > optional in the first place. +1 IMHO it wasn't a mistake at the time, but as lucene+solr are converging more and more it looks like the way to go > _______________________________________________ > 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
