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? 

-- 
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/81784738-15e9-49f8-bc49-d9a292cef3b5o%40googlegroups.com.

Reply via email to