If Dan's assertions are correct, and we can in fact refactor all these packages without API changes, then I am all for giving it a shot. Worst case we have done a little of the work we will have to do for a 2.0 api change anyway and have to revert to the idea of an uber jar.
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 >
