Imo, no module should export "internal". Maybe a stretch goal, but
something we should keep in mind.
On 11/26/18 10:50, Jacob Barrett wrote:
One lingering question I have around jigsaw is the split package issue
recursive? In that I mean if a module exports "org.apache.geode.internal"
and another module exports "org.apache.geode.internal.foo" is this legal?
On Mon, Nov 19, 2018 at 5:21 PM Dan Smith <dsm...@pivotal.io> wrote:
I think we can actually fix most of these issues without geode-2.0. Most of
these are in internal packages, which means we can change the package of
these classes without breaking users. The only concerning one is
org.apache.geode.cache.util, which is a public package. However, the
AutoBalancer is actually still marked @Experimental, so we could
technically move that as well. Or maybe deprecate the old one and it's
associated jar, and create a new jar with a reasonable package. JDK11 users
could just avoid the old jar.
I have been wondering for a while if we should just fold geode-cq and
geode-wan back into geode-core. These are not really properly separated
out, they are very tangled with core. The above package overlap kinda shows
that as well. But maybe going through the effort of renaming the packages
to make them java 11 modules would help improve the code anyway!
-Dan
On Mon, Nov 19, 2018 at 5:03 PM Owen Nichols <onich...@pivotal.io> wrote:
To package Geode as Java 11 Jigsaw module(s), a major hurdle is the
requirement that packages cannot be split across modules.
If we simply map existing Geode jars to Modules, we have about 10 split
packages (see table below). Any restructuring would potentially have to
wait until Geode 2.0.
A workaround would be to map existing packages into a small number of new
modules (e.g. geode-api and geode-internal). Existing jars would remain
as-is. Users making the transition to Java 11 /w Jigsaw already need to
switch from CLASSPATH to MODULEPATH so the inconvenience of a different
naming scheme for Geode-as-modules might be acceptable (however, once
module naming and organization is established, we may be stuck with it
for
a long time).
Thoughts?
Is it even possible to rearrange all classes in each package below into a
single jar? Is doing so desirable enough to defer Java 11 support until
a
yet-unplanned Geode 2.0, or perhaps to drive such a release?
Or, is it satisfactory to fatten Geode releases to include one set of
jars
for CLASSPATH use, plus a different set of jars for MODULEPATH use?
Package
Jar
org.apache.geode.cache.client.internal
geode-core-1.8.0.jar
geode-cq-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.cache.client.internal.locator.wan
geode-core-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.cache.query.internal.cq
geode-core-1.8.0.jar
geode-cq-1.8.0.jar
org.apache.geode.cache.util
geode-core-1.8.0.jar
geode-rebalancer-1.8.0.jar
org.apache.geode.internal
geode-connectors-1.8.0.jar
geode-core-1.8.0.jar
geode-cq-1.8.0.jar
geode-lucene-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.internal.cache.tier.sockets.command
geode-core-1.8.0.jar
geode-cq-1.8.0.jar
org.apache.geode.internal.cache.wan
geode-core-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.internal.cache.wan.parallel
geode-core-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.internal.cache.wan.serial
geode-core-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.internal.protocol.protobuf.v1
geode-protobuf-1.8.0.jar
geode-protobuf-messages-1.8.0.jar
