thanks a lot Chetan for your comments, sone questions inline.
2014-03-10 10:40 GMT+01:00 Chetan Mehrotra <[email protected]>: > 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. > IIUTC the logic (e.g. the SolrIndexEditorProvider impl) should live in the fragment, while the component should live in the host (e.g. SolrIndexEditorProviderService) so it'd look weird to me to have a component for the Solr index live in oak-lucene, or did I misunderstand? > > 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 > would you create C and D in Oak? How would you keep up with semantic versioning there? > > 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 > would inlining the jars solve the problem and / or are there any drawbacks in inlining? Thanks, Tommaso > > Chetan Mehrotra > > > On Mon, Mar 10, 2014 at 2:37 PM, Tommaso Teofili > <[email protected]> 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 >
