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 >> >>>> >> >>> >> >>> >> >> >> > >