GitHub user dalaro opened a pull request:
https://github.com/apache/incubator-tinkerpop/pull/41
shade plugin prototype config for Kryo
This commit modifies gremlin-core to shade Kryo 2.24.0 and its
dependencies under the package prefix org.apache.tinkerpop.shaded.
The shaded Kryo & dep classfiles are packed into the gremlin-core jar.
The shaded gremlin-core jar becomes the main project artifact
(i.e. there is no separate gremlin-core-$VERSION-shaded.jar).
Here's a sample of classfiles from the gremlin-core jar:
...
org/apache/tinkerpop/gremlin/structure/Graph$Helper.class
org/apache/tinkerpop/gremlin/structure/Graph.class
...
org/apache/tinkerpop/shaded/kryo_2_24_0/ClassResolver.class
org/apache/tinkerpop/shaded/kryo_2_24_0/DefaultSerializer.class
...
org/apache/tinkerpop/shaded/objenesis_2_1/Objenesis.class
org/apache/tinkerpop/shaded/objenesis_2_1/ObjenesisBase.class
...
org/apache/tinkerpop/shaded/minlog_1_2/Log$Logger.class
org/apache/tinkerpop/shaded/minlog_1_2/Log.class
...
org/apache/tinkerpop/shaded/kryo_2_24_0_reflectasm/AccessClassLoader.class
org/apache/tinkerpop/shaded/kryo_2_24_0_reflectasm/ConstructorAccess.class
...
I disassembled a couple of Kryo classfiles with `javap -verbose` to
check that the intended references were rewritten, and it seems to be
OK, though I only spent a few minutes in there.
Other modules (gremlin-{driver,test}, hadoop-gremlin) depend on Kryo
2.24.0 types shaded by this commit. This commit modifies the imports
in those modules' sources to use the shaded package names,
e.g. `import org.apache.tinkerpop.shaded.kryo_2_24_0.Kryo;`. The
project builds with Maven and the tests run by mvn clean install
-DfeelingLucky pass. However, IDEA's builtin compiler can't figure
out what's going on. IDEA's compiler chokes whenever it encounters a
reference to one of the types normally created by the shade plugin.
One way to make IDEA happy would be to hide all direct references to
Kryo types behind a TP interface that lives in -core and which is
implemented in -core. Modules which currently import Kryo directly
would instead import the interface from -core. This should make the
effects of shading invisible at the source level and placate IDEA.
One last comment about gremlin-core/pom.xml's new
`<optional>true</optional>` lines. These are kind of a hack. The
idea is to let gremlin-core continue depending on Kryo and its
dependencies so that it can compile and shade the classfiles, but to
prevent artifacts that depend on gremlin-core from pulling down the
unshaded Kryo artifact, which would defeat the point. Optional=true
does this, but it's not really the intended function. The alternative
is to use the "dependency reduced" POM generation feature of the
maven-shade-plugin, but that has always kind of creeped me out. It's
worth investigating if you don't like the optional=true hack though.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dalaro/incubator-tinkerpop shaded-kryo
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-tinkerpop/pull/41.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #41
----
commit 4c76324c9c8c38b59f80a0ffed26778a2fc59058
Author: Dan LaRocque <[email protected]>
Date: 2015-03-24T18:49:07Z
shade plugin prototype config for Kryo
This commit modifies gremlin-core to shade Kryo 2.24.0 and its
dependencies under the package prefix org.apache.tinkerpop.shaded.
The shaded Kryo & dep classfiles are packed into the gremlin-core jar.
The shaded gremlin-core jar becomes the main project artifact
(i.e. there is no separate gremlin-core-$VERSION-shaded.jar).
Here's a sample of classfiles from the gremlin-core jar:
...
org/apache/tinkerpop/gremlin/structure/Graph$Helper.class
org/apache/tinkerpop/gremlin/structure/Graph.class
...
org/apache/tinkerpop/shaded/kryo_2_24_0/ClassResolver.class
org/apache/tinkerpop/shaded/kryo_2_24_0/DefaultSerializer.class
...
org/apache/tinkerpop/shaded/objenesis_2_1/Objenesis.class
org/apache/tinkerpop/shaded/objenesis_2_1/ObjenesisBase.class
...
org/apache/tinkerpop/shaded/minlog_1_2/Log$Logger.class
org/apache/tinkerpop/shaded/minlog_1_2/Log.class
...
org/apache/tinkerpop/shaded/kryo_2_24_0_reflectasm/AccessClassLoader.class
org/apache/tinkerpop/shaded/kryo_2_24_0_reflectasm/ConstructorAccess.class
...
I disassembled a couple of Kryo classfiles with `javap -verbose` to
check that the intended references were rewritten, and it seems to be
OK, though I only spent a few minutes in there.
Other modules (gremlin-{driver,test}, hadoop-gremlin) depend on Kryo
2.24.0 types shaded by this commit. This commit modifies the imports
in those modules' sources to use the shaded package names,
e.g. `import org.apache.tinkerpop.shaded.kryo_2_24_0.Kryo;`. The
project builds with Maven and the tests run by mvn clean install
-DfeelingLucky pass. However, IDEA's builtin compiler can't figure
out what's going on. IDEA's compiler chokes whenever it encounters a
reference to one of the types normally created by the shade plugin.
One way to make IDEA happy would be to hide all direct references to
Kryo types behind a TP interface that lives in -core and which is
implemented in -core. Modules which currently import Kryo directly
would instead import the interface from -core. This should make the
effects of shading invisible at the source level and placate IDEA.
One last comment about gremlin-core/pom.xml's new
`<optional>true</optional>` lines. These are kind of a hack. The
idea is to let gremlin-core continue depending on Kryo and its
dependencies so that it can compile and shade the classfiles, but to
prevent artifacts that depend on gremlin-core from pulling down the
unshaded Kryo artifact, which would defeat the point. Optional=true
does this, but it's not really the intended function. The alternative
is to use the "dependency reduced" POM generation feature of the
maven-shade-plugin, but that has always kind of creeped me out. It's
worth investigating if you don't like the optional=true hack though.
----
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
