Hi,
For a client to use TinkerPop only 2 modules are required.
gremlin-language
gremlin-core
I am of the opinion that these 2 modules should actually be its own
dedicated project, but that is for another day.
Regarding these two modules, there is only one split package that
requires refactoring.
org.apache.tinkerpop.gremlin.language.grammar
I locally renamed
gremlin-core/org.apache.tinkerpop.gremlin.language.grammar
and was able two successfully build the client application with the
following module-info.java
module-info.java
requires gremlin.core;
requires gremlin.language;
This now gives the client manyoptions including building native images.
So in short, rename one package and I for one will be a happy JPMS
client.
Thanks
Pieter
On Wed, 2023-12-06 at 11:56 -0800, Ken Hu wrote:
> Hi All,
>
> Recently, there has been some discussion around the use of
> TinkerPop's Java
> libraries as a Java Module. My proposal is to not support this for
> now. The
> reason I feel this way is due to the fact that Java 8 will be
> supported for
> the foreseeable future. There are many dependencies of TinkerPop that
> don't
> support JPMS and would become automatic modules. I'm generally not in
> favor
> of this approach since I feel that it mostly defeats the purpose of
> the
> module system in the first place. I'd prefer that more of our
> dependencies
> became explicit modules first before converting our Java libraries
> into
> explicit modules.
>
> A second related question that has come up is the issue with using
> TinkerPop's Java libraries as automatic modules. The same package is
> exported in multiple projects which causes split packages to occur
> when
> attempting to use TinkerPop in this way. This will require
> workarounds from
> the user to allow TinkerPop to be used as an automatic module.
> Although it
> can be argued that this change would be simpler to do than converting
> the
> project into an explicit module, I'd still be against doing this. My
> preference would be to either fully support JPMS or not support it at
> all.
> Changing package names also constitutes a breaking change which I
> feel the
> majority of our users would not benefit from. Unless there is strong
> demand
> from users or someone is willing to champion this change (implement
> and
> support) then I'd prefer to not support this for now.
>
> What are your thoughts on this subject? If there is no disagreement
> in the
> next three days then I'm going to assume lazy consensus and update
> the
> documentation accordingly to show that we don't support being used as
> a
> Java Module.
>
> Thanks,
> Ken
