after one more day of investigating I think it makes sense to create the
OSGi specific bundle only for Solr, as the Lucene one already works nicely
and repackaging in the bigger one would complicate rather than simplify, as
noted in yesterday email.
So for now I'd commit my changes in
Couple of things to try
* Specify the packages versions via package-info
* Inline the classes instead of embedding the jars
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.
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:
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-*,
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
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.
thanks a lot Chetan for your comments, sone questions inline.
2014-03-10 10:40 GMT+01:00 Chetan Mehrotra chetan.mehro...@gmail.com:
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
Hi,
On Mon, Mar 10, 2014 at 5:07 AM, Tommaso Teofili
tommaso.teof...@gmail.com wrote:
Options 1 and 4 are the simplest ones, the only disadvantage is packaging
is heavy
The overhead is few extra megabytes, which is insignificant compared
to the amount of content that even most simple
Hi,
On Mon, Mar 10, 2014 at 5:40 AM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
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.
Good point. This line of thought actually
2014-03-10 17:15 GMT+01:00 Jukka Zitting jukka.zitt...@gmail.com:
Hi,
On Mon, Mar 10, 2014 at 5:40 AM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
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
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,
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
12 matches
Mail list logo
