Hi, An additional groupID Release sound like a valid part. The Maven reloaction feature should normally work but so existing applications can easier migrate to newer groupID. This strategy is also use for the migration from javax.* to jakarta* I think. There stragy is: 1. All libs are cloned in new groupId 2. Update to newer Version only the new Group Ids (with old package structure) 3. rename packages 4. Release new Features
Maybe this is also usable for GWT migration Am Donnerstag, 11. Juni 2020 22:19:00 UTC+2 schrieb Colin Alworth: > > @Thomas, it sounds like you think relocation should be well supported > then? My primary concern was the quote on the linked page, but if this is > well supported, then I think we're on the same page. From the linked page: > > *2020 rework in progress*, see discussion on dev mailing list >> <https://lists.apache.org/thread.html/r5e940260cfe5234f540c20fdb7bb7dacbb63b911a4b902c75f4f0cd2%40%3Cdev.maven.apache.org%3E>, >> >> still need analysis of issues, definition of improvements, and of course >> implementation... >> > > I'd also suggest going one step further and release a o.g:*:2.9.0 which > just has a relocation to point at c.g.g:*:2.9.0, and a BOM as you describe, > so that projects can begin migrating right away, even before the first > org.gwtproject-only release. We don't even necessarily need to wait until > 2.10 this way, but other 2.9.x releases could move to gwtproject, and just > have some canned maven files ready to have Google ship following each > release (for some limited window of time/versions)? > > I do think we need to push more than just the BOM (you may not have been > suggesting this) for c.g.g releases, as there are plenty of projects out > there not using the BOM. > > Just to be sure I am clear, you are suggesting that o.g BOM includes o.g > dependencies as well as c.g.g, while the c.g.g BOM would only reference > c.g.g dependencies (which themselves would be relocated to o.g anyway). If > so, I think I see a conflict here: > > - SomeLibrary depends on c.g.g:gwt-user:2.9.0 or earlier, with or > without BOM > - MyProject depends on o.g:gwt-user:2.10.0 or later, without a BOM, > and also on SomeLibrary > > Without a BOM, and without o.g:gwt-user:2.10.0 depending on some empty > c.g.g:gwt-user (and making that conflict apparent), the project would end > up with both old and new gwt-user on the classpath at the same time. > > > @Jens > >> Our new published org.gwtproject:...:2.10 release would depend on >> com.google.gwt:...:99.0 which means all old GWT libraries should be >> upgraded via Maven/etc to 99.0 automatically as soon as you add >> org.gwtproject:...:2.10 to your dependencies. >> > I suspect this will not work except in gradle, which picks the highest > version in the case of a conflict. Maven picks the "nearest to your > project", so: > > - SomeLibrary depends on c.g.g:gwt-user:2.9.0 (or earlier, with or > without a BOM) > - MyProject depends on SomeLibrary (so c.g.g:gwt-user is now 2 steps > away) > - MyProject depends on o.g:gwt-user:2.10 without a BOM, which depends > on c.g.g:gwt-user:99.0 (which is also 2 steps away) > > It isn't clear to me which will win automatically. As above, we need the > user to use a BOM if they update to the org.gwtproject implementation to > work reliably, or for the ecosystem to be ahead of applications, and push > updates to long-stable releases. Which, for some of these will require more > relocations, work by Google (which is what we're trying to avoid in the > first place) such as for Gin, GwtQuery, possibly others like GwtMockito. > > I feel like I might be being dense here, is this cleaner than I'm > imagining it? I'll try spinning up a few sample projects and artifacts with > dummy groupIds to test with as time permits for some concrete experiments. > > > > On Wednesday, June 10, 2020 at 3:40:58 AM UTC-5, Thomas Broyer wrote: >> >> >> On Wednesday, June 10, 2020 at 12:09:29 AM UTC+2, Colin Alworth wrote: >>> >>> We're in the last phases of refactoring out the various GWT modules from >>> the gwt-user.jar each into their own github.com/gwtproject/ >>> repositories and jars, so they can be released separately and managed >>> directly on github rather than only through gerrit. These will be new jars, >>> each with a org.gwtproject.* groupId, and with package structure also >>> following org.gwtproject.*. As of their first version they are built and >>> tested to be compatible with both GWT 2.9 and also J2CL, and will be as >>> close to drop-in replacements for their original classes as possible, save >>> for GWT.create(...) calls and changing package structure in your imports. >>> >>> With this change nearly complete, Google has requested that the main GWT >>> release no longer come from from them - as long as the groupId includes >>> com.google, the release to maven central or sonatype snapshots can only be >>> initiated by a Googler. When this change is completed, we would not need >>> the CLA any longer, nor would the compiler need to be hosted on gerrit >>> (though I assume that we would be welcome to continue there?). Google has >>> indicated that we do not need to change package structures within these >>> jars, and just releasing them on their own groupId is sufficient. >>> >>> The primary complication this will add is for large, long-lived >>> projects, using multiple parts of the GWT ecosystem: whereas adding a new >>> dependency to a tree with a conflicting version is expected and handled >>> (maven will ensure only one groupId+artifactId is present on the classpath, >>> selecting the "nearest" version to your project in the tree, while gradle >>> will pick the "highest" version, and ivy is configurable), adding a new >>> dependency with a different _groupId_ will retain both classpath entries, >>> which can clearly cause conflicts. Historically, we have seen issues with >>> this kind of conflict, mostly between gwt-dev and gwt-user, but this change >>> is likely to cause two conflicting versions of gwt-dev or two versions of >>> gwt-user, in addition to conflicting gwt-dev/gwt-user. >>> >>> One proposed solution is that we just switch from GWT 2.9 being >>> com.google.gwt to GWT 2.10 being org.gwtproject. Resolution for this would >>> occur within each project that uses GWT - if you deliberately stay with >>> com.google.gwt, any dependency that gets an update could need an explicit >>> exclusion added to it to prevent it from bringing in any org.gwtproject >>> dependencies. Any missed exclusion on a dependency could result in familiar >>> mixed-classpath errors like we sometimes see when gwt-user and gwt-dev >>> disagree, though instead of mitigating by requiring that projects list both >>> of these artifacts, every single dependency would need to apply exclusions >>> to it. >>> >>> Another solution could be to release 2.9.0 again under the new groupId, >>> and likewise provide the next several releases under both groupIds. This >>> would have the advantage of allowing a project to list both groupIds to >>> manage all dependencies to the same version, but does require that Google >>> continue to publish releases for the duration of some transition period. >>> >>> A similar solution that I can see would be to use the "relocation" >>> feature in maven, though I've rarely seen it used, and there is apparently >>> some ongoing discussion as to whether it should be used. This would enable >>> Google to release a new version which only tells Maven to switch to the >>> org.gwtproject release instead - downstream projects and libraries would >>> manage this in the same way as the second solution. Depending on the >>> specifics, Google might release a matching trivial relocation "release" for >>> each org.gwtproject release for a transition period, or might just release >>> one time and be done. More details on the feature: >>> https://maven.apache.org/guides/mini/guide-relocation.html >>> >>> Are there other technical considerations I'm missing as to how this >>> might be achieved in the most painless way possible? >>> >> >> In addition to the relocation for gwt-dev and gwt-user (and other JARs), >> the BOM (org.gwtproject:gwt) might then list both the org.gwtproject *and* >> the "relocated" com.google.gwt. >> How I think that would work out: people switch to using the >> org.gwtproject:gwt:2.10.0 BOM in their <dependencyManagement> with >> <scope>import</scope>, that would then import the dependency management >> rules that com.google.gwt:gwt-user should now be using 2.10.0 (and "nearest >> version" should now use that version), and of course >> org.gwtproject:gwt:2.10.0; and they'd switch their <dependencies> to >> org.gwtproject too. Now, if they have a dependency that references >> com.google.gwt:gwt-user:2.9.0, dependency management should actually >> resolve it to 2.10.0, which is relocated to org.gwtproject:gwt-user, so you >> should end up with a single JAR in your classpath. >> >> So I would go with Google pushing a single 2.10.0 with relocation, and us >> pushing an org.gwtproject whose BOM references com.google.gwt in addition >> to org.gwtproject. I think the BOM could continue referencing >> com.google.gwt 2.10.0 even for later versions (same as above: >> com.google.gwt:gwt-user:2.9.0 would be "upgraded" to 2.10.0 by dependency >> management from the BOM, which relocates to org.gwtproject:gwt-user:2.10.0, >> but dependency management "upgrades" it in turn to >> org.gwtproject:gwt-user:2.11.0) >> >> This should all be testable locally by tweaking the local repository (as >> explained in the mini guide). >> > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/dfe422ef-a4ad-4b71-8b0f-724eda863379o%40googlegroups.com.
