Github user spmallette commented on a diff in the pull request:
https://github.com/apache/incubator-tinkerpop/pull/186#discussion_r49576688
--- 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 --
> 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.
You say you check the imported/exported packages of your gremlin-osgi-deps
project and got the information from there. But when that project "goes away",
how would you know what should be added to `<osgi.import>` and `<osgi.export>`.
In other words, how did gremlin-osgi-deps know what to add?
> Could you explain why you have to shade those dependencies instead of
using them directly?
Shading is a technique for avoiding dependency conflict and it is
especially useful for packages that are widely used and are known to introduce
incompatible breaks between versions. By shading, we can bind TinkerPop to any
version of a library we want and upgrade it at our own pace without worrying
about conflict with other system we might depend on or what users might be
using.
---
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.
---
