In https://github.com/tteofili/jackrabbit-oak/blob/oak-1475c/oak-solr-osgi/pom.xmlI've specialized the above approach only for Solr.
Tommaso 2014-03-12 16:40 GMT+01:00 Tommaso Teofili <tommaso.teof...@gmail.com>: > > > 2014-03-12 12:29 GMT+01:00 Tommaso Teofili <tommaso.teof...@gmail.com>: > > >> >> >> 2014-03-12 12:01 GMT+01:00 Chetan Mehrotra <chetan.mehro...@gmail.com>: >> >> Couple of things to try >>> >>> * Specify the packages versions via package-info >>> >> >> they're already there in oak-lucene / solr , what should I do more? >> > > I've fixed it with the following Export-Package directive: > > <Export-Package> > > !org.apache.jackrabbit.oak.plugins.index.solr.osgi, > org.apache.jackrabbit.oak.plugins.index.* > </Export-Package> > > as the package-info get automatically picked up. > > >> >> >>> * Inline the classes instead of embedding the jars >>> >> >> hints on how to do that? >> > >> >>> >>> This would enable maven-bundle-plugin to see required >>> package-info.java file for versions and also the SCR generated files. >>> >>> Also can you share your project say on github. Would be easier for me >>> to try some options >>> >> >> sure: >> https://github.com/tteofili/jackrabbit-oak/blob/oak-1475b/oak-fulltext/pom.xml >> >> Thanks, >> Tommaso >> >> >>> Chetan Mehrotra >>> >>> >>> On Wed, Mar 12, 2014 at 3:55 PM, Tommaso Teofili >>> <tommaso.teof...@gmail.com> wrote: >>> > 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 <tommaso.teof...@gmail.com>: >>> > >>> >> 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 <tommaso.teof...@gmail.com >>> >: >>> >> >>> >> ah ok, thanks for clarifying. >>> >>> Regards, >>> >>> Tommaso >>> >>> >>> >>> >>> >>> 2014-03-10 18:10 GMT+01:00 Jukka Zitting <jukka.zitt...@gmail.com>: >>> >>> >>> >>> Hi, >>> >>>> >>> >>>> On Mon, Mar 10, 2014 at 1:01 PM, Tommaso Teofili >>> >>>> <tommaso.teof...@gmail.com> 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 >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >> >
