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/9011f8aa-e8fb-4e3d-9445-b5b9cc7b0684o%40googlegroups.com.
