2010/3/16 Hardy Ferentschik <hibernate(a)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