I like the exploratory approach and focusing on the application developer UX. I’m curious to see how the next experiments go. I’d prefer to align our grade submodules with java module definitions (e.g. geode-core becomes a module).
Are the fat jar module definitions solely for the client? If so I think we should figure out how to exclude Shiro entirely—IIRC we should only need the AuthInitializer on the client. I would also iterate on the names a bit. ‘geode-module' is not very descriptive. Anthony > On Nov 28, 2018, at 2:53 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > All, > > We started iterating on a solution for supporting Java modules based > applications linking to Geode as a module dependency. Now before you go, "but > why didn’t you do X?”, let’s set some ground rules here. The initial goal was > to get *a* solution, not the best solution, for linking and using basic > client features, like get, put, query, cq, function execution, and > serialization. To that end PR-2911 (https://github.com/apache/geode/pull/2911 > <https://github.com/apache/geode/pull/2911>) provides a solution. It produces > a fat jar containing a set of classes that make up the features stated in our > goal. It presents itself as a module using automatic naming in the manifest > as ‘org.apache.geode'. The corresponding POM includes all the the same > dependencies that geode-core had so that an application can just depend on > this new module artifact and get all the dependent modules as well. You can > see how this plays out in a simple “Hello World” application at > https://github.com/pivotal-jbarrett/geode-example-java-11 > <https://github.com/pivotal-jbarrett/geode-example-java-11>. > > Why the fat jar? If you make the application require ‘geode.core’ (automatic > name for geode-core.jar) then you immediately fail to compile with split > package errors on ‘org.apache.shiro’ dependencies. Shiro lacks a Java modules > update (see scary Shiro comments below). Ignoring the Shiro issues, by > commenting it out, we then hit the split package issues discussed in earlier > discussions. A fat jar, which includes ‘geode-core’, ‘geode-cq’, and > ‘shiro-core', solves this issue. The downside, besides another jar, is that > Shiro is implicitly exported from our fat jar and this can cause issues if > the application is also using Shiro (not likely given all the Shiro issues > below). > > What’s wrong with Shiro? It is effectively a dead project. The last several > board reports are copy and paste. The reports all indicate stalled interest > on mailing lists. The last release was May of 2017 and since then has only > had a handful of commits and activity. The last release, 1.4.0, actually > worsened the split package issues and all PRs posted to fix it have gone > unmerged. Shiro is required to be on the client class path so that we can > load one of our classes that ultimately doesn’t even use Shiro. We could do a > better job here so that we don’t have to leak Shiro onto the client class > path. > > So what’s next? We are going to experiment with other solutions: > - Fat module with module-info.java to hide Shiro and other internals > - Requires that we find a way to compile classes for Java 8 and modules-info > with Java 9+. > - Existing jars as automatic modules > - Need to get Shiro out of the client class path and only into the server > runtime class path. > - Correct split packages in geode-core and geode-cq > - Existing jars as modules with module-info > - All the requirements of "Existing jars as automatic modules”. > - Requires that we find a way to compile classes for Java 8 and modules-info > with Java 9+. > > We would love any input on the current state of this iteration as well as any > hints at other things we should try. In the mean time a review and acceptance > of this PR helps move us forward in the modules direction. > > Thanks, > Jake >
