jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: [DISCUSS] - OSGi deployment for Oak Lucene / Solr indexers
Date Mon, 10 Mar 2014 09:40:57 GMT
My vote would be to go for #3

>move the OSGi services we need for Solr in Oak into
oak-solr-osgi (as a fragment cannot run OSGi components/services)

Need not be. Host bundle can allow DS components to be picked from
Fragment bundle. So the required logic can live in respective fragment
bundle.

However I would prefer if its done in following way

A - oak-lucene - Becomes the host bundle. Assuming its always
required. Though some of its services might not be required in call
cases
B - oak-solr-* - Remain independent but fragment bundles. However they
do not embed any jars
C - lucene-fragment - This fragment bundle embed the lucene related jars
D - solr-fragment - This fragment embed the solr related jars

All the fragment specify the oak-lucene as host bundle

Reason for not embedding the Lucene and Solr related dependencies in
Oak bundles is to enable usage of same bundle jars in non OSGi env
without adding to size. As embedded jars (which are not inlined) would
not be usable in non OSGi env a user would have to add such jars in
addition to the one embedded thus adding to size

Chetan Mehrotra


On Mon, Mar 10, 2014 at 2:37 PM, Tommaso Teofili
<tommaso.teofili@gmail.com> wrote:
> Hi all,
>
> The main issue we currently have with our full text indexers is that Lucene
> and Solr are not "OSGi ready", missing proper MANIFEST entries so that they
> cannot directly be installed in e.g. Apache Felix, don't have semantic
> version information, etc.
>
> Currently oak-lucene embeds the Lucene dependencies it needs, also
> exporting its Lucene packages so that they can be used by oak-solr-core (as
> they're needed by Solr) which exposes its embedded Solr packages so that
> oak-solr-[embedded|remote] can use them.
>
> While this should work, there are some concerns raised in OAK-1442 [2]:
> - one issue is that with the current approach we have a problem if a Lucene
> / Solr package changes in a backward incompatible way while we don't
> properly upgrade the semantic version of the Oak package(s) using that,
> which in the end would mean that we in Oak would have to track changes in
> Lucene / Solr and I think I can assume we don't want to
> - the other issue relates more to how we package such Lucene and Solr
> artifacts to use them, as the suggestion is to just wrap o.a.lucene-* and
> o.a.solr-* in two wrapping bundles which can be installed inside an OSGi
> container.
>
> in OAK-1475 [1] we discussed a bit some different approaches for the
> deployment of Oak Lucene and Solr indexers in an OSGi environment,
> currently we have the following options:
>
> 1. package oak-lucene and oak-solr-* in a single bundle (e.g. called
> oak-fulltext), with their Lucene and Solr dependencies embedded, the Lucene
> indexer OSGi services would be already available, the Solr ones would need
> to be configured in order to start the Solr indexer.
> 2. package and export Lucene stuff in a oak-lucene-osgi bundle, package and
> export Solr stuff in oak-solr-osgi bundle, avoid oak-lucene and
> oak-solr-core to export Lucene and Solr packages.
> 3. merge oak-solr-* in a single oak-solr bundle which embeds the Solr
> dependencies (but doesn't export them) to be a fragment of oak-lucene (so
> that they share the classloader and therefore oak-solr can use Lucene stuff
> in oak-lucene), move the OSGi services we need for Solr in Oak into
> oak-solr-osgi (as a fragment cannot run OSGi components/services)
>
> Not yet discussed options:
>
> 4. remove the exported contents from oak-lucene and oak-solr, merge
> oak-solr-* together and duplicate the Lucene dependencies to be embedded in
> oak-solr.
>
> Options 1 and 4 are the simplest ones, the only disadvantage is packaging
> is heavy (in 4 we have duplicated embedded dependencies for Lucene in
> oak-lucene and oak-solr)
> Option 2 is the most OSGi oriented, even if has the unlikely, but yet
> possible, issue with semantic versioning.
> Option 3 is the smartest and trickiest one, no duplication of dependencies,
> full OSGi, but a bit more complicated as it uses OSGi fragments.
>
> My preferences go to 3 and 4.
>
> As this should be fixed for 0.19 please share your comments,
> Regards,
> Tommaso
>
> [1] : https://issues.apache.org/jira/browse/OAK-1475
> [2] :
> https://issues.apache.org/jira/browse/OAK-1442?focusedCommentId=13908472&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13908472

Mime
View raw message