As I said before, even if I think it's ugly, I will ship elasticsearch
lucene package in the bundle (as a private-package).
The lucene dependence will be removed from the camel feature.
Regards
JB
On 10/04/2012 03:49 PM, Babak Vahdat wrote:
In fact looking at the camel-elasticsearch feature:
https://svn.apache.org/repos/asf/camel/trunk/platforms/karaf/features/src/main/resources/features.xml
I see a bundle dependency to "org.apache.servicemix.bundles.lucene" version
3.6.0_1
However I've got no idea HOW/WHO found it out to be the PERFECT match (BTW
this feature came through CAMEL-5219).
I don't even see how the usage of the OSGi version range can resolve this,
let's say [X,X+Y). To my understanding the "perfect" solution would be to
use/load the exact Class Bytecode of Apache Lucene being embedded inside the
provided JAR @ central repo. However I've got no idea how OSGi world could
provide this :-)
All in one in case the elasticsearch bundle would NOT work properly out of
the box just because the Apache Lucene being loaded @ OSGi runtime is not
compatible (even through the usage of a range as you proposed) then who
would be "guilty" one? I would say both elasticsearch as well as Apache
Lucene folks would say:
"We never claimed to be OSGi-compatible! In fact it was Apache ServiceMix
providing some OSGi-Bundles through some OSGi-range hypothesis & magics".
Please excuse me if my answer appears blunt.
Babak
--
View this message in context:
http://servicemix.396122.n5.nabble.com/VOTE-Apache-ServiceMix-Bundles-2012-10-03-release-tp5714621p5714633.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
