Hi, I did an experiment on gremlin-core to see how many automatic modules there are. Turns out there are 4.
[WARNING] * Required filename-based automodules detected: [gremlin- shaded-3.7.2-SNAPSHOT.jar, javatuples-1.2.jar, commons-collections- 3.2.2.jar, exp4j-0.4.8.jar]. Please don't publish this project to a public artifact repository! * `javatuples` can probably be dropped as apache commons-lang3 has tuple classes already. `commons-collections-3.2.2` should be replaced with commons- collections4. `gremlin-shaded` is better not to talk about. This is for gremlin-core and gremlin-language. Cheers Pieter On Tue, 2023-12-12 at 09:21 -0800, Ken Hu wrote: > 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 <[email protected]> > 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 > > > <[email protected]> > > > 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 <[email protected]> > > > > Date: Friday, December 8, 2023 at 12:58 AM > > > > To: [email protected] <[email protected]> > > > > 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. > > > > > > > >
