2010/3/16 Hardy Ferentschik <hibern...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
