On Monday, June 15, 2020 at 7:44:34 PM UTC+2, Thomas Broyer wrote: > > FYI, I've made a couple more tests, and added the results to the README: > https://github.com/tbroyer/gwt-relocation-tests > Unsurprisingly, 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. >
That worked great; but then I remembered dependency constraints are transitive in Gradle, contrary to dependencyManagement in Maven, and are published in Gradle Module Metadata; so this needs more tests with Gradle. Also, if people know and use Ivy, SBT, Buildr, etc. it would be good to test with those, just to make sure (SBT seems to be using Ivy, or optionally Aether –the same as Maven– through a plugin). There's also Coursier <https://get-coursier.io/>, which is used by Bazel's rules_jvm_external <https://blog.bazel.build/2019/03/31/rules-jvm-external-maven.html>. > > On Sunday, June 14, 2020 at 11:27:45 PM UTC+2, Colin Alworth wrote: >> >> My repo of tests, with some notes on problems it has encountered while >> testing https://github.com/Vertispan/gwt-groupid-relocation-test >> >> -- >> Colin Alworth >> co...@colinalworth.com >> >> >> >> On 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. >> >> -- >> Colin Alworth >> co...@colinalworth.com >> >> >> >> 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+unsubscr...@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 >> >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/4f853f49-167b-4635-b185-9ae9d48948b5o%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- 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/986a89da-7a71-413d-a1df-f609ae382e40o%40googlegroups.com.
