Mark, Thanks for the info. Just looked up <Embed-Dependency> in the documentation and it does what I've done manually with Bundle-ClassPath, which is a bit what I was trying to avoid. At least if it's the way to go, using this instruction, I could still automate the process like I wanted.
Alain On Wed, Jan 2, 2019 at 5:40 AM Mark Hoffmann via osgi-dev < osgi-dev@mail.osgi.org> wrote: > Hi Alain, > > I know that Lucene itself contains split-packages in lucene-core.jar and > lucene-analyzer-common.jar. The split-package there is e.g. > org.apache.lucene.analysis.standard. When OSGi-fying them, we put the two > jars into one OSGi bundle. > > Currently we use bnd, to do that. In former times we used the > maven-bundle-plugin with this instruction e.g. > > > <Embed-Dependency>lucene-analyzers-common;inline=true,lucene-core;inline=true</Embed-Dependency> > > You also have to take care about all external dependencies of e.g. lucene > analyzers or spatial, like morfologic, uima, spatial4j, jakarta-regexp. You > may need to OSGi-fy these dependencies and their transient dependencies > too. > > After OSGi-fying the jars, we executed an additional build step to create > the p2 update site using maven-tycho. In addition to the OSGi-fied jars > there are other transient dependencies. For Lucene we identified: > > <dependency> > <groupId>com.ibm.icu</groupId> > <artifactId>icu4j</artifactId> > </dependency> > <dependency> > <groupId>org.ow2.asm</groupId> > <artifactId>asm</artifactId> > </dependency> > <dependency> > <groupId>org.ow2.asm</groupId> > <artifactId>asm-commons</artifactId> > </dependency> > <dependency> > <groupId>org.antlr</groupId> > <artifactId>antlr4-runtime</artifactId> > </dependency> > <dependency> > <groupId>commons-codec</groupId> > <artifactId>commons-codec</artifactId> > </dependency> > <dependency> > <groupId>org.apache.commons</groupId> > <artifactId>commons-compress</artifactId> > </dependency> > > We took these bundles from the standard Eclipse repository or the Eclipse > Orbit update site. > > This belongs only to the Lucene stuff. Maybe you have to do the same work > for the ES stuff. We never used require-bundle, it worked well out of the > box with package ex- and imports. Using a mega-lucene bundle with all > dependencies, was our first approach ad worked well too. But don't forget, > to put the Java service files as well in the bundles, because Lucene uses > the service loader. > > I hope this helps. > > Mark > Am 31.12.18 um 12:19 schrieb Alain Picard via osgi-dev: > > I am trying to convert a bundle of ours that now simply imports jars for > Elasticsearch and make it a p2 site with p2-maven-plugin that usesthe > maven-bundle-plugin/bnd to wrap non-OSGi jars. > > I ended up with resolution errors since ES has about 7-8 split packages, > most notably org.elasticsearch.client and org.elasticsearch.common. So I > went searching for solutions that I've seen before but never had to use > them. I cam across > https://eclipsesource.com/blogs/2008/08/22/tip-split-packages-and-visibility/ > from Chris and http://web.ist.utl.pt/ist162500/?p=65. > > I first tried to simply create a "bridge" bundle that simply requires the > ES bundles and re-export them and import the bridge bundle from my "search > bundle". That didn't solve the problem, same issue with imports of > split-packages. > > Next I added attribute and mandatory, even if here I was relying on > require-bundle (not what I normally do). In my bridge bundle I added all > the over 300 export-package for the 5 ES bundles, w/o any extra. This > resulted in an error for each export of the form: Package > 'org.elasticsearch.action.admin.cluster.allocation' does not exist in this > plug-in. In the search bundle, with a require bundle of the bridge bundle, > w/o the export packages it would not resolve any ES package and with them > in (even with the error) the only issues were with the split package. I > also tried in the search bundle to instead import the packages, with the > same result. > > I'm getting to the point where I feel I might just have to either go back > to the original approach or create a bundle that just handles the ES > dependencies with bundle-classpath and export-pacakges of all those. > > Any idea where I'm going wrong? > > Thanks > Alain > > > _______________________________________________ > OSGi Developer Mail > listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
