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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev