update on this: I've tried the oak-fulltext approach and I found two issues: 1. exported packages with semantic versioning from oak-lucene and oak-solr get lost when packing everything together unless they're explicitly specified (by hand) in the oak-fulltext maven-bundle-plugin configuration, it can be done but can be tedious (and it's error prone) 2. OSGi services exported by oak-lucene and oak-solr don't get exported by oak-fulltext as maven-scr-plugin can look into src/main/java or classes but don't know if / how it could work with embedded jars.
Any suggestions? Regards, Tommaso 2014-03-11 9:00 GMT+01:00 Tommaso Teofili <[email protected]>: > if there're no other objections / comments I'll go with the last suggested > approach of having oak-lucene and oak-solr not embedding anything and > having the oak-fulltext bundle embedding everything needed to make Lucene > and Solr indexers working in OSGi (lucene-*, oak-lucene, solr-*, > oak-solr-*, etc.) until we (eventually) get to proper semantic versioning > in Lucene / Solr. > > As a side effect I don't think it would make sense to keep > oak-solr-embedded and oak-solr-remote as separate artifacts so I'd merge > them with oak-solr-core in one oak-solr bundle. > > Regards, > Tommaso > > > 2014-03-10 18:18 GMT+01:00 Tommaso Teofili <[email protected]>: > > ah ok, thanks for clarifying. >> Regards, >> Tommaso >> >> >> 2014-03-10 18:10 GMT+01:00 Jukka Zitting <[email protected]>: >> >> Hi, >>> >>> On Mon, Mar 10, 2014 at 1:01 PM, Tommaso Teofili >>> <[email protected]> wrote: >>> > ok, so (in OSGi env) we would have oak-solr and oak-fulltext as >>> fragments >>> > of oak-lucene (being the fragment host) >>> >>> No, that's not what I meant. The proposed oak-fulltext bundle would >>> contain all of oak-lucene, oak-solr, and the Lucene/Solr dependencies. >>> No need for fragment bundles in this case. >>> >>> BR, >>> >>> Jukka Zitting >>> >> >> >
