Hi Pieter,
My thoughts on this matter have shifted back and forth a fair bit over the last
few days but I wanted to weigh in on the discussion. As far as I understand,
JPMS adoption remains very limited in the Java community which suggests that
fixing the split-package issue will only benefit very few users. However, one
of the main reasons for the slow adoption of JPMS is that many projects are
stuck with dependencies which are not modularized. There is a bit of a chicken
and egg problem limiting JPMS adoption and I wouldn’t want TinkerPop to
perpetuate this unnecessarily.
As Ken mentioned, any package renaming would be a breaking change and would
need to wait until our next major release. Personally, I don’t mind the
inconvenience of a package renaming during a major version bump, however I also
have no plans to use JPMS in any projects in the near future. I would be
curious to hear from others how they feel about the impact of the package
change, as well as if any other projects are looking to utilize TinkerPop in a
modularized app.
Overall, I am generally in favour of your renaming solution (perhaps renaming
from gremlin-core/org.apache.tinkerpop.gremlin.language.grammar to
gremlin-core/org.apache.tinkerpop.gremlin.core.grammar), however I may be
swayed against it if others begin to raise concerns regarding the impact of the
change. Additionally, if we do proceed with the package renaming, I would view
this as a one-off fix to remove a barrier for some users and I would be weary
to claim we officially support (and will continue to support) being used as
automatic modules. I agree with Ken that broad plan to fully adopt and support
JPMS is a pre-requisite for such a stance.
Regards,
Cole
From: pieter <pieter.mar...@gmail.com>
Date: Friday, December 8, 2023 at 12:58 AM
To: dev@tinkerpop.apache.org <dev@tinkerpop.apache.org>
Subject: Re: [DISCUSS] Support for using TinkerPop as a Java Module
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
Warning: The sender of this message could not be validated and may not be the
actual sender.
