Hi,

I would also vote for option 2: The 3MB are not a problem since we do
not have the requirement to minimize our package size. I would guess
that If we want to start to minimize dependencies, there would be much
more places in Stanbol to look at. That's why I would prefer to
produce less bundles and accept the plus in size.

- Fabian

2011/2/9 Olivier Grisel <[email protected]>:
> 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
>



-- 
Fabian

Reply via email to