Thanks for the response Pieter. I'll try to direct any users that are asking about JPMS to the aforementioned jira.
On Mon, Dec 11, 2023 at 9:32 PM pieter <pieter.mar...@gmail.com> wrote: > Hi, > > Yes thanks, that is reasonable. > I'll keep an eye on the jira issue. > > Thanks > Pieter > > On Mon, 2023-12-11 at 20:14 -0800, Ken Hu wrote: > > Thanks for your input Cole. > > > > My position on this hasn't changed much. I recognize that the ask to > > rename > > a package is a fairly small one, but I want to highlight that recent > > changes to package names have caused issues and I've seen reports of > > several applications breaking. It's hard to predict the kinds of > > issues > > this package renaming will cause. But, from recent experience, we can > > tell > > that there most likely will be problems. My preference is still to > > state > > that we don't provide any support for JPMS in the documentation, > > unless > > there is considerable evidence to prove that a reasonable number of > > users > > would actually adopt JPMS if it were possible to use TinkerPop as an > > automatic module. > > > > Since it isn't possible to make this breaking change until the next > > major > > version which is likely a while off, would the two of you agree to > > put this > > decision on hold until we are closer to its release? In the meantime, > > we > > can try to see how many users/providers would actually be interested > > in > > this change. We can monitor the activity on the associated Jira ( > > https://issues.apache.org/jira/browse/TINKERPOP-3019) for comments or > > watchers. I'd be willing to change my mind if I saw multiple members > > of the > > community come forth and ask for this. > > > > Do you find this to be a reasonable way to move forward on this? > > > > On Mon, Dec 11, 2023 at 5:24 PM Cole Greer > > <cole.gr...@improving.com.invalid> > > wrote: > > > > > 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. > > > > >
