2011/2/9 Rupert Westenthaler <[email protected]>: >> >> Both are alternative yard providers if I understand correctly. You can >> either run solr using an external server or use the solr classes >> inside the stanbol JVM. >> > In principle correct. However the SolrProvider is no Yard > implementation. There is only a singe SolrYard implementation that > requires a org.apache.solr.client.solrj.SolrServer instance. The > SolrProvider is just responsible of providing this SolrServer > instance. >> >> So we could have entityhub/yard/providers with solr and embeddedsolr >> as subfolders instead. But I would rather have them all grouped >> together in the same OSGi bundle unless Rupert has a technical reason >> to avoid this. > > The embeddedSolrServer requires all the Solr and Lucene dependencies > but Users that do not use an embedded Solr server do not need all this > stuff (~3MB jar's). > > I would have preferred to keep all the stuff needed to use remote > SolrServer within the SolrYard bundle and only move the > EmbeddedSolrServer stuff to an own bundle, but that was not possible > because of an cyclic build dependency (The unit tests of the SolrYard > use an EmbeddedSolrServer and the EmbeddedSolrServer does implement > the SolrProvider interface and would therefore has an dependency to > the SolrYard bundle). > > So in my opinion there are only two possibilities: > (1) creating three bundles (SolrYard, SolrProvider (interface > definition and implementaion for remote SolrServer) and > EmbeddedSolrProvider) > (2) move everything into the SolrYard bundle (and add the ~3MB Solr > and Lucene dependencies to it).
I would rather vote for option 2: 3MB is small in comparison of the size of a pre-filled yard index anyway that the user will have to download anyway to make use of such an yard in practice. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel
