Raymond, I think this is a good idea but some of their comment was that they were not even willing to get PR for it since they would then have to support it.
Curious, did you just do it via Bundle-ClassPath or via some Require-bundle re-export or via Export restriction and a bridge bundle or other mean? Alain On Wed, Jan 2, 2019 at 11:33 AM Raymond Auge <raymond.a...@liferay.com> wrote: > There appears to be a lot of us who've repackaged lucene/ES (my company > has done so also). > > I wonder if we could perhaps exert so upstream influence and maybe some > contributions to make it a better OSGi citizen. > > I happen to have a friend who recently works at Elasticsearch that has a > lot of OSGi experience that may be willing to help. > > Thoughts? > > - Ray > > On Wed, Jan 2, 2019, 06:38 Alain Picard via osgi-dev < > osgi-dev@mail.osgi.org wrote: > >> 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 > >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
