[hibernate-dev] Modularization of Search
sanne.grinovero at gmail.com
Tue Mar 16 13:04:12 EDT 2010
2010/3/16 Hardy Ferentschik <hibernate at ferentschik.de>:
> 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
> 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
> 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
> WDYT? Also which classes are we really interested in publishing in
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 - :
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
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
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
Related to : HSEARCH-228
More information about the hibernate-dev