Github user gdelafosse commented on a diff in the pull request: https://github.com/apache/incubator-tinkerpop/pull/186#discussion_r49556486 --- Diff: gremlin-shaded/pom.xml --- @@ -24,6 +24,67 @@ limitations under the License. </parent> <artifactId>gremlin-shaded</artifactId> <name>Apache TinkerPop :: Gremlin Shaded</name> + <packaging>bundle</packaging> + <properties> + <!-- + As this jar is shaded, the maven-bundle-plugin is not able to process exported and imported packages from generated classes. + So we must explicitely tell which packages are exported and imported by this bundle to the maven-bundle-plugin. + --> + <osgi.import> --- End diff -- Gremlin Shaded was not the most easy to bundleize, mainly because of the package relocation processed while packaging this jar. So I had to tell it explicitely what to do. To list those instructions I checked the imported and exported packages of my gremlin-osgi-deps project, and put the instructions corresponding to the gremlin-shaded packages directly in this project. As a result, gremlin-shaded is a correct OSGI bundle, and I'm able to get rid of the gremlin-osgi-deps (as soon as third parts dependencies are OSGI bundles too). To answer your question, the integration test I'm implementing will detect if you miss to update to the osgi.import and osgi.export. Sounds tricky but actually this gremlin-shaded project sounds tricky to me too. Could you explain why you have to shade those dependencies instead of using them directly?
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---