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. > >
