jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: [DISCUSS] - OSGi deployment for Oak Lucene / Solr indexers
Date Mon, 10 Mar 2014 11:22:22 GMT
On Mon, Mar 10, 2014 at 4:18 PM, Tommaso Teofili
<tommaso.teofili@gmail.com> wrote:
> IIUTC the logic (e.g. the SolrIndexEditorProvider impl) should live in the
> fragment, while the component should live in the host (e.g.
> SolrIndexEditorProviderService) so it'd look weird to me to have a
> component for the Solr index live in oak-lucene, or did I misunderstand?

No. When you add a @Component annotation then maven-scr-plugin would
generate xml descriptor file for that and add that file name to
Service-Component. So by default this header value is set to exact
known list of files present in that bundle. For your use case you
would set it to something like


With above setup SCR would look for descriptor xml from host as well
as fragment bundles

> would you create C and D in Oak? How would you keep up with semantic
> versioning there?

Yes C,D would be created in Oak. We do not have to worry about
semantic versioning here as these fragments would not be exporting any
package. They are just meant to provide required third party libraries
to the Bundle classpath of host  bundle

> would inlining the jars solve the problem and / or are there any drawbacks
> in inlining?

Inlining as suggested through separate C and D would be better as it
would allow the user to update the version (say with next minor
release). If these are inlined as part of A,B itself then it would not
be possible to do that. Or in more simpler setup when using Oak in non
OSGi env user would be using A,B and directly use the required Lucene
and Solr jars as per version required by Oak. C,D are only useful in
OSGi env

Chetan Mehrotra

View raw message