[hibernate-dev] Modularization of Search

Sanne Grinovero sanne.grinovero at gmail.com
Tue Mar 16 13:04:12 EDT 2010


2010/3/16 Hardy Ferentschik <hibernate at ferentschik.de>:
> Hi,
>
> I started on the modularization of Search (HSEARCH-468) and would like to
> get some feedback.

nice, the build is still working for me :)

> So far all I've done is to create a parent pom and push the main code into
> the hibernate-search module.
>
> The layout is now:
>
> pom.xml                     (parent)
> /hibernate-search           (the main code including tests)
> /hibernate-search-archetype (simple maven project used to generate a Maven
> Search archetype)
>
> This setup does not offer yet much new to the original setup, but at least
> we could now create
> a new submodule for the infinispan stuff.
>
> What I am trying to figure out now is how much further I should go with
> the current setup.
> We were talking about splitting out a module for test utilites
> (hibernate-search-testing),
> but it turns out that some of the testing utility classes depend on util
> classes form the
> main source tree. We could try to duplicate some of the classes into the
> hibernate-search-testing
> module (ugly) or we could do what core does and split even the actual
> tests out into
> maven module - hibernate-search-testsuite. This would leave us with
>
> /hibernate-search
> /hibernate-search-testing
> /hibernate-search-testsuite
>
> WDYT? Also which classes are we really interested in publishing in
> hibernate-search-testing?

It seems natural that the testsuite depends on the main code; so I'm
no sure I understood the alternative.
There are not many utilities for testing, currently just a couple of
classes; I usually use - for example - :
org.hibernate.search.test.util.AnalyzerUtils
org.hibernate.search.test.util.textbuilder.*
org.hibernate.search.test.SearchTestCase

but it's natural that we don't add much useful stuff as nobody can
depend on that; if the artifact was published it would make sense to
add more interesting things.

>
> To further complicate things we have this two profiles (with-optional-jars
> and without-optional-jars)
> in hibernate-search. The main reason for this setup is to allow to run
> surefire twice, once w/
> and once w/o the optional jars. The setup is really complicated and I
> would like to get rid of it.

I never understood the "optional jars" feature, it often looks like a
"poor man's modularization", or a trick to avoid modules explosion but
not the most robust approach.
I don't think the code would allow this easily, but wouldn't it make
sense to split the core support from the entitymanager support?
So in the jpa-search module you would add hard-dependency to jpa and
entitymanager, but not have them as dependencies in the
hibernate-search,
each one having it's own tests on the appropriate API.

> The obvious thing to do would be to have to testsuite problems, but I am
> afraid of module 'explosion'
> here. Any other suggestions?

Agree, I'm wary too of making too many modules. I'd suggest to keep it
simple for now and just add new modules if/when required, like the
infinispan one.
If you later find some clever way to split out jpa - or whole
hibernate core - we can discuss that in future with better insight.

One module I'd be glad to see is one to bring in benchmarks and
performance tests - we always avoided them as to not make them kill
productivity, but having them in a separate module would be nice - we
have some already, but are mostly disabled using a surefire
patternmatch.
Related to : HSEARCH-228

>
> --Hardy

Sanne




More information about the hibernate-dev mailing list