[gwt-contrib] Re: Discussion on changing gwt release groupid

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

[gwt-contrib] Re: Discussion on changing gwt release groupid

> > > 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 SomeLibrar

[gwt-contrib] Re: Discussion on changing gwt release groupid

@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 >

[gwt-contrib] Re: HashCode H$ property should be not enumerable

Since the existing code is very similar to J2CL's code, it seems like a reasonable change, provided it is indeed safe to drop support for IE8. At a glance, I'm having trouble finding a recent statement describing whether or not IE8 (and 9, 10) ought to be supported - since GWT is often used for

[gwt-contrib] HashCode H$ property should be not enumerable

Hi all, I was facing an annoying issue about the hashcode *$N* property, stored inside the java script object. I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects. I'm writing an object (JsType native) in order to configure a chart for Chart.js. @JsType(isNative = true, na