2020 rework in progress, see discussion on dev mailing list, still need analysis of issues, definition of improvements, and of course implementation...
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)
@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, 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.
I'm worried that this two way relocation (o.g:*:2.9.0 relocated to c.g.g:*:2.9.0, then c.g.g:*:2.10.0 relocating "back" to o.g:*:2.10.0) might cause more problems than it solves.Also, referencing a relocating POM will print a warning in the console (at least for Maven, AFAICT) so you don't actually want to use o.g before it actually exists.
One thing we could possibly do to detect such cases would be to add some code the Main classes (Compiler, DevMode, CodeServer, JUnitShell) that would look for some duplicate resource on the classpath, or even look for all the com/google/gwt/dev/About.properties content and warn or fail if it finds differing gwt.version properties in there (unfortunately this is in gwt-dev which has fewer risks of being duplicated than gwt-user).So, my plan would be:
- test relocation, without overthinking it, and detecting limitations; then we can refine the plan
- add a check to detect duplicated gwt-user on the classpath when running GWT tools
--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-co...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ef206a74-1c02-421b-a71a-3af43da0bf8ao%40googlegroups.com.
Nice, I have something very similar. My main finding is putting relocation in the BOM doesn't work, unless you _also_ include the previous version's dependencyManagement tag, so that it tells the projects which include the BOM "please update c.g.g" instead of just "relocate to o.g, which will say please include o.g", as that will skip the c.g.g version bump.
--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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4f853f49-167b-4635-b185-9ae9d48948b5o%40googlegroups.com.
My repo of tests, with some notes on problems it has encountered while testing https://github.com/Vertispan/gwt-groupid-relocation-testOn Sun, Jun 14, 2020, at 3:21 PM, Colin Alworth wrote:
Agreed, I was testing to confirm this. It appears to not make a difference in the samples I have so far if that BOM includes the relocation though, but there are a lot of permutations to go through, I'm mostly automating the "easier" ones at this time.On Sun, Jun 14, 2020, at 3:16 PM, Thomas Broyer wrote:
On Sunday, June 14, 2020 at 10:07:48 PM UTC+2, Colin Alworth wrote:Nice, I have something very similar. My main finding is putting relocation in the BOM doesn't work, unless you _also_ include the previous version's dependencyManagement tag, so that it tells the projects which include the BOM "please update c.g.g" instead of just "relocate to o.g, which will say please include o.g", as that will skip the c.g.g version bump.Indeed.That's what I was suggesting in https://groups.google.com/d/msg/google-web-toolkit-contributors/L2RMqglOEXo/fBGwNB2kCQAJ“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.”
--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+unsubscribe@googlegroups.com.
FYI, I've made a couple more tests, and added the results to the README: https://github.com/tbroyer/gwt-relocation-testsUnsurprisingly, the "dumb" resolution rules ("nearest definition") of Maven makes it irrecoverable for projects still on c.g.g that depend on libraries transitively bringing in o.g (they'll have a mix of both, unless they use exclusions); whereas for Gradle some things can be done to make it work the same as if everything was still on c.g.g.The one last test I'd like to do is the one you suggested, with an o.g:*:2.9.0 relocating to c.g.g:*:2.9.0. That could make it possible for Maven, in those above cases, to downgrade all o.g:*:2.10.0 to c.g.g:*:2.9.0 in one go, through a dependencyManagement rule (or switching to the o.g:gwt:2.9.0 BOM instead of c.g.g:gwt:2.9.0), rather than chasing every transitive and adding exclusions everywhere.