I don't have a full grasp of the consequences, I'll need to think about it. Here are a few comments in the mean time. SearchFactory is not a SPI, it is used by application developers. For scalability reasons, I would be tempted to move the orm module classes out of the root package. But that is definitely the most impactful of the two moves.
Emmanuel On Tue 2014-03-25 22:11, Hardy Ferentschik wrote: > Hi there, > > As part of my work for making Search OSGi ready [1], I am looking into > addressing HSEARCH-1560 [2] which is about > split packages which we have between some of our Search bundles (or modules > to use Maven lingo). > > Basically a split package "is caused where two or more bundles export the > same package name and version, usually with different contents”. [3] > In terms of OSGi, split packages are bad and should be avoided. There exists > a work around [3], but afaiu it is frowned upon. > While working on an integration test trying to run Search in Apache Karaf, I > was running into this problem and basically needed (for the time being) > revert to the mentioned work around. > > The biggest for getting rid of split packages is org.hibernate.search which > is a split packages between the engine and orm bundle. In > org.hibernate.search of engine > we have: > - Environment, > - FullTextFilter, > - ProjectionConstants, > - SearchException, > - SearchFactory > - Version. > > org.hibernate.search of orm contains: > - FullTextQuery, > - FullTextSession, > - FullTextSharedSessionBuilder, > - MassIndexer > - Search. > > As you can see, these are quite central classes and moving any of them > around will break existing code (even though updating just requires > to change import statements). If we are serious with OSGi we should address > this. We always said, that Search 5 is the release where we can break > API backwards compatibility. So if we want to do this, we should do it now. > On the other hand, it is a big change. > > I went ahead and tried to refactor org.hibernate.search in engine, applying > the following changes: > > org.hibernate.search.Environment -> > org.hibernate.search.cfg.Environment > org.hibernate.search.SearchFactory -> > org.hibernate.search.spi.SearchFactory > org.hibernate.search.SearchException -> > org.hibernate.search.exception.SearchException > org.hibernate.search.FullTextFilter -> > org.hibernate.search.filter.FullTextFilter > org.hibernate.search.Version -> > org.hibernate.search.engine.Version > > Some of these changes I actually find quite fitting independently of the > split package problem. FullTextFilter seems to have found its true home now > and Version and Environment don’t seem too bad either. The big change is > SearchFactory and .SearchException. > > WDYT? Is this package refactoring something worth doing and if so what do you > think about the new locations of the classes? Any better suggestions? > Or do you think the orm bundle should be refactored instead? > > You can see the preliminary result here [4]. > > —Hardy > > [1] https://hibernate.atlassian.net/browse/HSEARCH-1465 > [2] https://hibernate.atlassian.net/browse/HSEARCH-1560 > [3] http://wiki.osgi.org/wiki/Split_Packages > [4] https://github.com/hferentschik/hibernate-search/compare/HSEARCH-1560 > _______________________________________________ > 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
