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