On Mon, Mar 10, 2014 at 4:18 PM, Tommaso Teofili <tommaso.teof...@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 <Service-Component> OSGI-INF/org.apache.jackrabbit.oak.plugins.index.lucene.*, OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.*, OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.http.*, ... </Service-Component> 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
