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
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
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
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 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
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
Fwiw, I started setting up some tests here:
https://github.com/tbroyer/gwt-relocation-tests
Feel free to contribute issues or pull requests.
For now, Maven actually fails because the repository only includes POMs and
not JARs. I'll add empty JARs soon.
On Friday, June 12, 2020 at 5:47:12 PM
Yep, sounds like the test stuff I had in mind - for a quick demo I'll set up a
repo, put some "libraries" and "gwt" jars/boms into it, and then make a bunch
of sample projects. The "gwt jars" will have some service loader wiring, and
the sample projects will check to see which jars they end up
On Thursday, June 11, 2020 at 10:19:00 PM UTC+2, Colin Alworth wrote:
>
> @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
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
>
>
> 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
@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
>
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
I know you can force Gradle to swap out dependencies on the fly, e.g.
replace com.google.gwt with org.gwtproject releases. If that would also be
possible with Maven/Ivy/Bazel then it is just a matter of documentation.
If that is not possible, or not desired, then Google could probably publish
14 matches
Mail list logo
