Re: [gwt-contrib] GWT 3.0 ready editors porting completed

[Colin Alworth]

Yes - it doesn't need Widgets at all, just any bean-like data and views
which implement the various Editor interfaces. There's no reason that
this wouldn't work outside of GWT entirely - JVM, Android, TeaVM all can
run plain Java sources like this generates.
--
  Colin Alworth
  co...@colinalworth.com



On Fri, Nov 16, 2018, at 9:46 AM, Michael Joyner wrote:
> Can this be used with any UI kit?
> 
> 
> On 11/16/18 10:32 AM, Ahmad Bawaneh wrote:
>> Hi 
>> i would like to announce that i have completed the gwt-editors
>> porting to annotation processor, and now is GWT 3.0 ready.>> 
>> the work was started by both Colin Alworth[1] and Frank Hossfeld[2]
>> thanks for them both for the great work>> 
>> both me and Rafat Al-Barouki[3] made the final touches to make ready>> 
>> We appreciate your kind review of the new ported module at 
>> 
>> https://github.com/DominoKit/gwt-editors
>> 
>> Thanks
>> --
>>  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/52db809c-f009-4db6-b2d8-ef3103019983%40googlegroups.com[4].>>
>>   For more options, visit https://groups.google.com/d/optout.
> 
> 


> --
>  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/2f378177-0f77-626e-c3a6-b297bccbbdfc%40newsrx.com[5].>
>   For more options, visit https://groups.google.com/d/optout.


Links:

  1. https://github.com/niloc132
  2. https://github.com/FrankHossfeld
  3. https://github.com/rjeeb
  4. 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/52db809c-f009-4db6-b2d8-ef3103019983%40googlegroups.com?utm_medium=email&utm_source=footer
  5. 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/2f378177-0f77-626e-c3a6-b297bccbbdfc%40newsrx.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/1542383357.1941467.1579357000.426B2369%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

[Colin Alworth]

I messaged Manolo this morning after seeing this, and in gitter where
we're talking about this.
>From some digging in history, an old copy of the properties file
referenced pytz2011n, which looks like it might be a specific release of
pytz. The commit message Manolo made had a reference to some internal
Google python script, which I'm guessing takes that pytz
library/database (looks like they also just reference iana) and makes
the .properties file, and updates the interface that points at the file.
The commits for  previous changes went through google code and were
imported to git, so I'm not sure we can find much more public
commentary.
--
  Colin Alworth
  co...@colinalworth.com



On Fri, Dec 7, 2018, at 8:32 AM, Thomas Broyer wrote:
> 
> 
> On Friday, December 7, 2018 at 1:54:09 PM UTC+1, Ahmad Bawaneh wrote:>> 
> Anyone know what is generating TimeZoneConstants.properties, it says
>> it is generated from CLDR version 25 .. but i cant find any thing
>> that generates this gile in gwt code nor in gwt-tools code, was it
>> generated externally?> 
> Have you tried pinging Manolo? He's the last one to have updated the
> file, maybe he remembers the details. Either him or John Tamplin.> 


> --
>  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/af65bf54-2dbb-4dc0-9833-1064e21b207a%40googlegroups.com[1].>
>   For more options, visit https://groups.google.com/d/optout.


Links:

  1. 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/af65bf54-2dbb-4dc0-9833-1064e21b207a%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/1544194546.2589826.1602130792.5A5C8AA1%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

[Colin Alworth]

Thanks Manolo - in the course of his updates, Ahmad went over the patch
file used previously and found the changes to either be already merged
or entirely incompatible - no one objected to simply switching to the
stock version of CLDR, so that's what was done instead.
Goktug did some quick checking internally but didn't find anything right
away, I owe him a more in-depth writeup of what we think will point at
the tool which had been used in the past.
--
  Colin Alworth
  co...@colinalworth.com



On Mon, Dec 17, 2018, at 4:22 PM, Manuel Carrasco Moñino wrote:
> Sorry for the late reply. 
> In theory the process is: google modifies original cldr distribution
> per version, and gives a patch to us, then we run our generator and
> commit modified files.> We don't run any python script, hence 
> TimeZoneConstants.properties
> should have been always provided by google.> I don't remember how that file 
> in my commit was generated, apparently
> we should have some utility file for that, I have checked out to
> previous commit snapshot, patch cldr with goole patch, and run tools
> to generate files, though TimeZoneConstants.properties is not
> generated. It's so long ago that I don't conserve original tree with
> some program I could have utilised for that.  CC-ed J.A. Tamplin, he
> might remember about if there was some parallel utility.> I'll try to 
> investigate further though
> 
> - Manolo
> 
> 
> On Sat, Dec 8, 2018 at 12:50 PM Ahmad Bawaneh
>  wrote:>> I think in the GWT2 context we can just generate 
> a new file with the
>> same old tool with updated data, but in the GWT3 context i think we
>> need to think of another approach.>> few weeks ago i was working on a 
>> JodaTime emulation for GWT, one part
>> of that work was the generation of time zone info, i managed to build
>> a tool to generate them based on JodaTime runtime time zone info
>> provider which instead of creating run time instances i made the code
>> emit source code and it worked, i still think it could be made better
>> by implementing a wrapper instead of changing the code itself, anyway
>> .. the time zones info in joda time was based on iana database, and
>> joda time is a will maintained and regularly updated and reliable, so
>> we can use that as a base for a generator instead if inventing the
>> whole wheel.>> 
>> in my approach i was generating a class per time zone which a factory
>> class to get a time zone by id, but if we still think that the JSON
>> constants is a better approach we still can generate the JSONs from
>> those files.>> 
>> this is just a thought that i had as i was working on emulating
>> joda time.>> 
>> On Friday, December 7, 2018 at 5:17:20 PM UTC+2, Thomas Broyer wrote:>>> We 
>> may want to generate that file using java.time.ZoneId then; WDYT?>>> 
>>> On Friday, December 7, 2018 at 3:55:50 PM UTC+1, Colin Alworth
>>> wrote:>>>> I messaged Manolo this morning after seeing this, and in gitter
>>>> where we're talking about this.>>>> 
>>>> From some digging in history, an old copy of the properties file
>>>> referenced pytz2011n, which looks like it might be a specific
>>>> release of pytz. The commit message Manolo made had a reference to
>>>> some internal Google python script, which I'm guessing takes that
>>>> pytz library/database (looks like they also just reference iana)
>>>> and makes the .properties file, and updates the interface that
>>>> points at the file.>>>> 
>>>> The commits for  previous changes went through google code and were
>>>> imported to git, so I'm not sure we can find much more public
>>>> commentary.>>>> 
>>>> --
>>>>   Colin Alworth
>>>>   co...@colinalworth.com
>>>> 
>>>> 
>>>> 
>>>> On Fri, Dec 7, 2018, at 8:32 AM, Thomas Broyer wrote:
>>>>> 
>>>>> 
>>>>> On Friday, December 7, 2018 at 1:54:09 PM UTC+1, Ahmad Bawaneh
>>>>> wrote:>>>>>> Anyone know what is generating TimeZoneConstants.properties, 
>>>>> it
>>>>>> says it is generated from CLDR version 25 .. but i cant find any
>>>>>> thing that generates this gile in gwt code nor in gwt-tools code,
>>>>>> was it generated externally?>>>>> 
>>>>> Have you tried pinging Manolo? He's the last one to have updated
>>>>> the file, maybe he remembers the details. Either him or J

[gwt-contrib] Re: NoSuchMethodException in HEAD-SNAPSHOT has been removed, breaking knightsoft gwt-bean-validators

[Colin Alworth]

Thanks for the heads up - it was removed since it isn't possible to throw 
in client code anyway, and projects could emulate it themselves if 
necessary. I'm curious about why gwt-bean-validators must have it, as the 
original validator code did not have it - is it expecting it to be possible 
to throw? It has always had a private constructor to make that completely 
impossible.

I checked out the project so I could offer a pull request with the two 
different approaches that could be used to fix this, but it doesnt appear 
that the project builds out of the box - javadoc errors that are fatal just 
for a plain mvn install or mvn package. Stepping down to just mvn compile 
(so I could attempt to build, but never actually use it) then encounters a 
dependency-check issue. Any advice you can offer on building my own copy to 
contribute these fixes right away? 

Approach one: "super source" this exception - validators already require 
some super source, so there should already be a clear place to put this in 
the project.

Approach two: stop indicating that methods could throw this, or that 
try/catch blocks could catch it, since it wasn't possible to throw anyway. 
Any emulated java code cannot have this exception naturally (no 
classloader, no classes loaded from disk, etc), and as I mentioned, it has 
a private constructor.

Like I said, I'd be very glad to collaborate and build these patches and 
get them merged so we can get this resolved.

On Thursday, January 3, 2019 at 4:13:20 AM UTC-6, stuckagain wrote:
>
> Hi,
>
> I just noticed this morning that our project fails to build this morning 
> due to a change in HEAD-SNAPSHOT.
>
> We are using knightsoft gwt-bean-validators and its source is apparently 
> depending on the fact that GWT is emulating the NoSuchMethodException.
>
> I saw this commit where there is a mention that this was discussed:
>
> https://github.com/gwtproject/gwt/commit/329b21962075c675d1a2e2b3d48049ca5e9fe195
>
> This is what I get now when compiling:
> [INFO] Compiling module com.swift.cloud.platform.ui.demo.Demo
> [INFO]Tracing compile failure path for type 
> 'org.apache.commons.beanutils.PropertyUtils'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/supersource/org/apache/commons/beanutils/PropertyUtils.java'
> [INFO]  [ERROR] Line 56: No source code is available for type 
> java.lang.NoSuchMethodException; did you forget to inherit a required 
> module?
> [INFO]Tracing compile failure path for type 
> 'de.knightsoftnet.validators.shared.util.BeanPropertyReaderUtil'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/mt-bean-validators/1.0.0/mt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/shared/util/BeanPropertyReaderUtil.java'
> [INFO]  [ERROR] Line 60: No source code is available for type 
> java.lang.NoSuchMethodException; did you forget to inherit a required 
> module?
> [INFO]Tracing compile failure path for type 'java.net.URL'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/supersource/java/net/URL.java'
> [INFO]  [ERROR] Line 958: No source code is available for type 
> java.lang.NoSuchMethodException; did you forget to inherit a required 
> module?
> [INFO]Tracing compile failure path for type 
> 'org.hibernate.validator.internal.util.logging.Log'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/supersource/org/hibernate/validator/internal/util/logging/Log.java'
> [INFO]  [ERROR] Line 415: No source code is available for type 
> java.lang.NoSuchMethodException; did you forget to inherit a required 
> module?
> [INFO]Tracing compile failure path for type 
> 'de.knightsoftnet.validators.client.impl.AbstractGwtValidator'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/client/impl/AbstractGwtValidator.java'
> [INFO]  [ERROR] Line 144: No source code is available for type 
> java.lang.NoSuchMethodException; did you forget to inherit a required 
> module?
> [INFO]Tracing compile failure path for type 
> 'org.apache.commons.beanutils.BeanUtils'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/supersource/org/apache/commons/beanutils/BeanUtils.java'
> [INFO]  [ERROR] Line 48: No source code is available for type 
> java.lang.NoSuchMethodException; did you forget to inherit a required 
> module?
> [INFO][ERROR] Aborting compi

[gwt-contrib] Re: NoSuchMethodException in HEAD-SNAPSHOT has been removed, breaking knightsoft gwt-bean-validators

[Colin Alworth]

I believe that the reason this class existed to begin with was to allow 
(for some reason..) RPC to serialize that exception and pass it to client 
code. But emulation that "needs" it to match the correct signature can 
safely remove it from a "throws" clause without breaking the contract, 
correct?

Or is this a case of "it isn't a runtime exception, so the _calling_ code 
must then declare the catch statement"? I'm still waking up, might not be 
fully clear here...

-- 
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/f70256f6-a236-4f8f-b237-a191d44cb112%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Java 9, 10 JRE emulation reviews

[Colin Alworth]

Hey all, anyone want to review some code?

Right around the new year, I finished up a first cut of all of the features 
mentioned so far on https://github.com/gwtproject/gwt/issues/9547, 
including tests. The first patch is at 
https://gwt-review.googlesource.com/c/gwt/+/21501, with a tentative -1 from 
me to keep anyone from merging it until we're sure about the approaches I 
took there, and about how to get the build to run on something newer than 
Java 8. The full set of diffs can be seen at 
https://github.com/niloc132/gwt/commits/java9-collections, though in a 
fairly raw state, with the intention of splitting out changes piece by 
piece to land upstream.

Can anyone take a glance at that so we can think about merging it, and 
starting to look at the later patches in that stream? Likewise, has someone 
had the chance to look at Java 9+ support for our ant build?

-- 
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/3446a9bf-d1d7-47bb-ba24-2f13e70be82a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java11 support

[Colin Alworth]

Alexander has patches up for Java 11 language support - if we ship now, we 
won't be compatible with Java 11 (unless you just mean running the compiler 
on a Java 11 JDK, but as I understand it, we're already good there with 
2.8.2?).

I have patches up for Java 9, 10 JRE support, which also need review if 
you're interested in those things as well.

We're still here, but almost all of this work is done in our free time - if 
you have something you'd like to see done more quickly, please do watch 
reviews, help by making comments to improve the code and get it landed more 
quickly, and consider authoring some changes or directly supporting the 
developers who are authoring them. 

On Wednesday, February 6, 2019 at 3:17:22 PM UTC-6, Hristo Stoyanov wrote:
>
>
> I am also curious. GWT 2.8.2 being on Java 8 is major holdup for my 
> projects. Whatever happened to the GWT steering committee ??? Can we just 
> get GWT 2.9 with the only feature being Java 11 support?
>
> On Monday, January 7, 2019 at 10:19:28 AM UTC-8, Alexander Leshkin wrote:
>>
>> Is there any one who works on Java 11 support? I mean updating 
>> dependencies and new "sourceLevel" introduction.
>> If not and if there is an interest in this, I can try to create PR.
>>
>

-- 
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/3da4b019-31df-4c32-a53a-9077ad2696f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Testing GWT 2.9.0 for release

[Colin Alworth]

Hi all,
We have a build ready to test for GWT 2.9.0, and are looking for volunteers 
to verify that things are behaving properly on a variety of platforms. If 
you have an hour or two free and can help us out, we would appreciate it.

We're hoping for a cross-section of testing that verifies 
 * JVM version: 8, 11, 14
 * Operating System: Linux, OS X, Windows (8, 8.1, 10)
 * Browser: Chrome, Firefox, Safari, IE11, Edge

If a tester has access to more than one of these at a time, the tests will 
probably go more quickly than two individuals testing the same setup. 
Please note that while Microsoft still provides virtual machines for 
testing purposes, only Windows 10 appears to be available, though with both 
IE11 and Edge 
(https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/).

Please send me an email off-list with the various options you are able to 
test, and I'll get you on the testing spreadsheet.

Thanks!

-- 
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/c0e7162a-5217-4e89-8c50-ee3c051202c2%40googlegroups.com.

Re: [gwt-contrib] Testing GWT 2.9.0 for release

[Colin Alworth]

Yeah I’ll send it out once we’ve got some volunteers, and figured out who is 
able to test what configurations. 

-- 
 Colin Alworth
 co...@colinalworth.com



On Mon, Apr 13, 2020, at 10:00 PM, Juan Pablo Gardella wrote:
> Hi Colin,
> 
> Could you please share the spreadsheet again?
> 
> Juan
> 
> On Mon, 13 Apr 2020 at 23:43, Colin Alworth  wrote:
>> Hi all,
>> We have a build ready to test for GWT 2.9.0, and are looking for volunteers 
>> to verify that things are behaving properly on a variety of platforms. If 
>> you have an hour or two free and can help us out, we would appreciate it.
>> 
>> We're hoping for a cross-section of testing that verifies 
>>  * JVM version: 8, 11, 14
>>  * Operating System: Linux, OS X, Windows (8, 8.1, 10)
>>  * Browser: Chrome, Firefox, Safari, IE11, Edge
>> 
>> If a tester has access to more than one of these at a time, the tests will 
>> probably go more quickly than two individuals testing the same setup. Please 
>> note that while Microsoft still provides virtual machines for testing 
>> purposes, only Windows 10 appears to be available, though with both IE11 and 
>> Edge (https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/).
>> 
>> Please send me an email off-list with the various options you are able to 
>> test, and I'll get you on the testing spreadsheet.
>> 
>> Thanks!
>> 

>> --
>>  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/c0e7162a-5217-4e89-8c50-ee3c051202c2%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/c0e7162a-5217-4e89-8c50-ee3c051202c2%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/CA%2BkiFseb94LNZo8-vqXD6KTTHApRq8jAAnL7gW18EoTHygzz3w%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFseb94LNZo8-vqXD6KTTHApRq8jAAnL7gW18EoTHygzz3w%40mail.gmail.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/daf8600c-308a-44dd-a17b-69f9fa9e2c7c%40www.fastmail.com.

Re: [gwt-contrib] Testing GWT 2.9.0 for release

[Colin Alworth]

We're having an issue related to the java7->java8 update, the build isn't 
properly including the full sources for the included sample projects. By 
itself, not a big deal, but it could imply that other assumptions of the 
ant build are broken too. I'm looking into it, we'll have an updated 
release candidate when we figure it out.

https://github.com/gwtproject/gwt/issues/9682: The 2.9 candidate was cut 
before the java.io changes came in, so this will not be included in the 
first 2.9 at least, though will likely show up later (See the 4th point in 
this email).

Removing validation: as a rule, the main GWT project rarely, if ever, 
removes anything within a major release. This is very deliberate, so that 
updating to the latest release (to fix security issues, to support 
newer/changing/breaking browsers, improve performance) is accessible to 
stable projects in maintenance mode, with no surprises. Since gwt-dev and 
gwt-user are strongly tied to each other, it isn't feasible to even suggest 
that someone update part of their project, but continue to use older jars 
(such as updating the compiler to fix some issue, but still keeping an old 
gwt-user so that the now-deprecated validation doesn't change or 
disappear). This is why each module that is being broken out will now live 
in its own git repo, own jar, and be versioned separately from the others. 
My best guess here is that we can try for a "minimal gwt-user" which just 
has enough to let the compiler work, and assume that developers switch to 
the org.gwtproject modules that they want, plus anything thirdparty like 
validation. That said, validation is basically the only thing that _isn't_ 
ready for j2cl, and there is a small gwt-validation project that has gotten 
started that is compatible with both gwt2 and j2cl - do you have plans to 
finish https://gitlab.com/ManfredTremmel/gwt-bean-validators/-/issues/3? 
Both topics (further modularizing gwt-user, and apt for validation) are 
probably better discussed in another thread, or in gitter.

CL 19800: Agreed, sucks that this fell through the cracks. Two thoughts: 
lets get that into gwt-i18n as soon as possible, and lets try to land that 
patch after 2.9.0 is cut and shipped. The plan is that 2.9.x gets updated 
regularly (6-8 weeks sort of thing) with any changes, and marked with a 
date rather than just an occasional version.

-- 
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/9b91b87d-4ff7-483a-99cc-356bb4ce00d9%40googlegroups.com.

Re: [gwt-contrib] Testing GWT 2.9.0 for release

[Colin Alworth]

Update on the broken samples in the gwt distribution:

The issue is some kind of interaction between Java 8 and ant - when a URL 
is read from the classloader for a directory within a jar, it had a 
trailing slash. When running the GWT webappcreator from command line, this 
didn't happen, when running within ant in Java 7 this didn't happen.

The patch is up as https://gwt-review.googlesource.com/c/gwt/+/22320.

An alternative fix could be to normalize those paths inside the 
WebAppCreator and remove trailing slashes - we experimented with that at 
first, but once we discovered that it was ant's classloader which was 
causing this and _not_ just Java 8, it made more sense to fork the task. 
This also brings the WebAppCreator task in line with all other  tasks 
in the ant build.

-- 
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/2aa37e19-95ec-406d-aa96-cf0f1233cb36%40googlegroups.com.

Re: [gwt-contrib] Re: Testing GWT 2.9.0 for release

[Colin Alworth]

Jim, the download zip is available for people who are helping with pre-release 
testing - it is an error that the jars made it into maven central before we 
completed this acceptance testing. Once we finish testing, we will announce it 
and make a zip generally available for download.

With that said, can you confirm that the 
jsinterop-annotations-1.1.0-sources.jar jar does _not_ contain a file at 
jsinterop/annotations/Annotations.gwt.xml'? I am suspecting either you got a 
corrupt jar, or that this sources jar didn't end up on your compiler classpath 
after all.

$ unzip jsinterop-annotations-1.1.0-RC1-sources.jar 
Archive: jsinterop-annotations-1.1.0-RC1-sources.jar
 inflating: jsinterop/annotations/Annotations.gwt.xml 
...



-- 
 Colin Alworth
 co...@colinalworth.com



On Tue, Apr 28, 2020, at 1:02 PM, 'Jim Douglas' via GWT Contributors wrote:
> I've got the same build error that Michael reported here, and I'm not sure 
> how to get past it.
> 
> I couldn't find a complete self-contained gwt-2.9.0-rc1.zip distribution, so 
> I hacked one together by downloading 2.8.2 from here:
> 
> http://www.gwtproject.org/download.html
> 
> I extracted that GWT 2.8.2 SDK to ~/Documents/gwt-2.9.0-rc2, then I 
> downloaded all of the relevant 2.9.0-RC1 jar files from Maven:
> 
> https://mvnrepository.com/artifact/com.google.gwt
> 
> And I dropped those jar files into that directory. The result was a hacked 
> attempt at a 2.9.0-rc1 GWT SDK, with a root directory that looks like this:
> 
> /Users/jimdouglas/Documents/gwt-2.9.0-rc1

> scrappy:gwt-2.9.0-rc1 jimdouglas$ ls -l

> total 99096

> -rw-r--r--@ 1 jimdouglas staff 12371 Oct 18 2017 COPYING

> -rw-r--r--@ 1 jimdouglas staff 15678 Oct 18 2017 COPYING.html

> -rw-r--r--@ 1 jimdouglas staff 3332 Oct 18 2017 about.html

> -rw-r--r--@ 1 jimdouglas staff 1132 Oct 18 2017 about.txt

> drwxr-xr-x@ 4 jimdouglas staff 128 Oct 18 2017 doc

> -rw-r--r--@ 1 jimdouglas staff 69451 Oct 18 2017 gwt-api-checker.jar

> -rw-r--r--@ 1 jimdouglas staff 207833 Apr 28 08:44 gwt-codeserver.jar

> -rw-r--r--@ 1 jimdouglas staff 15733992 Apr 28 08:41 gwt-dev.jar

> -rw-r--r--@ 1 jimdouglas staff 1842417 Apr 28 08:43 gwt-elemental.jar

> -rw-r--r--@ 1 jimdouglas staff 7100 Oct 18 2017 gwt-module.dtd

> -rw-r--r--@ 1 jimdouglas staff 276583 Oct 18 2017 gwt-servlet-deps.jar

> -rw-r--r--@ 1 jimdouglas staff 9941813 Apr 28 08:42 gwt-servlet.jar

> -rw-r--r--@ 1 jimdouglas staff 17412993 Apr 28 08:40 gwt-user.jar

> -rwxr-xr-x@ 1 jimdouglas staff 128 Nov 2 2015 i18nCreator

> -rwxr-xr-x@ 1 jimdouglas staff 90 Nov 2 2015 i18nCreator.cmd

> -rw-r--r--@ 1 jimdouglas staff 13672 Apr 28 10:41 
> jsinterop-annotations-1.1.0-sources.jar

> -rw-r--r--@ 1 jimdouglas staff 5772 Apr 28 10:41 
> jsinterop-annotations-1.1.0.jar

> -rw-r--r--@ 1 jimdouglas staff 858 Oct 18 2017 release_notes.html

> -rw-r--r--@ 1 jimdouglas staff 62207 Oct 18 2017 requestfactory-apt-src.jar

> -rw-r--r--@ 1 jimdouglas staff 90362 Oct 18 2017 requestfactory-apt.jar

> -rw-r--r--@ 1 jimdouglas staff 524213 Oct 18 2017 
> requestfactory-client+src.jar

> -rw-r--r--@ 1 jimdouglas staff 200451 Oct 18 2017 
> requestfactory-client-src.jar

> -rw-r--r--@ 1 jimdouglas staff 323928 Oct 18 2017 requestfactory-client.jar

> -rw-r--r--@ 1 jimdouglas staff 1261366 Oct 18 2017 
> requestfactory-server+src.jar

> -rw-r--r--@ 1 jimdouglas staff 258242 Oct 18 2017 
> requestfactory-server-src.jar

> -rw-r--r--@ 1 jimdouglas staff 1003290 Oct 18 2017 requestfactory-server.jar

> drwxr-xr-x@ 11 jimdouglas staff 352 Oct 18 2017 samples

> -rw-r--r--@ 1 jimdouglas staff 65220 Nov 2 2015 
> validation-api-1.0.0.GA-sources.jar

> -rw-r--r--@ 1 jimdouglas staff 47433 Nov 2 2015 validation-api-1.0.0.GA.jar

> -rwxr-xr-x@ 1 jimdouglas staff 130 Nov 2 2015 webAppCreator

> -rwxr-xr-x@ 1 jimdouglas staff 92 Nov 2 2015 webAppCreator.cmd

> scrappy:gwt-2.9.0-rc1 jimdouglas$ 

> 
> Then within Eclipse, I did a "GWT Compile Project", which failed right away 
> with this error message:
> 
> Loading inherited module 'com.basis.bbj.web.gwt.EnglishOnly'

>  Loading inherited module 'com.google.gwt.core.Core'

>  Loading inherited module 'jsinterop.annotations.Annotations'

>  [ERROR] Unable to find 'jsinterop/annotations/Annotations.gwt.xml' on your 
> classpath; could be a typo, or maybe you forgot to include a classpath entry 
> for source?

> 
> So first question: How do I get it to recognize the 
> jsinterop-annotations-1.1.0 that I did drop into that directory?
> 
> And second question: Is there an easier way to download or construct a 
> traditional GWT SDK to test GWT 2.9.0-RC1 in Eclipse?
> 
> On Tuesday, April 21, 2020 at 12:09:44 AM UTC

Re: [gwt-contrib] Re: Testing GWT 2.9.0 for release

[Colin Alworth]

...To further clarify, because in re-reading that email I might sound like a 
bit of a jerk: If you would like to help with testing I'll add you to the group 
- ideally we're looking for more testers with something other than Windows 10, 
but more testing is usually better. The purpose in what I was saying was not to 
exclude you, but to indicate that the zip wasn't available yet because it 
wasn't ready to be generally available at this time.

-- 
 Colin Alworth
 co...@colinalworth.com



On Tue, Apr 28, 2020, at 9:41 PM, Colin Alworth wrote:
> Jim, the download zip is available for people who are helping with 
> pre-release testing - it is an error that the jars made it into maven central 
> before we completed this acceptance testing. Once we finish testing, we will 
> announce it and make a zip generally available for download.
> 
> With that said, can you confirm that the 
> jsinterop-annotations-1.1.0-sources.jar jar does _not_ contain a file at 
> jsinterop/annotations/Annotations.gwt.xml'? I am suspecting either you got a 
> corrupt jar, or that this sources jar didn't end up on your compiler 
> classpath after all.
> 
> $ unzip jsinterop-annotations-1.1.0-RC1-sources.jar 
> Archive: jsinterop-annotations-1.1.0-RC1-sources.jar
>  inflating: jsinterop/annotations/Annotations.gwt.xml 
> ...
> 
> 
> 
> -- 
>  Colin Alworth
>  co...@colinalworth.com
> 
> 
> 
> On Tue, Apr 28, 2020, at 1:02 PM, 'Jim Douglas' via GWT Contributors wrote:
>> I've got the same build error that Michael reported here, and I'm not sure 
>> how to get past it.
>> 
>> I couldn't find a complete self-contained gwt-2.9.0-rc1.zip distribution, so 
>> I hacked one together by downloading 2.8.2 from here:
>> 
>> http://www.gwtproject.org/download.html
>> 
>> I extracted that GWT 2.8.2 SDK to ~/Documents/gwt-2.9.0-rc2, then I 
>> downloaded all of the relevant 2.9.0-RC1 jar files from Maven:
>> 
>> https://mvnrepository.com/artifact/com.google.gwt
>> 
>> And I dropped those jar files into that directory. The result was a hacked 
>> attempt at a 2.9.0-rc1 GWT SDK, with a root directory that looks like this:
>> 
>> /Users/jimdouglas/Documents/gwt-2.9.0-rc1

>> scrappy:gwt-2.9.0-rc1 jimdouglas$ ls -l

>> total 99096

>> -rw-r--r--@ 1 jimdouglas staff 12371 Oct 18 2017 COPYING

>> -rw-r--r--@ 1 jimdouglas staff 15678 Oct 18 2017 COPYING.html

>> -rw-r--r--@ 1 jimdouglas staff 3332 Oct 18 2017 about.html

>> -rw-r--r--@ 1 jimdouglas staff 1132 Oct 18 2017 about.txt

>> drwxr-xr-x@ 4 jimdouglas staff 128 Oct 18 2017 doc

>> -rw-r--r--@ 1 jimdouglas staff 69451 Oct 18 2017 gwt-api-checker.jar

>> -rw-r--r--@ 1 jimdouglas staff 207833 Apr 28 08:44 gwt-codeserver.jar

>> -rw-r--r--@ 1 jimdouglas staff 15733992 Apr 28 08:41 gwt-dev.jar

>> -rw-r--r--@ 1 jimdouglas staff 1842417 Apr 28 08:43 gwt-elemental.jar

>> -rw-r--r--@ 1 jimdouglas staff 7100 Oct 18 2017 gwt-module.dtd

>> -rw-r--r--@ 1 jimdouglas staff 276583 Oct 18 2017 gwt-servlet-deps.jar

>> -rw-r--r--@ 1 jimdouglas staff 9941813 Apr 28 08:42 gwt-servlet.jar

>> -rw-r--r--@ 1 jimdouglas staff 17412993 Apr 28 08:40 gwt-user.jar

>> -rwxr-xr-x@ 1 jimdouglas staff 128 Nov 2 2015 i18nCreator

>> -rwxr-xr-x@ 1 jimdouglas staff 90 Nov 2 2015 i18nCreator.cmd

>> -rw-r--r--@ 1 jimdouglas staff 13672 Apr 28 10:41 
>> jsinterop-annotations-1.1.0-sources.jar

>> -rw-r--r--@ 1 jimdouglas staff 5772 Apr 28 10:41 
>> jsinterop-annotations-1.1.0.jar

>> -rw-r--r--@ 1 jimdouglas staff 858 Oct 18 2017 release_notes.html

>> -rw-r--r--@ 1 jimdouglas staff 62207 Oct 18 2017 requestfactory-apt-src.jar

>> -rw-r--r--@ 1 jimdouglas staff 90362 Oct 18 2017 requestfactory-apt.jar

>> -rw-r--r--@ 1 jimdouglas staff 524213 Oct 18 2017 
>> requestfactory-client+src.jar

>> -rw-r--r--@ 1 jimdouglas staff 200451 Oct 18 2017 
>> requestfactory-client-src.jar

>> -rw-r--r--@ 1 jimdouglas staff 323928 Oct 18 2017 requestfactory-client.jar

>> -rw-r--r--@ 1 jimdouglas staff 1261366 Oct 18 2017 
>> requestfactory-server+src.jar

>> -rw-r--r--@ 1 jimdouglas staff 258242 Oct 18 2017 
>> requestfactory-server-src.jar

>> -rw-r--r--@ 1 jimdouglas staff 1003290 Oct 18 2017 requestfactory-server.jar

>> drwxr-xr-x@ 11 jimdouglas staff 352 Oct 18 2017 samples

>> -rw-r--r--@ 1 jimdouglas staff 65220 Nov 2 2015 
>> validation-api-1.0.0.GA-sources.jar

>> -rw-r--r--@ 1 jimdouglas staff 47433 Nov 2 2015 validation-api-1.0.0.GA.jar

>> -rwxr-xr-x@ 1 jimdouglas staff 130 Nov 2 2015 webAppCreator

>> -rwxr-xr-x@ 1 jimdouglas staff 92 Nov 2 2015 webAppCreator.cmd

&

Re: [gwt-contrib] Re: Testing GWT 2.9.0 for release

[Colin Alworth]

Jim, from this result, your classpath isn't correctly configured - the file is 
there in the jar, as expected, but GWT isn't seeing it, so doesn't know to 
include these sources.

I'll reach out off-list once we have a new zip and are ready to start testing 
again.

-- 
 Colin Alworth
 co...@colinalworth.com



On Tue, Apr 28, 2020, at 9:59 PM, 'Jim Douglas' via GWT Contributors wrote:
> scrappy:gwt-2.9.0-rc1 jimdouglas$ pwd

> /Users/jimdouglas/Documents/gwt-2.9.0-rc1

> scrappy:gwt-2.9.0-rc1 jimdouglas$ jar tvf jsinterop-annotations-1.1.0.jar | 
> grep gwt.xml

> scrappy:gwt-2.9.0-rc1 jimdouglas$ jar tvf 
> jsinterop-annotations-1.1.0-sources.jar | grep gwt.xml

>  40 Wed Apr 08 22:14:10 PDT 2020 jsinterop/annotations/Annotations.gwt.xml

> scrappy:gwt-2.9.0-rc1 jimdouglas$ 

> 
> 
> On Tuesday, April 28, 2020 at 7:38:43 PM UTC-7, Colin Alworth wrote:
>> Jim, the download zip is available for people who are helping with 
>> pre-release testing - it is an error that the jars made it into maven 
>> central before we completed this acceptance testing. Once we finish testing, 
>> we will announce it and make a zip generally available for download.
>> 
>> With that said, can you confirm that the 
>> jsinterop-annotations-1.1.0-sources.jar jar does _not_ contain a file at 
>> jsinterop/annotations/Annotations.gwt.xml'? I am suspecting either you got a 
>> corrupt jar, or that this sources jar didn't end up on your compiler 
>> classpath after all.
>> 
>> $ unzip jsinterop-annotations-1.1.0-RC1-sources.jar 
>> Archive: jsinterop-annotations-1.1.0-RC1-sources.jar
>>  inflating: jsinterop/annotations/Annotations.gwt.xml 
>> ...
>> 
>> 
>> 
>> -- 
>>  Colin Alworth
>> co...@colinalworth.com
>> 
>> 
>> 
>> On Tue, Apr 28, 2020, at 1:02 PM, 'Jim Douglas' via GWT Contributors wrote:
>>> I've got the same build error that Michael reported here, and I'm not sure 
>>> how to get past it.
>>> 
>>> I couldn't find a complete self-contained gwt-2.9.0-rc1.zip distribution, 
>>> so I hacked one together by downloading 2.8.2 from here:
>>> 
>>> http://www.gwtproject.org/download.html
>>> 
>>> I extracted that GWT 2.8.2 SDK to ~/Documents/gwt-2.9.0-rc2, then I 
>>> downloaded all of the relevant 2.9.0-RC1 jar files from Maven:
>>> 
>>> https://mvnrepository.com/artifact/com.google.gwt
>>> 
>>> And I dropped those jar files into that directory. The result was a hacked 
>>> attempt at a 2.9.0-rc1 GWT SDK, with a root directory that looks like this:
>>> 
>>> /Users/jimdouglas/Documents/gwt-2.9.0-rc1

>>> scrappy:gwt-2.9.0-rc1 jimdouglas$ ls -l

>>> total 99096

>>> -rw-r--r--@ 1 jimdouglas staff 12371 Oct 18 2017 COPYING

>>> -rw-r--r--@ 1 jimdouglas staff 15678 Oct 18 2017 COPYING.html

>>> -rw-r--r--@ 1 jimdouglas staff 3332 Oct 18 2017 about.html

>>> -rw-r--r--@ 1 jimdouglas staff 1132 Oct 18 2017 about.txt

>>> drwxr-xr-x@ 4 jimdouglas staff 128 Oct 18 2017 doc

>>> -rw-r--r--@ 1 jimdouglas staff 69451 Oct 18 2017 gwt-api-checker.jar

>>> -rw-r--r--@ 1 jimdouglas staff 207833 Apr 28 08:44 gwt-codeserver.jar

>>> -rw-r--r--@ 1 jimdouglas staff 15733992 Apr 28 08:41 gwt-dev.jar

>>> -rw-r--r--@ 1 jimdouglas staff 1842417 Apr 28 08:43 gwt-elemental.jar

>>> -rw-r--r--@ 1 jimdouglas staff 7100 Oct 18 2017 gwt-module.dtd

>>> -rw-r--r--@ 1 jimdouglas staff 276583 Oct 18 2017 gwt-servlet-deps.jar

>>> -rw-r--r--@ 1 jimdouglas staff 9941813 Apr 28 08:42 gwt-servlet.jar

>>> -rw-r--r--@ 1 jimdouglas staff 17412993 Apr 28 08:40 gwt-user.jar

>>> -rwxr-xr-x@ 1 jimdouglas staff 128 Nov 2 2015 i18nCreator

>>> -rwxr-xr-x@ 1 jimdouglas staff 90 Nov 2 2015 i18nCreator.cmd

>>> -rw-r--r--@ 1 jimdouglas staff 13672 Apr 28 10:41 
>>> jsinterop-annotations-1.1.0-sources.jar

>>> -rw-r--r--@ 1 jimdouglas staff 5772 Apr 28 10:41 
>>> jsinterop-annotations-1.1.0.jar

>>> -rw-r--r--@ 1 jimdouglas staff 858 Oct 18 2017 release_notes.html

>>> -rw-r--r--@ 1 jimdouglas staff 62207 Oct 18 2017 requestfactory-apt-src.jar

>>> -rw-r--r--@ 1 jimdouglas staff 90362 Oct 18 2017 requestfactory-apt.jar

>>> -rw-r--r--@ 1 jimdouglas staff 524213 Oct 18 2017 
>>> requestfactory-client+src.jar

>>> -rw-r--r--@ 1 jimdouglas staff 200451 Oct 18 2017 
>>> requestfactory-client-src.jar

>>> -rw-r--r--@ 1 jimdouglas staff 323928 Oct 18 2017 requestfactory-client.jar

>>> -rw-r--r--@ 1 jimdouglas staff 126

Re: [gwt-contrib] CI / Jenkins configuration issue

[Colin Alworth]

The build is failing again, two days in a row, and since this is shortly 
after the jsinterop-annotation change, there is concern that this failure 
is a result of that change. Can a googler look into this, or grant us the 
ability to do so?

Thanks,
Colin

On Monday, July 22, 2019 at 12:48:34 PM UTC-5, Roberto Lublinerman wrote:
>
> The issue is still not completely resolved and build.gwtproject.org is 
> still unreachable. However continuous builds and presubmits should be 
> working now.
>
> On Sun, Jul 7, 2019 at 4:39 AM Roberto Lublinerman  > wrote:
>
>> I am currently on vacation. The issue is that because of security 
>> concerns new policies are in place regarding use of compute engine by 
>> Google teams. Http and https have been blocked by an enforcer bot. I will 
>> sort this out when I get back. There might be a need to transition out of 
>> this configuration.
>>
>> So for now build.gwtproject.org will remain inaccessible, the server 
>> though it's still running, pulls the changes, does the fast check but is 
>> unable to start the presubmit since it does so through an http post on 
>> build.gwtproject.org.
>>
>> I'll let you know how it goes.
>>
>>
>>
>> On Sat, Jul 6, 2019, 12:58 Jens > 
>> wrote:
>>
>>>
>>> fixed

>>>  
>>> Hmm, build.gwtproject.org still isn't accessible for me and Jenkins 
>>> still does an endless check as soon as +1 or +2 is given.
>>>
>>> -- J.
>>>
>>> -- 
>>> 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/fc58ea21-f502-4a85-9571-81b43f564630%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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/c520c1f1-2b2f-4b7e-95f7-b3fba534dfa0%40googlegroups.com.

Re: [gwt-contrib] CI / Jenkins configuration issue

[Colin Alworth]

Yes - I've grown accustomed to the emails being too truncated to be helpful, 
but I do have that set of tests fixed, and am slowly running the other tests in 
the build to be sure that I haven't broken anything else. This shouldn't affect 
the gwt distribution artifacts, provided all tests pass, but we can discuss 
cutting yet another release if someone feels strongly about this. My current 
position is that if all tests pass, we can release as-is, does that seem 
reasonable?

-Colin

-- 
 Colin Alworth
 co...@colinalworth.com



On Sun, May 3, 2020, at 10:23 AM, Thomas Broyer wrote:
> 
> 
> On Sunday, May 3, 2020 at 3:37:30 PM UTC+2, Colin Alworth wrote:
>> The build is failing again, two days in a row, and since this is shortly 
>> after the jsinterop-annotation change, there is concern that this failure is 
>> a result of that change. Can a googler look into this, or grant us the 
>> ability to do so?
> 
> From https://groups.google.com/d/topic/gwt-maintainers/cFtUrCzbTd4/discussion,
> 
>> compile.tests:
>>  [mkdir] Created dir: 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test>
>> [gwt.javac] Compiling 1427 source files to 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test>
>> [gwt.javac] Note: Some input files use or override a deprecated API.
>> [gwt.javac] Note: Recompile with -Xlint:deprecation for details.
>> [gwt.javac] Note: Some input files use unchecked or unsafe operations.
>> [gwt.javac] Note: Recompile with -Xlint:unchecked for details.
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/core/linker/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/util/tools/shared/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/core/ext/soyc/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/dev/javac/typemodel/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/util/tools/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/core/ext/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/core/ext/typeinfo/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/util/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/core/ext/linker/package-info.class>
>> [gwt.javac] Creating empty 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test/com/google/gwt/util/regexfilter/package-info.class>
>> [gwt.javac] Compiling 3792 source files to 
>> <http://build.gwtproject.org/job/gwt/ws/build/out/dev/bin-test>
>> [gwt.javac] 
>> <http://build.gwtproject.org/job/gwt/ws/user/super/com/google/gwt/emul/javaemul/internal/ArrayHelper.java>:18:
>>  error: package jsinterop.annotations does not exist
>> [gwt.javac] import jsinterop.annotations.JsPackage;
>> [gwt.javac] ^
>> [gwt.javac] 
>> <http://build.gwtproject.org/job/gwt/ws/user/super/com/google/gwt/emul/javaemul/internal/ArrayHelper.java>:19:
>>  error: package jsinterop.annotations does not exist
>> [gwt.javac] import jsinterop.annotations.JsProperty;
>> [gwt.javac] ^
>> [gwt.javac] 
>> <http://build.gwtproject.org/job/gwt/ws/user/super/com/google/gwt/emul/javaemul/internal/ArrayHelper.java>:20:
>>  error: package jsinterop.annotations does not exist
>> [gwt.javac] import jsinterop.annotations.JsType;
>> [gwt.javac] ^
>> [gwt.javac] 
>> <http://build.gwtproject.org/job/gwt/ws/user/super/com/google/gwt/emul/javaemul/internal/ArrayHelper.java>:95:
>>  error: cannot find symbol
>> [gwt.javac] @JsType(isNative = true, name = "Function", namespace = 
>> JsPackage.GLOBAL)
>> [gwt.javac] ^
>> [gwt.javac] symbol: class JsType
>> [gwt.javac] location: class ArrayHelper
>> [gwt.javac] 
>> <http://build.gwtproject.org/job/gwt/ws/user/super/com/google/gwt/emul/javaemul/internal/NativeArray.java>:19:
>>  error: package jsinterop.annotations does not exist
>> [gwt.javac] import jsinterop.annotations.JsFunction;
>> [gwt.javac] ^
>

Re: [gwt-contrib] Testing GWT 2.9.0 for release

[Colin Alworth]

Excellent - reach out in https://gitter.im/gwtproject/gwt, 
https://gitter.im/gwtproject/gwt-modules, or https://gitter.im/vertispan/j2cl 
for any discussion around this, and people who are eager to help test.

-- 
  Colin Alworth
  co...@colinalworth.com

On Sun, May 3, 2020, at 11:40 AM, Manfred Tremmel wrote:
> Am Montag, 20. April 2020, 03:01:12 CEST schrieb Colin Alworth:
> > That said, validation is basically the only thing that _isn't_
> > ready for j2cl, and there is a small gwt-validation project that has gotten
> > started that is compatible with both gwt2 and j2cl - do you have plans to
> > finish https://gitlab.com/ManfredTremmel/gwt-bean-validators/-/issues/3?
> > Both topics (further modularizing gwt-user, and apt for validation) are
> > probably better discussed in another thread, or in gitter.
> 
> I know replacing generators is to long on my todo list and it always was 
> postponed because something else was more important. In June I'm three weeks 
> on vacation and it's on first place of my todo list for this time.
> 
> 
> 
> -- 
> 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/1772943.97skhhT45E%40thinkpad.
>

-- 
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/8ccd2e92-4388-4407-85c6-be7168b45a31%40www.fastmail.com.

[gwt-contrib] Informal GWT/J2CL call tomorrow

[Colin Alworth]

Every few weeks, a group of us that chat regularly on gitter try to meet up 
and chat about what we're working on in the GWT/J2CL ecosystem. We're 
casting the net a bit wider this time, posting the invite here (albeit with 
short notice). If those goes well, we might formalize further.

This is meant to be a very informal discussion, no firm structure or 
purpose, but a few people have offered to present some specific things, and 
I've listed the times they hope to be around. We realize that timezones are 
a thing, and just running an "all-day" call isn't going to get people 
together, so the rough plan is to start at 3pm UTC, and at the top of every 
hour would be the best time to join for things to "start" (rather than 
having people join haphazardly, see no one is there, and just leave).

Link: meet.google.com/fht-icbn-tpm

Starting around 3pm UTC: Dmitrii Tikhomirov/@treblereel - brainstorming on 
locale generation, lazy loading, and pruning code so that GWT2/J2CL can 
skip unused locales.

4pm UTC: Myself/@niloc132 - j2cl-maven-plugin 0.15-SNAPSHOT 
changes/improvements, some progress in typescript -> externs -> jsinterop 
codegen

When able to join: Frank Hossfeld/@FrankHossfeld - work on migrating 
gwt-user modules and getting ready for release.

11pm UTC: Miroslav Pokorny/@mP1 - tooling to make building emulation 
libraries easier, work on java.time, junit 4/5 asserts (I will probably not 
still be on by this point, we'll see how my evening goes).

I stress again that this is very informal, and if you have something you 
would like to talk about or ask about, you are very welcome to join.

Normally we're chatting in https://gitter.im/vertispan/j2cl about j2cl 
specifically, and in https://gitter.im/gwtproject/gwt for more general GWT 
topics.

-- 
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/260306e7-a639-4f36-8fbd-2721ab3e10a9%40googlegroups.com.

[gwt-contrib] Discussion on changing gwt release groupid

[Colin Alworth]

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? 

-- 
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/81784738-15e9-49f8-bc49-d9a292cef3b5o%40googlegroups.com.

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

[Colin Alworth]

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 
large long-lived applications, it can sometimes make sense to provide 
support for browsers that might be officially unsupported, but still either 
have a wide install base or where some other "extended support" is still 
available.

For example, from 
https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
 
it appears that while IE8 and IE10 are no longer supported, IE9 is still 
supported in some supported operating systems as the most recent browser. 
However, there is still the note "To continue receiving IE 8 updates after 
January 12, 2016, please contact your Microsoft Account Team.", suggesting 
it is still possible to get IE8 support.

This is contradicted somewhat by 
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems,
 
which says that the two OS versions (Win Server 2008 IA64 and SP2) which 
support IE9 are no longer supported, suggesting that aside from some 
specialized support contract, IE8, IE9, and IE10 should be considered dead.

On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote:
>
> 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, name = "Object", namespace = JsPackage.GLOBAL)
>
> Every property is the ID of another object.
>
> But unfortunately I got an error from Chart.js because it is scanning all 
> properties keys to get the objects but it does not recognize the value of 
> *$H*, being a number and not a object.
>
> scales: { 
>   $H: 135, 
>   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, …}, 
>   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
> }
>
> It's clear that a hashcode must be stored therefore there is no way to remove 
> it.
>
> Searching for a solution, I have found the *javaemul.internal.ObjectHashing* 
> class which is managing the H$ property, I guess:
>
>  public static native int getHashCode(Object o) /*-{
> return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
>  }-*/;
>
> I think the definition of H$ property must be changed, in order to define the 
> property "not enumerable" (currently is writable, enumerable and 
> configurable) using *Object.defineProperty()*, as it is reported 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty.
>
> The *Object.defineProperty()* method is not supported into Internet Explorer 
> 8 therefore if going to manage the hascode in this way, GWT will drop the 
> support on IE8 as well.
>
> In the J2CL implementation, it looks like already aligned with my proposal:
>
>
> /** 
>   * Utility functions for setting and retrieving system level hashcodes. 
>   */
> class Hashing { 
>/** 
>  * Gets a hash code on the passed-in object. 
>  * 
>  * @param {*} obj 
>  * @return {number} 
>  * @public 
>  */ 
>  static $getHashCode(obj) { 
> let o = /** @type {Object} */ (obj); 
> return o.$systemHashCode || (Object.defineProperties(o, { 
> $systemHashCode: {value: Hashing.$getNextHashId(), enumerable: false} }), 
> o.$systemHashCode); 
>  }
>
> Anyway, as workaround, I'm rewriting the hashcode property for this object, 
> maintaining the same value but setting the property as not enumerale and it 
> seems working.
>
>
>
>

-- 
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/a355b976-6859-4237-b057-2bbb1905f6aao%40googlegroups.com.

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

[Colin Alworth]

@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 
> <https://lists.apache.org/thread.html/r5e940260cfe5234f540c20fdb7bb7dacbb63b911a4b902c75f4f0cd2%40%3Cdev.maven.apache.org%3E>,
>  
> 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. 


@Jens

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

It isn't clear to me which will win automatically. As above, we need the 
user to use a BOM if they update to the org.gwtproject implementation to 
work reliably, or for the ecosystem to be ahead of applications, and push 
updates to long-stable releases. Which, for some of these will require more 
relocations, work by Google (which is what we're trying to avoid in the 
first place) such as for Gin, GwtQuery, possibly others like GwtMockito.

I feel like I might be being dense here, is this cleaner than I'm imagining 
it? I'll try spinning up a few sample projects and artifacts with dummy 
groupIds to test with as time permits for some concrete experiments.


 
On Wednesday, June 10, 2020 at 3:40:58 AM UTC-5, Thomas Broyer wrote:
>
>
> 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, 
>> us

[gwt-contrib] Ant, ZipScanner, and GWT

[Colin Alworth]

We have two issues tracking the dependency that GWT has on Ant, 
https://github.com/gwtproject/gwt/issues/9690 and 
https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and 
produced a minimal set of classes copied from ant which appear to provide a 
working ZipScanner. For the moment, this lives in its own git repository at 
https://github.com/vertispan/ant-zipscanner, and is not deployed anywhere.

I spent a while testing with latest ant, 1.10.8, but semantics have changed 
with the zip/directory scanner API such that leading "/" characters no 
longer match - rather than break behavior, I've instead switched to simply 
using the 1.6.5 code, and modified that for our purposes. This has the 
advantage of being substantially smaller than 1.10.8 - 18 types instead of 
46, and of those 18, 11 are required for ant's own implementation of the 
zip format, so the other 7 are needed to scan a zip and match contents. It 
is quite likely that this could be pruned further, but might come at a cost 
when updating to some later ant version (should we decide to do that).

This repository is arranged in three commits:

   - Create a script to copy the classes we need from the ant repo, and a 
   pom to ship these contents. The script is handy when iterating on a new 
   version, but probably won't be needed unless we do attempt to use a new 
   version
   - Copy all required classes from the tag "rel/1.6.5" in the upstream ant 
   repo 
   - Comment out anything which didn't compile due to missing dependencies 
   (we have no use for Project or refs, we only call ZipScanner methods 
   directly), or which modify the filesystem in some way (to limit risks when 
   depending on this codebase

The resulting output is shaded into a new package by the pom so that it 
will not interfere with ant when GWT is compiled (or if GWT is invoked from 
ant). 

When GWT is updated to both include this jar and also to reference these 
new shaded classes instead of the originals within ant, all tests in dev/ 
pass and all samples compile, though I haven't yet run all of the other 
tests.

So, my question is then how to proceed. First of all, is this approach 
acceptable in terms of maintenance, or would we prefer reimplementing the 
API from scratch in order to drop this dependency, or just updating to the 
latest ant version for this one API?

Assuming we like the approach, should we incorporate these copied/modified 
sources into GWT itself, or add an additional jar to gwtproject/tools, with 
instructions on how to update it, and from there include it into the 
project? A somewhat related option could be releasing this jar to maven 
central under something like org.gwtproject.ant:ant-zipscanner, and 
maintaining it in the github.com/gwtproject umbrella.

Finally, is there any objection to staying with 1.6.5, or should I see if 
we can use a later version, or update GWT's internals to use the new 
behavior around leading slashes, etc?

-- 
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/f3957563-9097-4e1d-9166-77858655aa64o%40googlegroups.com.

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

[Colin Alworth]

Agreed that this fix only requires dropping IE8, but I'm suggesting that we go 
a bit further and either a) also drop other dead browsers, or b) have a 
plan/timeline for when we can drop those browsers - at least officially. We 
might still leave in support for them (as we did for IE6 for some years), but 
require that projects go out of their way to enable that support.

-- 
 Colin Alworth
co...@colinalworth.com



On Fri, Jun 12, 2020, at 9:49 AM, stockiNail wrote:
> Some frameworks can support IE8 polyfilling the application. In my opinion 
> the IE 8 support could be dropped.
> 
> Don't forget that the proposal (the`* Object.defineProperty()*`usage) is 
> available from IE9, therefore we are not saying that we raise the GWT 
> requirement to IE11 or Edge, but only 1 version up.
> 
> Il giorno venerdì 12 giugno 2020 16:32:24 UTC+2, Vegegoku ha scritto:
>> Most of our cliensts dropped support for ancient IEs, and we now only 
>> support IE11 and edge.
>> 
>> On Thursday, June 11, 2020 at 10:18:18 PM UTC+3, Colin Alworth wrote:
>>> 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 
>>> large long-lived applications, it can sometimes make sense to provide 
>>> support for browsers that might be officially unsupported, but still either 
>>> have a wide install base or where some other "extended support" is still 
>>> available.
>>> 
>>> For example, from 
>>> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
>>>  it appears that while IE8 and IE10 are no longer supported, IE9 is still 
>>> supported in some supported operating systems as the most recent browser. 
>>> However, there is still the note "To continue receiving IE 8 updates after 
>>> January 12, 2016, please contact your Microsoft Account Team.", suggesting 
>>> it is still possible to get IE8 support.
>>> 
>>> This is contradicted somewhat by 
>>> https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems,
>>>  which says that the two OS versions (Win Server 2008 IA64 and SP2) which 
>>> support IE9 are no longer supported, suggesting that aside from some 
>>> specialized support contract, IE8, IE9, and IE10 should be considered dead.
>>> 
>>> On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote:
>>>> 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, name = "Object", namespace = JsPackage.GLOBAL)
>>>> 
>>>> Every property is the ID of another object.
>>>> 
>>>> But unfortunately I got an error from Chart.js because it is scanning all 
>>>> properties keys to get the objects but it does not recognize the value of 
>>>> *$H*, being a number and not a object.
>>>> scales: { 
>>>>   $H: 135, 
>>>>   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, 
>>>> …}, 
>>>>   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
>>>> }
>>>> 
>>>> It's clear that a hashcode must be stored therefore there is no way to 
>>>> remove it.
>>>> 
>>>> Searching for a solution, I have found the 
>>>> *javaemul.internal.ObjectHashing* class which is managing the H$ property, 
>>>> I guess:
>>>> 
>>>>  public static native int getHashCode(Object o) /*-{
>>>>     return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
>>>>  }-*/;
>>>> 
>>>> I think the definition of H$ property must be changed, in order to define 
>>>> the property "not enumerable" (currently is writable, enumerable and 
>>>> configurable) using *Object.defineProperty()*, as it is reported 
>>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defi

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

[Colin Alworth]

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 with, so that we 
can see which configurations cause which surprises.

Roughly, I'll deploy

 * LibraryWithNewGwt
 * LibraryWithOldGwt
 * LibraryWithBomAndNewGwt
 * LibraryWithBomAndOldGwt
 * LibraryWithTransitiveOldGwt (two flavors of this, one for each of the old 
gwt above)
 * LibraryWithTransitiveNewGwt (again, two flavors)

then try to build projects with old or new gwt, plus 1-2 of the libraries 
above. If a project ever detects more than one gwt version, we'll fail that, 
and go from there.


> 
> 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.
Good point - perhaps we just push a o.g:gwt:2.9.0 bom then, and encourage 
switching to just that? Same idea as before - projects can future proof 
themselves and move to this BOM, then only have to change its version in the 
BOM declaration to be correctly updated. This does miss out on some of the 
benefits though. Will hold off exploring until the above experiment has some 
results to share.


> 
> 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
Yeah, I was thinking about this - It would be nice if we could go back in time 
and add some nice version sentinel that can be scanned for across all jars, but 
About.properties is as good as anything. Confirming gwt-dev is current doesn't 
tell you much (plenty of libraries only use gwt-user), but hopefully it will 
catch the important cases. Probably should augment the above samples to have 
another axis: gwt-user, or gwt-user+gwt-dev on each library.

-- 
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/d9878fe9-4880-4722-984e-dbf1d8aca600%40www.fastmail.com.

Re: [gwt-contrib] Re: Ant, ZipScanner, and GWT

[Colin Alworth]

So, given either "make a git repo on gwtproject/ and add a jar to 
gwtproject/tools" with the minimal history, or a single commit adding all 
already-modified classes to gwt in one go? I should be able to turn out either 
change fairly quickly, once we decide.

Adding to GWT directly would be somewhat lower friction (no need to ship a jar 
to central, easier to further tweak if something is screwy), but as I said, 
loses that tiny bit of history/context. Like you said, a forked jar is not at 
all new for the project to have, and is a nice way to say "this is external, 
even if we tweaked it a bit". For the zip distribution I imagine we'd shade it 
in to the overall zip, but for the m2 release it would probably be an external 
jar (since it will hopefully never change).

-- 
 Colin Alworth
co...@colinalworth.com



On Fri, Jun 12, 2020, at 1:36 PM, Thomas Broyer wrote:
> To minimize the work, and because 1.6.5 works well for us without known 
> vulnerability, I would either copy/paste the code into gwtproject/gwt or 
> provide it in a JAR in gwtproject/tools and call it a day. We already have a 
> copy of Rhino (with changes for JSNI), and a slimmed down version of jsilver 
> containing only the streamhtmlparser.
> No need to try to update and risk a breaking change, and no need to make it 
> "more maintainable" as I'm sure it'll be a one-shot anyway (and that decision 
> could be revisited in the future should we need to make changes to those Ant 
> classes).
> 
> On Friday, June 12, 2020 at 3:31:04 PM UTC+2, Colin Alworth wrote:
>> We have two issues tracking the dependency that GWT has on Ant, 
>> https://github.com/gwtproject/gwt/issues/9690 and 
>> https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and 
>> produced a minimal set of classes copied from ant which appear to provide a 
>> working ZipScanner. For the moment, this lives in its own git repository at 
>> https://github.com/vertispan/ant-zipscanner, and is not deployed anywhere.
>> 
>> I spent a while testing with latest ant, 1.10.8, but semantics have changed 
>> with the zip/directory scanner API such that leading "/" characters no 
>> longer match - rather than break behavior, I've instead switched to simply 
>> using the 1.6.5 code, and modified that for our purposes. This has the 
>> advantage of being substantially smaller than 1.10.8 - 18 types instead of 
>> 46, and of those 18, 11 are required for ant's own implementation of the zip 
>> format, so the other 7 are needed to scan a zip and match contents. It is 
>> quite likely that this could be pruned further, but might come at a cost 
>> when updating to some later ant version (should we decide to do that).
>> 
>> This repository is arranged in three commits:
>>  * Create a script to copy the classes we need from the ant repo, and a pom 
>> to ship these contents. The script is handy when iterating on a new version, 
>> but probably won't be needed unless we do attempt to use a new version
>>  * Copy all required classes from the tag "rel/1.6.5" in the upstream ant 
>> repo
>>  * Comment out anything which didn't compile due to missing dependencies (we 
>> have no use for Project or refs, we only call ZipScanner methods directly), 
>> or which modify the filesystem in some way (to limit risks when depending on 
>> this codebase
>> The resulting output is shaded into a new package by the pom so that it will 
>> not interfere with ant when GWT is compiled (or if GWT is invoked from ant). 
>> 
>> When GWT is updated to both include this jar and also to reference these new 
>> shaded classes instead of the originals within ant, all tests in dev/ pass 
>> and all samples compile, though I haven't yet run all of the other tests.
>> 
>> So, my question is then how to proceed. First of all, is this approach 
>> acceptable in terms of maintenance, or would we prefer reimplementing the 
>> API from scratch in order to drop this dependency, or just updating to the 
>> latest ant version for this one API?
>> 
>> Assuming we like the approach, should we incorporate these copied/modified 
>> sources into GWT itself, or add an additional jar to gwtproject/tools, with 
>> instructions on how to update it, and from there include it into the 
>> project? A somewhat related option could be releasing this jar to maven 
>> central under something like org.gwtproject.ant:ant-zipscanner, and 
>> maintaining it in the github.com/gwtproject umbrella.
>> 
>> Finally, is there any objection to staying with 1.6.5, or should I see if we 
>> can use a later version, or update GWT

Re: [gwt-contrib] Re: Ant, ZipScanner, and GWT

[Colin Alworth]

If I understand you, that is what I'm doing - I only the required 18 classes 
(with some members removed so that I don't need more than that), and am just 
seeking an opinion other than my own as to whether it is better to checked them 
straight into gwt as com.google.gwt.thirdparty.ant... classes, or into a 
standalone jar (to be clearer that this is external work+license, and have a 
pointer to where that work originated).

Ant works as a standalone jar as it is, so this would include no external 
dependencies, just these few classes either added directly to gwt, or to gwt's 
tools repo as a jar. The manual work is done, and it was fairly minimal (after 
i figured out the minimal set, and that latest ant doesnt work), just want to 
get thoughts on packaging/licensing, if there are any considerations.

-- 
  Colin Alworth
  co...@colinalworth.com

On Fri, Jun 12, 2020, at 5:19 PM, Peter Donald wrote:
> Possibly a dumb question ... but isn't it possible to just manually
> vendor in the source files to GWT? I can't imagine there is a whole
> lot of dependencies that would need to be maintained. Just strip out
> the gunk you don't need.
> 
> On Sat, Jun 13, 2020 at 7:05 AM Colin Alworth  wrote:
> >
> > So, given either "make a git repo on gwtproject/ and add a jar to 
> > gwtproject/tools" with the minimal history, or a single commit adding all 
> > already-modified classes to gwt in one go? I should be able to turn out 
> > either change fairly quickly, once we decide.
> >
> > Adding to GWT directly would be somewhat lower friction (no need to ship a 
> > jar to central, easier to further tweak if something is screwy), but as I 
> > said, loses that tiny bit of history/context. Like you said, a forked jar 
> > is not at all new for the project to have, and is a nice way to say "this 
> > is external, even if we tweaked it a bit". For the zip distribution I 
> > imagine we'd shade it in to the overall zip, but for the m2 release it 
> > would probably be an external jar (since it will hopefully never change).
> >
> > --
> >   Colin Alworth
> >   co...@colinalworth.com
> >
> >
> >
> > On Fri, Jun 12, 2020, at 1:36 PM, Thomas Broyer wrote:
> >
> > To minimize the work, and because 1.6.5 works well for us without known 
> > vulnerability, I would either copy/paste the code into gwtproject/gwt or 
> > provide it in a JAR in gwtproject/tools and call it a day. We already have 
> > a copy of Rhino (with changes for JSNI), and a slimmed down version of 
> > jsilver containing only the streamhtmlparser.
> > No need to try to update and risk a breaking change, and no need to make it 
> > "more maintainable" as I'm sure it'll be a one-shot anyway (and that 
> > decision could be revisited in the future should we need to make changes to 
> > those Ant classes).
> >
> > On Friday, June 12, 2020 at 3:31:04 PM UTC+2, Colin Alworth wrote:
> >
> > We have two issues tracking the dependency that GWT has on Ant, 
> > https://github.com/gwtproject/gwt/issues/9690 and 
> > https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and 
> > produced a minimal set of classes copied from ant which appear to provide a 
> > working ZipScanner. For the moment, this lives in its own git repository at 
> > https://github.com/vertispan/ant-zipscanner, and is not deployed anywhere.
> >
> > I spent a while testing with latest ant, 1.10.8, but semantics have changed 
> > with the zip/directory scanner API such that leading "/" characters no 
> > longer match - rather than break behavior, I've instead switched to simply 
> > using the 1.6.5 code, and modified that for our purposes. This has the 
> > advantage of being substantially smaller than 1.10.8 - 18 types instead of 
> > 46, and of those 18, 11 are required for ant's own implementation of the 
> > zip format, so the other 7 are needed to scan a zip and match contents. It 
> > is quite likely that this could be pruned further, but might come at a cost 
> > when updating to some later ant version (should we decide to do that).
> >
> > This repository is arranged in three commits:
> >
> > Create a script to copy the classes we need from the ant repo, and a pom to 
> > ship these contents. The script is handy when iterating on a new version, 
> > but probably won't be needed unless we do attempt to use a new version
> > Copy all required classes from the tag "rel/1.6.5" in the upstream ant repo
> > Comment out anything which didn't compile due to missing dependencies (we 
> > have no use for

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

[Colin Alworth]

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.

Will push shortly, compare notes.

-- 
 Colin Alworth
co...@colinalworth.com



On Sun, Jun 14, 2020, at 3:04 PM, Thomas Broyer wrote:
> 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 UTC+2, Colin Alworth wrote:
>> 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 
>> with, so that we can see which configurations cause which surprises.
>> 
>> Roughly, I'll deploy
>> 
>>  * LibraryWithNewGwt
>>  * LibraryWithOldGwt
>>  * LibraryWithBomAndNewGwt
>>  * LibraryWithBomAndOldGwt
>>  * LibraryWithTransitiveOldGwt (two flavors of this, one for each of the old 
>> gwt above)
>>  * LibraryWithTransitiveNewGwt (again, two flavors)
>> 
>> then try to build projects with old or new gwt, plus 1-2 of the libraries 
>> above. If a project ever detects more than one gwt version, we'll fail that, 
>> and go from there.
>> 
>> 
>>> 
>>> 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.
>> Good point - perhaps we just push a o.g:gwt:2.9.0 bom then, and encourage 
>> switching to just that? Same idea as before - projects can future proof 
>> themselves and move to this BOM, then only have to change its version in the 
>> BOM declaration to be correctly updated. This does miss out on some of the 
>> benefits though. Will hold off exploring until the above experiment has some 
>> results to share.
>> 
>> 
>>> 
>>> 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
>> Yeah, I was thinking about this - It would be nice if we could go back in 
>> time and add some nice version sentinel that can be scanned for across all 
>> jars, but About.properties is as good as anything. Confirming gwt-dev is 
>> current doesn't tell you much (plenty of libraries only use gwt-user), but 
>> hopefully it will catch the important cases. Probably should augment the 
>> above samples to have another axis: gwt-user, or gwt-user+gwt-dev on each 
>> library.
> 

> --
>  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/ef206a74-1c02-421b-a71a-3af43da0bf8ao%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/ef206a74-1c02-421b-a71a-3af43da0bf8ao%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/6f1a73b6-a843-437c-a38c-77a9924d7293%40www.fastmail.com.

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

[Colin Alworth]

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/153f88bc-b11c-4cd9-8049-b73940133df6%40www.fastmail.com.

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

[Colin Alworth]

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/8c2bd2d2-c869-4437-ae85-8efe574eef77%40www.fastmail.com.

[gwt-contrib] Re: Is there a doc which indicates which licenses are acceptable for imported code for use by the JRE Emulation?

[Colin Alworth]

I am not a lawyer, so I tend toward a very conservative interpretation of 
anything we come up with, and none of this is actual legal advice, just my 
understanding.

GWT is licensed/distributed under the Apache Public License 2.0, so any 
code contributed must be compatible with that license to let us continue to 
distribute as we do now. Using the GWT compiler, the JRE emulation will be 
transpiled and and distributed with your own code - remaining compatible 
with Apache matters here too, so that the legal requirements can 
consistently be met by developers using GWT and distributing licenses 
properly. 

At this time the main GWT repo is covered by Google's CLA (and I suspect 
that even if we stop using a CLA for GWT itself, the JRE will continue to 
use one, since it is shared by J2CL), which has a few limitations, such as 
needing to certify that you authored the code, and that if you didn't that 
you have the rights to contribute the code and have provided all of the 
licensing details. https://cla.developers.google.com/clas to read more 
about this. 

As an example, there is code included in GWT emulation that isn't 
copyrighted by Google, such as some emulation for javax.validation and 
hibernate validation implementation. These are licensed under APLv2 also.

Beyond this, I would suggest asking about specific cases/ideas you have in 
mind?

On Tuesday, June 16, 2020 at 9:57:06 AM UTC-5, Michael Conrad wrote:
>
> Is there a doc which indicates which licenses are acceptable for imported 
> code for use by the JRE Emulation? 
>

-- 
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/cf078843-6da5-4ed1-8896-b5162becc90do%40googlegroups.com.

[gwt-contrib] Thurs Jun 18 2020 GWT Contributors call

[Colin Alworth]

The call two weeks ago 
(https://groups.google.com/d/topic/google-web-toolkit-contributors/Tqgfb3QgGS0/discussion)
 
was fairly successful, so we're doing it again. Structure is again quite 
light, there will be a few items to get discussion going, and we'll let it 
take its own life from there.

We'll officially start at 5pm CEST / 11am EDT, though I'll plan to be on 
for at least an hour before then.

Frank Hossfeld will lead us off discussing Nalu, a lightweight gwt/j2cl 
compatible MVP tool.

Ahmad Bawaneh will give a short talk about domino-jackson, an updated (and 
converted from Generators to APT) version of gwt-jackson, a JSON-bean 
mapping tool familiar to many Java developers.

I'll do a live-coding demo of updating a simple application to use 
elemental2/"vanilla.js", if I get far enough and ambitious enough, we might 
manage to move it to J2CL and deploy it.

The call will probably run for a few hours off and on, but just an hour or 
two of "official" topics, the rest will be more informal discussion as 
people have time. We're staying on meet again this week out of inertia, may 
pick something else based on how the audience changes, or if we decide to 
record sessions. The link will be meet.google.com/nmu-mrky-mjo.

If you happen to have a microphone, that makes discussion a bit easier, but 
otherwise feel free to join and send remarks through the built-in text - 
meet is a bit annoying in that if you have to rejoin you'll lose old 
messages that were sent, that's another reason we're exploring other 
options.

-- 
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/bbd1dc65-ec53-402e-9ce2-d6b7aebb3a43o%40googlegroups.com.

Re: [gwt-contrib] CI / Jenkins configuration issue

[Colin Alworth]

Can you share the jenkins configurations as they exist today to ease the 
migration process? They don't seem to be checked in to the build glue or any 
other repository I noticed on the gwt.googlesource.com repo.

-- 
 Colin Alworth
co...@colinalworth.com



On Wed, Jun 17, 2020, at 10:29 AM, 'Roberto Lublinerman' via GWT Contributors 
wrote:
> The Jenkins server is online, however due to new security related policies on 
> the compute engine vms run by our teams, we cannot give public access to the 
> Jenkins instance. 
> 
> The CI build is running as scheduled. The presubmit is broken, as far as I 
> can tell it was broken long ago by a Jenkins update. It seems that our go 
> presubmit code needs to be updated on how it does the presubmit request to 
> Jenkins, I think it just needs to be changed from http get to http post.
> 
> Given the low number of contributions I do not mind triggering presubmit 
> manually, so just ping me. But moving forward, the CI server needs to be 
> moved out of our internal infrastructure. If you want to have a look on why 
> the presubmit trigger 
> (https://gwt.googlesource.com/buildglue/+/refs/heads/master/jenkins/jenkins.go)
>  is failing you could probably replicate it locally and if anybody 
> contributes a fix I'll apply it to our server. I currently do not have much 
> bandwidth to devote to any of this.
> 
> 
> On Wed, Jun 17, 2020 at 12:59 AM Jens  wrote:
>> Any news here?
>> 
>> The Leeroy Jenkins spam is really annoying in code reviews.
>> 
>> -- J.
>> 

>> --
>>  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/4d9695b1-bf52-4792-a0c5-c4cb413487abo%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/4d9695b1-bf52-4792-a0c5-c4cb413487abo%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/CAC7T7gnmMbRX6avp6Ca%2BNCye0kH5R8%3DSS%2B9%2Bv%2B6c3qAkwGOLdQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gnmMbRX6avp6Ca%2BNCye0kH5R8%3DSS%2B9%2Bv%2B6c3qAkwGOLdQ%40mail.gmail.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/6bbd26e9-a3a8-4140-b69f-d3897a534815%40www.fastmail.com.

Re: [gwt-contrib] Resolving cycle dependency between gwt-safehtml & gwt-safecss

[Colin Alworth]

One potential option could be moving the tests into gwt-safecss, and only 
release them together - the release process through sonatype will permit 
you to push more than one set of artifacts, test them in the staging repo, 
and then release to central together. That would imply using either local 
artifacts to build gwt-safecss (instead of pulling from central), or 
temporarily adding the staging repo to the pom.

It does seem simpler to just merge to gwt-safehtml - especially since I 
doubt that gwt-safecss is often used by itself.

On Thursday, June 25, 2020 at 3:19:05 PM UTC-5 juan_pablo_gardella wrote:

> Not too much options I think, see 
> https://stackoverflow.com/questions/55429921/how-to-fix-cyclic-dependency-between-java-modules
>
> Maybe a new common shared module (maven artifact in this case) or merge 
> safehtml and safecss into a new one and let them deprecated.
>
> Juan
>
> On Thu, 25 Jun 2020 at 17:14, 'Frank Hossfeld' via GWT Contributors <
> google-web-tool...@googlegroups.com> wrote:
>
>> To prepare GWT for j2cl we need to move the modules out of GWT, replace 
>> generators with ATP, etc. This is in progress and the first modules 
>> (SNAPSHOT) are released.
>>
>> Migrating gwt-safehtml and gwt-safecss runs into a problem, cause 
>> gwt-safehtml depends on gwt-safecss and gwt-safecss depends on 
>> gwt-safehtml. This is a serious issue, cause one can not be build and 
>> tested without the other. 
>>
>> To solve this issue, we are looking for solutions.
>>
>> One solution might be to move the tests out of gwt-safehtml. But then 
>> gwt-safehtml needs to be build and deployed before the tests run and might 
>> be deployed with failing tests. That looks like a bad solution.  At the 
>> moment the idea is to move the sources and tests from gwt-safecss into 
>> gwt-safehtml and delete gwt-safecss. This will remove the cycle dependency 
>> between these two modules, but doing so, the module will be the first 
>> module that contains two old modules in one new.
>>
>> Any other ideas how to solve this issue?
>>
>> -- 
>> 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/a8d6c785-c8d9-4eba-8cc2-0b42ecac1124o%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/8b4addde-bf52-4a88-b38f-fd2c0493f9f9n%40googlegroups.com.

Re: [gwt-contrib] Re: Resolving cycle dependency between gwt-safehtml & gwt-safecss

[Colin Alworth]

I may be putting words in Frank's mouth, but I believe the proposal to "merge" 
these is only to bring them into a single git repository, rather than one 
repository per module - so option #4 is specifically what he is proposing (with 
lots of room for optional other changes like 1, 2). We still very much want 
separate artifacts for these (many small-but-not-tiny artifacts is ideal for 
j2cl), and since the cycle is just around tests that seems complete enough 
(especially given the current annoyances in testing j2cl vs gwt2).

On Fri, Jun 26, 2020, at 8:07 AM, Thomas Broyer wrote:
> AFAICT, safecss depends on SafeUri only, which currently is in 
> com.google.gwt.safehtml, and safehtml depends on both SafeUri and SafeStyles 
> (though only for their class names during codegen, so optional except for 
> tests).
> 
> This means that either:
>  1. we split up a gwt-safeuri (with UriUtils, SafeUri, SafeUriString, 
> IsSafeUri, etc.)
>  2. we split up a gwt-safehtml-templates so we can have safehtml-templates 
> depend on both safehtml and safecss, with safecss depending on safehtml (for 
> its safeuri)
>  3. we merge everything despite having separate packages and gwt.xml
>  4. we put everything in the same project, but still separate artifacts, so 
> we can have tests (split into their own submodule) depend on both safehtml 
> and safecss without having safehtml depending on safecss (given that we also 
> need the reverse)
>  5. we do nothing. The dependency cycle actually only exists when none of the 
> projects have been published (even as snapshots), so publish safehtml without 
> the dependency (and with the corresponding tests disabled; possibly split 
> into a separate submodule so you can easily ignore them) and then you can 
> build safecss and publish it, and finally run safehtml tests. Once we've past 
> the snapshots phase and actually have tagged versions, this means safehtml 
> will always be one release of safecss behind.
> Options 1, 2, and 4 are not mutually exclusive actually.
> 
> I'd personally go with all 1, 2, and 4 options, which provide fine-grain 
> modularity for users, and a coarser one for developers (develop, test, and 
> release everything at once). Migration from com.google.gwt to org.gwtproject 
> would be slightly more complex than a blind "replace com.google.gwt.safehtml 
> with org.gwtproject.safehtml", but that's already the case for gwt-event.
> 
> 
> On Thursday, June 25, 2020 at 10:14:46 PM UTC+2, Frank Hossfeld wrote:
>> To prepare GWT for j2cl we need to move the modules out of GWT, replace 
>> generators with ATP, etc. This is in progress and the first modules 
>> (SNAPSHOT) are released.
>> 
>> Migrating gwt-safehtml and gwt-safecss runs into a problem, cause 
>> gwt-safehtml depends on gwt-safecss and gwt-safecss depends on gwt-safehtml. 
>> This is a serious issue, cause one can not be build and tested without the 
>> other. 
>> 
>> To solve this issue, we are looking for solutions.
>> 
>> One solution might be to move the tests out of gwt-safehtml. But then 
>> gwt-safehtml needs to be build and deployed before the tests run and might 
>> be deployed with failing tests. That looks like a bad solution. At the 
>> moment the idea is to move the sources and tests from gwt-safecss into 
>> gwt-safehtml and delete gwt-safecss. This will remove the cycle dependency 
>> between these two modules, but doing so, the module will be the first module 
>> that contains two old modules in one new.
>> 
>> Any other ideas how to solve this issue?
> 

> --
>  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/10f49ebb-6824-4f2e-ba55-468566c6c156o%40googlegroups.com
>  
> .

-- 
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/0e6b4dde-8046-4db5-80f8-a4435ff8a518%40www.fastmail.com.

[gwt-contrib] Required JDK version to build GWT?

[Colin Alworth]

As of somewhere in the time leading up to the GWT 2.9.0 release, it is no 
longer possible to build GWT with Java7, and similarly the decision was 
made to no longer officially support running on Java7 
(jsinterop-annotations use of "TYPE_USE", newer jetty version too I 
believe). 

There is still some defunct wiring in the build to handle Java 7 vs Java 8 
though, mostly with regards to running tests - since we first javac our 
java classes, and then run gwtc on them, we need to make sure that the java 
version being use can correctly compile those tests.

The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some of 
the existing work on this: the main remaining piece is to decide how to 
handle javadoc. GWT has its own custom doclet to handle a few custom tags, 
"example", "gwt.include", and "tip". None of this compiles after Java 8, 
since Java 9 came with a new, incompatible API to build custom tags, so 
either we drop Java 8 support for building the toolkit, require _only_ Java 
8 to build, support two parallel copies of the custom doc wiring, or drop 
the doc wiring entirely and remove these custom tags throughout the 
codebase.

Since the release of GWT 2.9 and my own work on the above ticket, I've been 
picking back up some Java 9/10/11 JRE emulation work that I had previously 
paused, and I'm running into the issue described at the top - if you write 
a test that calls Map.of() and run it on Java8 as a GWTTestCase, you'll get 
a compile error.

Two basic ways I can easily see to fix this: we can make two copies of each 
test, one as an empty "real" java type and one as supersource, or we can 
guard those tests behind java version args in the build glue like we did 
for Java7 vs Java8. The first option is clunky, and while I see this was 
done for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't done 
for JRE emulation tests, and I assume there was a reason for that. The 
second option requires changing our CI to build+test on some new JRE...

...and given the constraints of the Java LTS system, and the java 8/9 
divide for custom doclet stuff, it seems like the clearest win is to move 
all the way to Java11, though continue to target java 8 releases, and test 
on all JREs up until current.

So that's my pitch. For completeness, some other options that seem 
workable, keeping in mind that at present there are about 3 important JRE 
versions to support well: Java 8, Java 11, and the current stable release.
 * Require Java8 for javadoc, supersource tests
 * Allow any JRE 8+, use ant filters for tests for each version, maintain 
two javadoc builds
 * Allow any JRE 8+, use ant filters, only actually produce javadoc on 
java9+ builds

Other technical ways to deal with this, or have a missed an easier solution 
to one of these problems?

-- 
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/0aa0701b-4287-4e4c-bbef-23952898c64an%40googlegroups.com.

Re: [gwt-contrib] Required JDK version to build GWT?

[Colin Alworth]

Right - the excludes via ant are certainly an option ("use ant filters"), my 
main hope is to avoid adding another stanza of xml for the emulation for each 
release. Cutting out Java7 and adding a "java 11 or higher" to lump all the 
java 9, 10, 11 tests in would at least be a net equal in XML from what we have 
today (since compiling under Java 7 isn't an option), but still a bit messier 
than I'd like - especially if we agree that "run all internal tests in Java11" 
is reasonable (plus another few build steps to validate the build under other 
versions of Java). 

If that isn't deemed reasonably, we'll need a Java9 check (for the new of() 
methods), Java 10 check (new optional methods, collections copyOf), Java 11 
check (string methods) to get caught up with the JDT we're using today, and 12, 
13, 14 are out now, with 15 soon. Again, not impossible, just perhaps messy - 
and unwinding the "java8" flag (which really seems to mean "newer than java7") 
is less fun than I'd like.

-- 
 Colin Alworth
co...@colinalworth.com



On Mon, Jun 29, 2020, at 9:21 PM, 'Goktug Gokdogan' via GWT Contributors wrote:
> wrt running tests:
> See https://gwt-review.googlesource.com/c/gwt/+/13861 for the pattern used in 
> JRE earlier; and the CI was updated to run in both 7 and 8 at the same time.
> 
> PS: Compiler tests ("jjs.test.Java8Test") was different because we really 
> needed to run the compiler tests with new syntax inside Google which didn't 
> have the Java8 VM at the time. It wasn't a deal breaker to be not able run 
> Java8 JRE tests at the time so they are not super sourced.
> 
> I recommend the same approach.
> 
> 
> On Mon, Jun 29, 2020 at 6:45 PM Colin Alworth  wrote:
>> As of somewhere in the time leading up to the GWT 2.9.0 release, it is no 
>> longer possible to build GWT with Java7, and similarly the decision was made 
>> to no longer officially support running on Java7 (jsinterop-annotations use 
>> of "TYPE_USE", newer jetty version too I believe). 
>> 
>> There is still some defunct wiring in the build to handle Java 7 vs Java 8 
>> though, mostly with regards to running tests - since we first javac our java 
>> classes, and then run gwtc on them, we need to make sure that the java 
>> version being use can correctly compile those tests.
>> 
>> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some of 
>> the existing work on this: the main remaining piece is to decide how to 
>> handle javadoc. GWT has its own custom doclet to handle a few custom tags, 
>> "example", "gwt.include", and "tip". None of this compiles after Java 8, 
>> since Java 9 came with a new, incompatible API to build custom tags, so 
>> either we drop Java 8 support for building the toolkit, require _only_ Java 
>> 8 to build, support two parallel copies of the custom doc wiring, or drop 
>> the doc wiring entirely and remove these custom tags throughout the codebase.
>> 
>> Since the release of GWT 2.9 and my own work on the above ticket, I've been 
>> picking back up some Java 9/10/11 JRE emulation work that I had previously 
>> paused, and I'm running into the issue described at the top - if you write a 
>> test that calls Map.of() and run it on Java8 as a GWTTestCase, you'll get a 
>> compile error.
>> 
>> Two basic ways I can easily see to fix this: we can make two copies of each 
>> test, one as an empty "real" java type and one as supersource, or we can 
>> guard those tests behind java version args in the build glue like we did for 
>> Java7 vs Java8. The first option is clunky, and while I see this was done 
>> for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't done for JRE 
>> emulation tests, and I assume there was a reason for that. The second option 
>> requires changing our CI to build+test on some new JRE...
>> 
>> ...and given the constraints of the Java LTS system, and the java 8/9 divide 
>> for custom doclet stuff, it seems like the clearest win is to move all the 
>> way to Java11, though continue to target java 8 releases, and test on all 
>> JREs up until current.
>> 
>> So that's my pitch. For completeness, some other options that seem workable, 
>> keeping in mind that at present there are about 3 important JRE versions to 
>> support well: Java 8, Java 11, and the current stable release.
>>  * Require Java8 for javadoc, supersource tests
>>  * Allow any JRE 8+, use ant filters for tests for each version, maintain 
>> two javadoc builds
>>  * Allow any JRE 8+, use ant filte

Re: [gwt-contrib] Re: Required JDK version to build GWT?

[Colin Alworth]

e doclets on JDK8, this means we have to run the build twice 
>>> when cutting 
>>>  a release: once with JDK.lts/JDK.latest to make sure the tests 
>>> pass, and 
>>>  then once with JDK8 to actually build the artifacts.
>>>  - con: requires setting up the new JDKs, and new jobs, on the 
>>>  CI server. If we keep using the current build.gwtproject.org, 
>>>  this puts the burden on Google; that'd likely precipitate the 
>>> replacement 
>>>  of the server.
>>>  - con: requires 2 builds to make sure things still build/run 
>>>  with JDK8
>>>   - Supersourcing
>>>   - pro: tests can run with JDK8, so the whole build is 
>>>   JDK8-compatible and still covers all tests
>>>   - con: requires somehow maintaining the tests twice, keeping the 
>>>   javac'd and supersourced versions in sync (AFAIK, the javac'd version 
>>> has 
>>>   to have the test methods so they're detected by JUnit, even if their 
>>> body 
>>>   is empty; so it would be rather easy to add a test to the 
>>> supersourced 
>>>   version and never actually run it because the method is missing from 
>>> the 
>>>   javac'd version)
>>>
>>> The situation requiring the minimum effort in the short term would be 
>>> keeping the doclets as they are and using supersourcing for the tests.
>>> In the long run, as JDK9+ tests grow, supersourcing might become 
>>> unsustainable, but the impact on the CI server et al. is non-negligible. We 
>>> could still possibly, at least temporarily, build only with JDK8, and only 
>>> run the JDK9+ tests once in a while (at release time?), manually on a 
>>> developer's machine as a smoke test.
>>>
>>> So, my vote would be: "require JDK8 for javadoc, supersource tests", 
>>> with a fallback to an option you didn't list: "Allow any JDK 8+, use ant 
>>> filters, only actually produce javadoc on JDK8 builds", and if/when someone 
>>> wants to put the effort then migrate the doclets and move on to your third 
>>> option: "allow any JDK8+, use ant filters, only actually produce javadoc on 
>>> JDK9+ builds"
>>>
>>> On Tuesday, June 30, 2020 at 3:45:36 AM UTC+2, Colin Alworth wrote:
>>>>
>>>> As of somewhere in the time leading up to the GWT 2.9.0 release, it is 
>>>> no longer possible to build GWT with Java7, and similarly the decision was 
>>>> made to no longer officially support running on Java7 
>>>> (jsinterop-annotations use of "TYPE_USE", newer jetty version too I 
>>>> believe). 
>>>>
>>>> There is still some defunct wiring in the build to handle Java 7 vs 
>>>> Java 8 though, mostly with regards to running tests - since we first javac 
>>>> our java classes, and then run gwtc on them, we need to make sure that the 
>>>> java version being use can correctly compile those tests.
>>>>
>>>> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking 
>>>> some of the existing work on this: the main remaining piece is to decide 
>>>> how to handle javadoc. GWT has its own custom doclet to handle a few 
>>>> custom 
>>>> tags, "example", "gwt.include", and "tip". None of this compiles after 
>>>> Java 
>>>> 8, since Java 9 came with a new, incompatible API to build custom tags, so 
>>>> either we drop Java 8 support for building the toolkit, require _only_ 
>>>> Java 
>>>> 8 to build, support two parallel copies of the custom doc wiring, or drop 
>>>> the doc wiring entirely and remove these custom tags throughout the 
>>>> codebase.
>>>>
>>>> Since the release of GWT 2.9 and my own work on the above ticket, I've 
>>>> been picking back up some Java 9/10/11 JRE emulation work that I had 
>>>> previously paused, and I'm running into the issue described at the top - 
>>>> if 
>>>> you write a test that calls Map.of() and run it on Java8 as a GWTTestCase, 
>>>> you'll get a compile error.
>>>>
>>>> Two basic ways I can easily see to fix this: we can make two copies of 
>>>> each test, one as an empty "real" java type and one as supersource, or we 
>>>> can guard those tests behind java version args in the

Re: [gwt-contrib] Re: Required JDK version to build GWT?

[Colin Alworth]

Okay, sounds good, I think these are compatible goals. Restating here to make 
sure I understood clearly, then I'll make a few notes on the existing tickets, 
new tickets to track this:
 * ant test (more or less) should correctly filter out java9+ jre emulation 
tests when run from Java 8. All tests will be run in Java 11 (or Java.latest, 
when we add tests that require a newer JDK)
 * ant dist-dev should run correctly in Java 8, Java 11, and Java.latest
 * Based on the current status of javadoc, ant dist will for now run on Java8 
only, then later only on any Java9+. (elemental hasnt actually been removed 
yet, but I have a patch for it...)

Steps to achieve this, roughly in order:
 * Remove Java 7/8 filters in ant wiring, make everything run cleanly/simply on 
Java 8 alone
 * Finish making the distribution part of the code run cleanly on Java >=9 
(https://gwt-review.googlesource.com/c/gwt/+/22640 is the last step until this 
is finished)
 * Update build to skip any doc tasks when on Java >8
 * Add Java <11 filters to ant wiring, allowing specific tests to be excluded 
when running on something older than Java 11 in anticipation of this emulation 
to be finished, landed.
 * Update Javadoc to support >8 only, update build to skip any doc tasks when 
on Java 8



On Wed, Jul 1, 2020, at 11:34 AM, Thomas Broyer wrote:
> 
> 
> On Wednesday, July 1, 2020 at 3:32:34 AM UTC+2, Colin Alworth wrote:
>> Thanks Goktug for clarifying - I am personally in favor of a more coarse 
>> approach, more future proofed approach that will end up with making changes 
>> now rather than later. And to your followup, agreed, all else equal, let's 
>> avoid supersource.
>> 
>> Thomas - While I made a Java8-first option was the first bullet at the end 
>> of my email, I deliberately skipped the option of "we can either produce 
>> build artifacts, or test the output, but not both in the same build", but it 
>> may be worth considering, even if it means each release has to be built 
>> twice.
>> 
>> My thinking on the javadoc wiring is that it is better done once, and better 
>> done sooner than later. There are other advantages to modernizing the 
>> javadoc: dropping the deprecated API, search, etc. If the concern is only 
>> saving the effort of this work, then I'm happy to own this task, if we think 
>> it would be preferred to only produce output artifacts using Java8 then it 
>> seems it wouldn't make sense to try it at all, at least until we get closer 
>> to something resembling a Java 8 EOL, or find ourselves needing a baseline 
>> higher than Java 8 for other reasons. That is, optimizing for 
>> minimum-effort-today has its advantages, but my current mindset was to seek 
>> to future proof a bit, as long as I'm excising Java7-specific things and 
>> ensuring other code builds on Java9+.
>> 
>> With the assumption that Javadoc is handled, is there any objection to 
>> requiring Java 11+ to run tests, Java 9+ to produce a complete build? It 
>> sounds like this is the direction everyone is moving, only supporting tests 
>> in a limited range of versions, only supporting releases in a limited range 
>> of versions (or, just one), or is the objection specifically to dropping 
>> Java 8 as the build version of choice?
> 
> I'm concerned with dropping JDK 8 testing. If we want to make sure it works 
> with JDK 8, we have to test with JDK 8. If we want to make sure it works with 
> JDK 11, we have to test with JDK 11. (IMO, supporting JDK14, then 15, etc. 
> would only be a bonus)
> Given how Ant works, this probably does not mean *building* (the non-test 
> code) with either, i.e. we could probably build and test with JDK8 
> (JAVA_HOME=… ant build) and then run tests with JDK 11 (JAVA_HOME=… ant test, 
> in the same directory, reusing the classes already compiled by the previous 
> build with the other JDK), or the reverse.
> Of course, it also depends what we want to test!
> Unfortunately, JDK 8 and JDK 9+ are different enough (at runtime) that we'd 
> really want to test both (AFAIK, we(you) only did smoke tests with JDK 11 for 
> GWT 2.9.0, and smoke tests might actually be enough)
> 
> So, what do we want to achieve?
>  * Make it possible to "ant dist-dev" and "ant test" with JDK 11 (or even 
> 14)? to run JDK9+ specific tests (and make it easier for anyone to contribute)
>  * Make it possible to "ant clean elemental dist" with JDK 11 (or even 14)? 
> (this could/would mean dropping support for JDK 8 for "ant doc", but keep 
> "ant dist-dev" and "ant test" working)
> In any case, I believe we should keep "ant dist-dev" and "ant test" workin

[gwt-contrib] Thurs July 2 2020 GWT community call

[Colin Alworth]

We're going to try recording tomorrow, just for the specific 'sessions' 
that are planned, so the video should be available afterward, I'll link in 
a follow up post when they are ready.

Three planned topics to record:
 * Ahmad Bawaneh presenting domino-history, a simple routing tool to 
manipulate the url and browser history, based on the pushState API, but 
intended to be usable in other platforms like the JVM in the future
 * Rafat Al-Barouki presenting domino-rest, a follow up to Ahmad's talk 
last time on domino-jackson, this tool lets you take jax-rs interfaces and 
generate gwt/android/jvm compatible clients with no runtime reflect
 * Frank Hossfeld presenting gwt-editor, a quick talk to show how to move 
an existing project to the annotation-processor based editor framework

We'll also have a probably-unrecorded discussion looking at some modern 
compiled web applications to identify if GWT is being used, looking at some 
of the differences and similarities between closure-compiled j2cl and gwt2 
output.

The talks will formally start at 5pm CEST / 11am EDT, but the call will be 
available to join about an hour earlier, I'll share a link to join here. 
Outside of the sessions above, nothing will be recorded, and we'll probably 
be discussing other topics around contributing to the gwt ecosystem - main 
topic this week will be revisiting internationalization and reducing dev 
mode and prod mode code size.

-- 
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/309b9227-0b54-4f94-b14b-e31df9c73b24o%40googlegroups.com.

[gwt-contrib] Re: Thurs July 2 2020 GWT community call

[Colin Alworth]

Meeting link is at https://meet.google.com/jbs-wier-ywp - we will start 
recording in about an hour, and will only publish the three talks listed 
below.

On Wednesday, July 1, 2020 at 12:58:15 PM UTC-5, Colin Alworth wrote:
>
> We're going to try recording tomorrow, just for the specific 'sessions' 
> that are planned, so the video should be available afterward, I'll link in 
> a follow up post when they are ready.
>
> Three planned topics to record:
>  * Ahmad Bawaneh presenting domino-history, a simple routing tool to 
> manipulate the url and browser history, based on the pushState API, but 
> intended to be usable in other platforms like the JVM in the future
>  * Rafat Al-Barouki presenting domino-rest, a follow up to Ahmad's talk 
> last time on domino-jackson, this tool lets you take jax-rs interfaces and 
> generate gwt/android/jvm compatible clients with no runtime reflect
>  * Frank Hossfeld presenting gwt-editor, a quick talk to show how to move 
> an existing project to the annotation-processor based editor framework
>
> We'll also have a probably-unrecorded discussion looking at some modern 
> compiled web applications to identify if GWT is being used, looking at some 
> of the differences and similarities between closure-compiled j2cl and gwt2 
> output.
>
> The talks will formally start at 5pm CEST / 11am EDT, but the call will be 
> available to join about an hour earlier, I'll share a link to join here. 
> Outside of the sessions above, nothing will be recorded, and we'll probably 
> be discussing other topics around contributing to the gwt ecosystem - main 
> topic this week will be revisiting internationalization and reducing dev 
> mode and prod mode code size.
>

-- 
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/f1a6d70d-da6b-4443-b868-e0ca38b85188o%40googlegroups.com.

[gwt-contrib] Thurs July 16 2020 GWT community call

[Colin Alworth]

We have a shorter itinerary this week - I'll record a short piece on 
j2cl-maven-plugin and how to start a project with it, try using pieces from 
the ecosystem.

Dmitrii, Ahmad and I will continue our brainstorming about efficiently 
producing both optimized output and minimizing the work the compiler does 
for i18n/cldr generated code.

We'll probably also continue poking around j2cl/closure output to recap 
what we learned about string concatenation last time, understand why this 
makes sense, possibly try to make the output improve a bit.

The first video from last call was published earlier this week, the second 
one will probably go out tomorrow. The first video can be found at 
https://www.youtube.com/watch?v=7uFUoL1vpMI, we'll continue to publish the 
other videos to the same channel.

We'll get started at our usual time, 5pm CEST / 11am EDT. The call will be 
on Google Meet again, but we're open to options that can record at a higher 
resolution and not force the presenter's picture into frame and hurt 
readability.

https://meet.google.com/aru-fdpg-cjf

-- 
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/dbcbb3f4-e093-4235-89b7-9f8b9a65846bo%40googlegroups.com.

Re: [gwt-contrib] Thurs July 16 2020 GWT community call

[Colin Alworth]

It went well - it was a smaller crowd, probably in part due to fewer "talks" 
and more "contrib", but that's a balance we're going to have to continue to 
strike.

The main focus was on getting closure to provide the sort of optimization we've 
come to expect from gwt2, and we had a surprisingly large amount of difficulty 
in getting it to do this. I'm doing a writeup now for the closure compiler 
list, since we've got a fairly simple set of plain example JS that demonstrates 
the issue. The biggest concern is that this means that you have to use raw JS 
to "explain" this pattern to the compiler, otherwise it will not understand and 
will not bother to prune/optimize code, but our guess right now is that this is 
a specific enough of a use case that we can provide tooling to solve this 
problem, and that tooling can generate JS instead of developers writing it. 
Also worth noting that j2cl+closure has been at least on par with gwt2 if not 
smaller in the examples we've tried so far, so especially if it tends to 
generate sub-optimal code in a few cases, we know it is doing a far better job 
than gwt2 in other cases. 

Next week we have two talks planned already, and have room for 1-2 more if 
anyone is interested. As usual, the call will start an hour early with no set 
topic, instead anyone can ask questions or make suggestions on what we can 
discuss. 
https://calendar.google.com/event?action=TEMPLATE&tmeid=MXVmcmw1czU5cHMxYm5lcHEzZWQ0MjR2ODUgY29saW5AdmVydGlzcGFuLmNvbQ&tmsrc=colin%40vertispan.com

-- 
  Colin Alworth
  co...@colinalworth.com



On Tue, Jul 21, 2020, at 8:24 AM, Michael Conrad wrote:
> How did it go?
> 
> 
> On 7/15/20 5:02 PM, Colin Alworth wrote:
>> We have a shorter itinerary this week - I'll record a short piece on 
>> j2cl-maven-plugin and how to start a project with it, try using pieces from 
>> the ecosystem.
>> 
>> Dmitrii, Ahmad and I will continue our brainstorming about efficiently 
>> producing both optimized output and minimizing the work the compiler does 
>> for i18n/cldr generated code.
>> 
>> 
> 
> 

> --
> 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/864efc55-2de0-3db7-be88-e3fe9170da42%40newsrx.com
>  
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/864efc55-2de0-3db7-be88-e3fe9170da42%40newsrx.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/17bf2f7e-77ca-4fd7-959b-e2412f0047c0%40www.fastmail.com.

[gwt-contrib] Re: Documentation of compiler optimisations?

[Colin Alworth]

GWT itself hasn't changed substantially in many years - improvements have 
mostly been language features, adding support for incremental compilation, 
the jsinterop system, etc, so for the most part the optimizations haven't 
changed.

That said, the best way is almost certainly to take a look at the source 
code itself, and the JavaToJavaScriptCompiler class has the high level 
aspects of this. This is a different way to look at the current process, 
but might give you helpful insights in contrast to the link you shared.

Starting in the compilePermutation() method: 
https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#L304-L467
This method is well commented, showing the order of operations that take 
place. Optimizations on Java source itself largely happens at the 
optimizeJava() method, which itself does very little, just check if it 
should run, and if so, invokes optimizeJavaToFixedPoint(), then applies one 
last optimization: RemoveEmptySuperCalls. optimizeJavaToFixedPoint() can be 
found at 
https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#L1415-L1457
though it largely just invokes optimizeJavaOneTime in a loop until the code 
stops changing, and follows up with one optional run to the 
DataflowOptimizer. optimizeJavaOneTime can be found at
https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#L1492-L1517
Here you can see the optimizations that happen in the main optimization 
loop, with a small handful of notes on the order that these must take place.

After this we're back to the compilerPermutation method, which finishes 
normalizing the code to JS and continuing to optimize this lightly, though 
not in a loop, just a few specific passes.




On Thursday, October 1, 2020 at 3:52:04 PM UTC-5 George Georgovassilis 
wrote:

> Is there an up-to-date documentation of optimisations the compiler 
> applies? An older page [1] discusses some topics but it isn't clear what of 
> that has been implemented.
> (apologies for posting here, I asked this question on the user forum [2] 
> but didn't get any replies)
>
> [1] 
> https://github.com/gwtproject/old_google_code_wiki/blob/master/AdvancedCompilerOptimizations.wiki.md
> [2] https://groups.google.com/g/google-web-toolkit/c/aOBvgbKjjcw
>
>

-- 
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/35d8b2c8-59a7-4e4c-a252-08ba7cb07fe6n%40googlegroups.com.

Re: [gwt-contrib] Re: Goodbye IE 8–9 👋

[Colin Alworth]

I've just filed https://github.com/gwtproject/gwt/issues/9739, where a 
workaround exists in java.util.Date that nearly doubles the time it takes 
to parse date strings and build date objects. This workaround exists for 
IE8 and IE9, as all more recent browsers implement the same behavior as we 
already would expect. Dropping support for those two browsers would 
simplify the code required here

>From the age of this thread and the discussion so far, it sounds like there 
is interest in keeping IE11 still, but no one has spoke up about IE10 or 
below. 

Additionally, java.util.Random emulation was changed to require Date.now(), 
which isn't available in IE8, so neither GWT 2.8.2 nor GWT 2.9.0 are 
apparently compatible with IE8 anyway, at least in this small way. This 
should give us some confidence (along with the lack of opposition in this 
thread) that at least IE8 is definitely safe to drop.

So, is there any objection at this time to dropping what remains of IE8, 
IE9, and IE10 support from GWT? Then, we can reevaluate IE11 at some later 
date, for GWT itself? Various migrated GWT modules have focused their 
efforts on well-supported browsers, and are likely to only support IE11 by 
accident anyway.

On Friday, March 12, 2021 at 1:20:02 AM UTC-6 stuckagain wrote:

> We still need IE11 support in the banking sector. We still have a majority 
> of customers that use IE11 due to technical reasons (plugins needed for 
> accessing secure token don’t install properly in Chrome without internet 
> access amongst others).
>
> What do you mean with “next version of GWT” if that is 3.x then I don’t 
> care at this point. We have been waiting for that release for a few years 
> now. But 2.x releases should not drop IE11 support it is supposed to be a 
> long-term supported version.
> On 12 Mar 2021, 07:54 +0100, bernhar...@schubec.com <
> bernhar...@schubec.com>, wrote:
>
> Hi all! 
>
> I think IE11 support should be dropped soon if it blocks (or makes it 
> difficult) to implement new features in the next version of GWT.
> I understand, that there are enterprises who still use IE11 internally, 
> but developers who service such enterprises should use the current version 
> of GWT, which is not going away. Nobody is forced to upgrade to the next 
> version of GWT.
>
> Thanks,
> Berni 
>
> tony.be...@gmail.com schrieb am Donnerstag, 11. März 2021 um 22:26:21 
> UTC+1:
>
>> IE 11 is still widely used inside corporations, because it is the only 
>> browser that supports Java applets, and applications such as Oracle 
>> e-Business Suite still use applets extensively (for Oracle forms). While 
>> that segment does not move very fast, it does not mean other unrelated 
>> groups within the same corporation are not updating GWT regularly. It is 
>> hard to generalize In a multinational company  with tens of thousands of 
>> employees. 
>>
>> Regards
>>
>> Tony
>>
>> On Thu, Mar 11, 2021 at 9:49 AM Jens  wrote:
>>
>>> Dropping IE 8-10 shouldn't really hurt. Companies that require it are 
>>> probably not upgrading GWT in a fast pace anyways.
>>>
>>> However I wouldn't drop IE 11 anytime soon. IE 11 itself is tied to the 
>>> lifecycle of Microsoft's operating systems, which means for Windows 10 it 
>>> is supported until 2025 (for now). So just because MS and Google drop 
>>> support for IE 11 in some/all of their products, the browser itself is 
>>> still generally supported by MS. So we should think twice before removing 
>>> IE 11 from a library such as GWT, even if it means to decline/revert 
>>> certain commits if they break IE 11. From own experience I have usually 
>>> seen something around 8% of IE 11 usage in GWT based apps. 
>>>
>>> However I am pretty sure more and more companies will announce dropping 
>>> IE 11 this year or next year. With MS and Google starting, this could 
>>> easily have a domino effect. However GWT also also strongly used internally 
>>> inside companies so it might not have that much of an effect in that area.
>>>
>>> If we ditch IE 8-10 and only leaving gecko1_8 and safari, can't we kill 
>>> them both as well and put them together? Are there so many differences in 
>>> code between both? From my work migrating GWT code to elemental2/JsInterop 
>>> I had the feeling that only some minor stuff is different between both. So 
>>> there shouldn't be that much overhead in code size and performance doing 
>>> (cached) runtime checks instead.
>>>
>>> -- J.
>>>
>>> --
>>> 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/031f1171-cce9-4c17-b717-80bb5730f7fdn%40googlegroups.com
>>>  
>>> 

[gwt-contrib] GWT 2.10 release?

[Colin Alworth]

We've got a few changes that have been brewing or waiting to be made 
available, and it sounds like it is about time to collectively push to make 
these things happen. Given the nature of some of these, I am suggesting 
that they not be folded into a bugfix release, but instead that the next 
release be 2.10.0.


Changing Maven Central groupId
One of the big ones is work to migrate off of the "com.google.gwt" groupId 
(note that we are not adjusting packages) and into our own namespace in 
maven, "org.gwtproject.gwt". Google's efforts to open sourcing and 
encourage GWT has been very accommodating for the community, and this 
change is long past due, so that releases of GWT do not need someone with 
access to the com.google groupId in Maven Central to perform the release 
process for us. If successful, this will be the final release which uses 
the old groupId. 

To that end, Thomas Broyer has done a lot of work to make sure this path 
will be as smooth as possible. That work can be seen discussed in the 
mailing list 

 
and in a github repo he wrote 
 to demonstrate approaches 
and their relative merits. No final summary was officially posted, but from 
discussions 
in gitter chat 
, the 
cleanest proposed option is to follow Experiment #3 for today, and 
optionally later to roll out the last two options to more easily facilitate 
updates from older releases.

This means that the next release will be performed first on org.gwtproject, 
and then later we will request that someone at Google perform the final 
com.google.gwt release, consisting only of pom files that indicate 
relocation to the new groupId. Applications and dependencies will need to 
switch to this new groupId over time, but in theory at least, using the 
researched relocation mechanism should make that fairly painless.

Finally, I suggest that any release candidate that goes out only exist on 
org.gwtproject, to avoid needing to iterate with com.google releases, in 
case we end up needing more than one RC in the release process.

--

Chrome debugging bugs
There are a few changes in Chrome made over the last year or so that impact 
GWT development and debugging in various ways. 
https://gwt-review.googlesource.com/c/gwt/+/23500 fixes SDM (and cross 
origin apps) stack traces being lost, and unhandledrejection events are 
entirely lost in some cases. 
https://gwt-review.googlesource.com/c/gwt/+/23580 tracks a newer change in 
Chrome dev tools, where the unofficial Function.displayName property no 
longer works when debugging obfuscated code with GWT's 
-XmethodNameDisplayMode flag, and transitions to the standard Function.name 
property instead. 


--

IE8/IE9/IE10 removal
Another thread on this mailing list 
 
tracks the ongoing discussion of removing three end-of-life'd browsers from 
GWT. It has been suggested that IE11 support remain for at least a little 
while longer. According to 
https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
 
IE11 as a desktop application will no longer be supported after June 2022, 
though that may change, and even if it does not, it may make sense to 
continue support for some time after that.

--

Dropping Java 7 support, and upgrading Jetty 9 and HtmlUnit
Building GWT itself with something newer than Java 8 is going to require 
additional work (see https://github.com/gwtproject/gwt/issues/9683), but 
the time has come to no longer support Java 7, and require 8 as the minimum 
version for building and using GWT. I have a work in progress patch 
 which 
upgrades both Jetty 9 and HtmlUnit to their latest respective versions in 
order to deal with several issues affecting each. I am holding out for one 
last fix in HtmlUnit before disabling the two tests it affects (note that 
this is still a net win, about a dozen tests are now passing that weren't 
previously).

--

Other changes already in HEAD-SNAPSHOT can be seen at 
https://github.com/gwtproject/gwt/compare/2.9.0...master.

-- 
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/1cd1088d-474e-459f-9f99-d16ca54710ffn%40googlegroups.com.

Re: [gwt-contrib] Re: Goodbye IE 8–9 👋

[Colin Alworth]

Note that it appears I'm mistaken, Runtime.java polyfilled Date.now() 
(though code in JsDate and others still believed that this method might not 
exist), so GWT 2.8.2 and 2.9.0 likely function properly in IE8.

On Thursday, September 30, 2021 at 11:49:56 AM UTC-5 Colin Alworth wrote:

> I've just filed https://github.com/gwtproject/gwt/issues/9739, where a 
> workaround exists in java.util.Date that nearly doubles the time it takes 
> to parse date strings and build date objects. This workaround exists for 
> IE8 and IE9, as all more recent browsers implement the same behavior as we 
> already would expect. Dropping support for those two browsers would 
> simplify the code required here
>
> From the age of this thread and the discussion so far, it sounds like 
> there is interest in keeping IE11 still, but no one has spoke up about IE10 
> or below. 
>
> Additionally, java.util.Random emulation was changed to require 
> Date.now(), which isn't available in IE8, so neither GWT 2.8.2 nor GWT 
> 2.9.0 are apparently compatible with IE8 anyway, at least in this small 
> way. This should give us some confidence (along with the lack of opposition 
> in this thread) that at least IE8 is definitely safe to drop.
>
> So, is there any objection at this time to dropping what remains of IE8, 
> IE9, and IE10 support from GWT? Then, we can reevaluate IE11 at some later 
> date, for GWT itself? Various migrated GWT modules have focused their 
> efforts on well-supported browsers, and are likely to only support IE11 by 
> accident anyway.
>
> On Friday, March 12, 2021 at 1:20:02 AM UTC-6 stuckagain wrote:
>
>> We still need IE11 support in the banking sector. We still have a 
>> majority of customers that use IE11 due to technical reasons (plugins 
>> needed for accessing secure token don’t install properly in Chrome without 
>> internet access amongst others).
>>
>> What do you mean with “next version of GWT” if that is 3.x then I don’t 
>> care at this point. We have been waiting for that release for a few years 
>> now. But 2.x releases should not drop IE11 support it is supposed to be a 
>> long-term supported version.
>> On 12 Mar 2021, 07:54 +0100, bernhar...@schubec.com <
>> bernhar...@schubec.com>, wrote:
>>
>> Hi all! 
>>
>> I think IE11 support should be dropped soon if it blocks (or makes it 
>> difficult) to implement new features in the next version of GWT.
>> I understand, that there are enterprises who still use IE11 internally, 
>> but developers who service such enterprises should use the current version 
>> of GWT, which is not going away. Nobody is forced to upgrade to the next 
>> version of GWT.
>>
>> Thanks,
>> Berni 
>>
>> tony.be...@gmail.com schrieb am Donnerstag, 11. März 2021 um 22:26:21 
>> UTC+1:
>>
>>> IE 11 is still widely used inside corporations, because it is the only 
>>> browser that supports Java applets, and applications such as Oracle 
>>> e-Business Suite still use applets extensively (for Oracle forms). While 
>>> that segment does not move very fast, it does not mean other unrelated 
>>> groups within the same corporation are not updating GWT regularly. It is 
>>> hard to generalize In a multinational company  with tens of thousands of 
>>> employees. 
>>>
>>> Regards
>>>
>>> Tony
>>>
>>> On Thu, Mar 11, 2021 at 9:49 AM Jens  wrote:
>>>
>>>> Dropping IE 8-10 shouldn't really hurt. Companies that require it are 
>>>> probably not upgrading GWT in a fast pace anyways.
>>>>
>>>> However I wouldn't drop IE 11 anytime soon. IE 11 itself is tied to the 
>>>> lifecycle of Microsoft's operating systems, which means for Windows 10 it 
>>>> is supported until 2025 (for now). So just because MS and Google drop 
>>>> support for IE 11 in some/all of their products, the browser itself is 
>>>> still generally supported by MS. So we should think twice before removing 
>>>> IE 11 from a library such as GWT, even if it means to decline/revert 
>>>> certain commits if they break IE 11. From own experience I have usually 
>>>> seen something around 8% of IE 11 usage in GWT based apps. 
>>>>
>>>> However I am pretty sure more and more companies will announce dropping 
>>>> IE 11 this year or next year. With MS and Google starting, this could 
>>>> easily have a domino effect. However GWT also also strongly used 
>>>> internally 
>>>> inside companies so it might not have that much of an effect 

Re: [gwt-contrib] Re: GWT 2.10 release?

[Colin Alworth]

I'm looking for reviewers and help for the above issues so I can finalize 
them and begin testing. There are a few dependency chains here - I have 
IE8/9/10 removal just about complete, but before that can merge we need the 
apichecker updated, and after that merges, we can remove the poorly 
performing java.util.Date.fixDaylightSavings call. Likewise before 
htmlunit/jetty can be upgraded, Java 7 support must be dropped and the new 
jars put in the tools repo.

Here are reviews currently waiting for someone to take a look:

   - Fix Chrome+SDM stack traces 
   https://gwt-review.googlesource.com/c/gwt/+/23500
   - Fix Chrome -XmethodDisplayName 
   https://gwt-review.googlesource.com/c/gwt/+/23580
   - Provide GWT 2.9.0 apicheck jars 
   https://github.com/gwtproject/tools/pull/22
   - Permit GWT 2.10.0 breaking api changes 
   https://gwt-review.googlesource.com/c/gwt/+/23680 (depends on tools#22)
   - Drop support for Java 7 
   https://gwt-review.googlesource.com/c/gwt/+/23700

After these start to land (to avoid too many at a time), will be the 
following:

   - Drop IE8/9/10 support (depends on review 23680 above)
   - Improve java.util.Date performance in both gwt2 and j2cl (depends on 
   dropping IE8/9)
   - Add latest HtmlUnit/Jetty to gwtproject/tools
   - Update Htmlunit/Jetty to latest (depends on dropping java7 support and 
   htmlunit/jetty being in tools) - this is somewhat incomplete, there are two 
   dev mode tests that are failing, and jetty-env.xml is not presently loaded 
   correctly
   - Add Github Actions support - this depends on the patch which drops 
   Java 7 support due to some issue in running the validation tests in that 
   environment. I'm attempting to replicate build.gwtproject.org except in a 
   way that is visible, and can deploy snapshots to the org.gwtproject groupId 
   when we're ready for that.
   
If you have +2 permissions in the review site, I'd appreciate a look at 
some of these, if you are interested in trying out the patches and giving a 
+1 that would help other reviewers as well.

On Tuesday, October 12, 2021 at 8:01:02 AM UTC-5 juan_pablo_gardella wrote:

> @co...@colinalworth.com  do yo know any ETA on this?
>
> On Tue, Oct 12, 2021, 5:28 AM Rocco De Angelis  
> wrote:
>
>>
>> Nice +1 
>> chani...@gmail.com schrieb am Dienstag, 5. Oktober 2021 um 16:38:08 
>> UTC+2:
>>
>>> Thank a millon, looks great ! +1
>>>
>>> On Friday, October 1, 2021 at 2:55:21 p.m. UTC-4 krypto...@gmail.com 
>>> wrote:
>>>
 awesome +1

 On Fri, Oct 1, 2021 at 2:31 PM mcmi...@gmail.com  
 wrote:

> Sound greats +1
>
>
> nilo...@gmail.com schrieb am Donnerstag, 30. September 2021 um 
> 21:22:13 UTC+2:
>
>> We've got a few changes that have been brewing or waiting to be made 
>> available, and it sounds like it is about time to collectively push to 
>> make 
>> these things happen. Given the nature of some of these, I am suggesting 
>> that they not be folded into a bugfix release, but instead that the next 
>> release be 2.10.0.
>>
>>
>> Changing Maven Central groupId
>> One of the big ones is work to migrate off of the "com.google.gwt" 
>> groupId (note that we are not adjusting packages) and into our own 
>> namespace in maven, "org.gwtproject.gwt". Google's efforts to open 
>> sourcing 
>> and encourage GWT has been very accommodating for the community, and 
>> this 
>> change is long past due, so that releases of GWT do not need someone 
>> with 
>> access to the com.google groupId in Maven Central to perform the release 
>> process for us. If successful, this will be the final release which uses 
>> the old groupId. 
>>
>> To that end, Thomas Broyer has done a lot of work to make sure this 
>> path will be as smooth as possible. That work can be seen discussed 
>> in the mailing list 
>> 
>>  
>> and in a github repo he wrote 
>>  to demonstrate 
>> approaches and their relative merits. No final summary was officially 
>> posted, but from discussions in gitter chat 
>> , the 
>> cleanest proposed option is to follow Experiment #3 for today, and 
>> optionally later to roll out the last two options to more easily 
>> facilitate 
>> updates from older releases.
>>
>> This means that the next release will be performed first on 
>> org.gwtproject, and then later we will request that someone at Google 
>> perform the final com.google.gwt release, consisting only of pom files 
>> that 
>> indicate relocation to the new groupId. Applications and dependencies 
>> will 
>> need to switch to this new groupId over time, but in theory at least, 
>> using 
>> the research

Re: [gwt-contrib] Re: Goodbye IE 8–9 👋

[Colin Alworth]

I've gone ahead and submitted the patches for this work, and have a build 
available (either for maven or just a plain zip download) to test this out, 
along with other features. I only removed explicit references to IE8, 9, 
and 10, as some other code was a bit vague in how it might be used. As IE11 
is still technically supported for a while, and as it behaves as though it 
is a firefox permutation from GWT's perspective, I didn't put any effort at 
this time into removing it.
There are two prerequisite merges that have to happen for this to land:

   - First we need to update the gwt apichecker reference jars 
   https://github.com/gwtproject/tools/pull/22
   - Next, we need to update GWT to use these new reference jars, and 
   account for some api changes since 2.9 that already exist 
   https://gwt-review.googlesource.com/c/gwt/+/23680


Once those are merged, IE 8/9/10 can be removed 
https://gwt-review.googlesource.com/c/gwt/+/23760

As a follow-up, java.util.Date can be substantially more efficient in both 
gwt and j2cl https://gwt-review.googlesource.com/c/gwt/+/23761

See https://github.com/niloc132/gwt/actions/runs/1369212299 for build log 
and artifacts of only these patches. For maven artifacts, use the 
https://repo.vertispan.com/gwt-snapshot/ repository, and specify gwt 
version 2.10.0-htmlunit-upgrade-SNAPSHOT, this build contains other fixes 
as well such as dropping Java7 support, upgrading to latest Jetty 9, and 
upgrading to latest htmlunit.

Community reviewers who have the ability to approve/+2 patches don't seem 
to be available right now, so I request that anyone who tries out these 
patches or builds also look through the code and give a +1 comment or 
review at the links above. I've received private confirmation from several 
individuals and teams that these patches work as expected, but comments to 
that effect on the patches will help to move this forward.

On Tuesday, October 12, 2021 at 3:24:38 AM UTC-5 rdeang...@gmail.com wrote:

>
> +1 for dropping support for all IE versions (8-10)
> Jens schrieb am Mittwoch, 6. Oktober 2021 um 10:22:50 UTC+2:
>
>> I think the gecko permutation has very little to no special treatment of 
>> IE 11 and there are some bugs reported because of that. So there isn't much 
>> to deprecated for IE 11. 
>>
>> Personally I only use safari, gecko permutation and define safari as 
>> fallback permutation. In addition I use some code to check runtime vs 
>> compile time user agent and if they are different display a warning that 
>> some things might not work. That warning basically triggers for any exotic 
>> user-agent and any IE below 11.
>>
>> Dropping all IE permutations (8-10) should be totally fine I guess. 
>> Especially because the new, smaller GWT modules only care about IE 11 (if 
>> at all). gwt-dom for example has only two checks for safari and everything 
>> else is treated the same.
>>
>> -- J.
>>
>> ManfredTremmel schrieb am Montag, 4. Oktober 2021 um 11:07:11 UTC+2:
>>
>>> Am Donnerstag, 30. September 2021, 18:49:56 CEST schrieb Colin Alworth: 
>>>
>>> > So, is there any objection at this time to dropping what remains of 
>>> IE8, 
>>> > IE9, and IE10 support from GWT? Then, we can reevaluate IE11 at some 
>>> later 
>>> > date, for GWT itself? Various migrated GWT modules have focused their 
>>> > efforts on well-supported browsers, and are likely to only support 
>>> IE11 by 
>>> > accident anyway. 
>>>
>>> Let's drop the IE-Permutations. IE11 uses the gecko permutation, so no 
>>> need to 
>>> drop it. In my newer projects, I only use safari permutation for all 
>>> browsers, 
>>> so even dropping all browser specific permutations wouldn't affect me. 
>>>
>>>
>>>

-- 
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/98f32124-392c-47a4-8424-54e2a1c99934n%40googlegroups.com.

[gwt-contrib] gwtproject.org migration, https support

[Colin Alworth]

We've successfully migrated the gwtproject.org website to a new domain name 
server and new hosting, at Google's request. There are a few small 
differences from the old hosting:


   - HTTPS is now supported and enabled, though not yet mandatory, to allow 
   a period of migration, and making sure that no downstream tools will break 
   as a result of these changes. HSTS is also disabled for now. I propose that 
   mid-week I will update this to always redirect to HTTPS, and then in 
   another two or three weeks consider enabling HSTS if there have been no 
   reported issues.
   - The samples.gwtproject.org domain now redirects to the showcase, 
   rather than giving a confusing 500 error. The samples are still at this 
   time hosted as static content rather than servlets.
   - The GWT application that enhances the documentation has been updated, 
   picking up changes published ~2 years ago.
   - Deep links that omit "www." (for example 
   gwtproject.org/doc/latest/DevGuide.html) will now redirect to the expected 
   page (in this case www.gwtproject.org/doc/latest/DevGuide.html) rather than 
   redirecting only to www.gwtproject.org.


Building and deployment of the new site is currently described at 
https://github.com/Vertispan/gwtproject.org, and should be hostable with or 
without DNS entries or HTTPS (though handling your own dns for 
"gwtproject.org" itself may eventually conflict with HSTS). The README 
contains some basic details on how the hosting is structured and how to run 
on any arbitrary server. There is also a TODO list at 
https://github.com/Vertispan/gwtproject.org/blob/main/TODO.md, which could 
eventually be migrated to actual github issues.

This could have been implemented through a similar build process that then 
pushed to github-pages, but at least for now we decided against this. Once 
some kind of continuous integration is in place to create pre-built 
artifacts for gwt-site-webapp and gwt-site itself, it might make sense to 
reconsider this, but for samples it still may make sense to use custom 
hosting to phase out the current static-only samples and provide some 
samples which can interact in some way with the server.

If there are no objections to the current layout, configuration, 
deployment, and documentation, I propose migrating this project to 
github.com/gwtproject, as well as following up on the bullet points of the 
TODO list.

-- 
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/94a1c877-78ac-40ea-9084-405514b8b3d4n%40googlegroups.com.

[gwt-contrib] License for gwt-site content

[Colin Alworth]

See the question raised at 
https://github.com/gwtproject/gwt-site/issues/328.

While gwtproject explicitly licenses all "software and sample code" as 
under the Apache License 2.0, it appears that we don't have a license 
specified for the contents of the gwtproject website 
(https://gwtproject.org, https://github.com/gwtproject/gwt-site/). A case 
could be made that the content is already licensed as under the same 
license. It was my understanding that this is discouraged (though at the 
moment I'm having a hard time seeing why that would be). I can find 
concrete examples of the Apache Foundation licensing their documentation 
under the Apache License
 * https://github.com/apache/couchdb-documentation
 * https://github.com/apache/cordova-docs

On the other hand, if the Apache license that applies to all code and 
samples does not apply to the contents, then each author owns their own 
content directly.

I am not a lawyer, but my understanding is that (at least in the country in 
which I reside) content is copyrighted by default, and the author owns that 
copyright. Additional rights must be granted by the author. If we want to 
change the license, we need the approval of the authors so far - 
https://github.com/gwtproject/gwt-site/graphs/contributors. Anyone who 
doesn't approve would need to have their content removed, if we decide to 
change.

Are we sufficiently clear that all content is Apache licensed, including 
the website documentation? Is there a good reason to consider a different 
license instead? Should we seek confirmation from any authors of 
substantial amounts of content that their content falls under the license 
we choose?

My suggestion is to clarify that all content is under the Apache License, 
and see a confirmation from any author who wrote more than ~5 lines of 
content. If we think we are already clear that all content is under that 
license, then we should state that in an up front way, such as setting the 
"license" metadata of the gwt-site repo, and adding a LICENSE file.

Thoughts, suggestions, pointers to how other projects have handled this?

-- 
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/45f473b5-4d2d-4016-b76d-29210128de27n%40googlegroups.com.

[gwt-contrib] Preliminary testing for GWT 2.10 release

[Colin Alworth]

TL;DR: If you have the capability to do so, now would be an excellent time 
to help us test GWT in anticipation of a release, especially around the 
groupId change we're going to make.

--

We think that we're one merge away from being ready for a GWT 2.10 release, 
so I'm starting the release process a bit early, since this last commit 
involves changing GWT's groupId away from com.google and to org.gwtproject.

To that end, I have a maven repo with the maven changes along wit all of 
the other changes in the GWT 2.10 series. The repo's URL is 
https://repo.vertispan.com/gwt-groupid-migration-test/, and the only GWT 
version that exists there is "2.10.0-new-groupid-2".

Based on earlier work (such as in the 
https://groups.google.com/g/google-web-toolkit-contributors/c/L2RMqglOEXo/m/44BeZKeBCQAJ
 
thread), this should allow projects to transition from com.google.gwt to 
org.gwtproject by adding the org.gwtproject:gwt:pom to their project, and 
then specify gwt-user etc, and automatically manage the version of gwt used 
by dependencies. It should also be possible to just use the old groupid for 
this release, but later releases will not have that option.

Please note that *packages are not changing *as part of this transition, 
only groupIds.

Rough release notes:
 * Updated htmlunit and jetty to more recent versions
 * Dropped support for IE8/9/10
 * Dropped support for Java 7
 * Support long classpaths by using CLASSPATH env vars to run child 
permutation workers
 * Many enhancements to emulation APIs and generated code

Please reply to this thread or email me directly with any 
results/surprises/questions.

-- 
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/dad1685b-9ad0-4a1a-88f4-dd0332d7b91dn%40googlegroups.com.

[gwt-contrib] Re: License for gwt-site content

[Colin Alworth]

Ah thank you, I'm very happy to be wrong. I checked a several commits but 
didn't think to look at PRs. 

Changes made to gwt-site do not go through gerrit, but through github since 
late 2014, though the CLA bot does still track it. 

I had already gone through the list of committers who made changes to 
markdown that were more than 5 lines in total and narrowed that list to 
only ones who didn't have a CLA on gwt-review.googlesource.com, but it 
turns out that list of ~38 people must have signed the CLA in some other 
way. I'll recheck the PRs those committers were involved in to confirm, but 
it sounds like we just need to clarify the license directly, since the CLA 
gives us (well, Google technically) the right to do that.

As Google is winding down their direct involvement in the project, the CLA 
bot will be turned off soon, and we'll want to be sure we have an 
explicitly license in all projects that covers contributions, but so far 
this was the only project deficient in this way - and the only project not 
covered by gerrit.

Thanks again for finding my mistake.

On Friday, April 22, 2022 at 3:40:42 AM UTC-5 Jens wrote:

> Haven't all changes been made through gerrit and did require a CLA? 
>
> --J.
>
> Colin Alworth schrieb am Donnerstag, 21. April 2022 um 17:34:49 UTC+2:
>
>> See the question raised at 
>> https://github.com/gwtproject/gwt-site/issues/328.
>>
>> While gwtproject explicitly licenses all "software and sample code" as 
>> under the Apache License 2.0, it appears that we don't have a license 
>> specified for the contents of the gwtproject website (
>> https://gwtproject.org, https://github.com/gwtproject/gwt-site/). A case 
>> could be made that the content is already licensed as under the same 
>> license. It was my understanding that this is discouraged (though at the 
>> moment I'm having a hard time seeing why that would be). I can find 
>> concrete examples of the Apache Foundation licensing their documentation 
>> under the Apache License
>>  * https://github.com/apache/couchdb-documentation
>>  * https://github.com/apache/cordova-docs
>>
>> On the other hand, if the Apache license that applies to all code and 
>> samples does not apply to the contents, then each author owns their own 
>> content directly.
>>
>> I am not a lawyer, but my understanding is that (at least in the country 
>> in which I reside) content is copyrighted by default, and the author owns 
>> that copyright. Additional rights must be granted by the author. If we want 
>> to change the license, we need the approval of the authors so far - 
>> https://github.com/gwtproject/gwt-site/graphs/contributors. Anyone who 
>> doesn't approve would need to have their content removed, if we decide to 
>> change.
>>
>> Are we sufficiently clear that all content is Apache licensed, including 
>> the website documentation? Is there a good reason to consider a different 
>> license instead? Should we seek confirmation from any authors of 
>> substantial amounts of content that their content falls under the license 
>> we choose?
>>
>> My suggestion is to clarify that all content is under the Apache License, 
>> and see a confirmation from any author who wrote more than ~5 lines of 
>> content. If we think we are already clear that all content is under that 
>> license, then we should state that in an up front way, such as setting the 
>> "license" metadata of the gwt-site repo, and adding a LICENSE file.
>>
>> Thoughts, suggestions, pointers to how other projects have handled this?
>>
>

-- 
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/5a00b0b9-fb6b-48c1-a6c9-156908ba3dean%40googlegroups.com.

Re: [gwt-contrib] Preliminary testing for GWT 2.10 release

[Colin Alworth]

leDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 918: The method createMuted(DocumentEventRouter super E,E,?>) in the type WaveletBasedSupplement is not applicable for the 
> arguments (DocumentEventRouter)
>  [ERROR] Line 933: The method 
> createPendingNotification(DocumentEventRouter) in the type 
> WaveletBasedSupplement is not applicable for the arguments 
> (DocumentEventRouter)
>  [ERROR] Line 938: The method 
> createWaveletReadState(DocumentEventRouter, 
> ObservablePrimitiveSupplement.Listener) in the type WaveletBasedSupplement 
> is not applicable for the arguments (DocumentEventRouter ?,capture#84-of ? extends N>, ObservablePrimitiveSupplement.Listener)
>  [ERROR] Line 958: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 923: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 913: The method createFolders(DocumentEventRouter super E,E,?>) in the type WaveletBasedSupplement is not applicable for the 
> arguments (DocumentEventRouter)
>  [ERROR] Line 913: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 938: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 933: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 943: The method 
> createWaveletCollapsedState(DocumentEventRouter, 
> ObservablePrimitiveSupplement.Listener) in the type WaveletBasedSupplement 
> is not applicable for the arguments (DocumentEventRouter ?,capture#87-of ? extends N>, ObservablePrimitiveSupplement.Listener)
>  [ERROR] Line 948: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 923: The method createCleared(DocumentEventRouter super E,E,?>) in the type WaveletBasedSupplement is not applicable for the 
> arguments (DocumentEventRouter)
>  [ERROR] Line 958: The method 
> createAbuseStore(DocumentEventRouter) in the type 
> WaveletBasedSupplement is not applicable for the arguments 
> (DocumentEventRouter)
>  [ERROR] Line 953: The method 
> createWaveletNotifiedVersion(DocumentEventRouter) in the 
> type WaveletBasedSupplement is not applicable for the arguments 
> (DocumentEventRouter)
>  [ERROR] Line 918: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 963: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 928: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 963: The method 
> createGadgetStatesDoc(DocumentEventRouter, 
> ObservablePrimitiveSupplement.Listener) in the type WaveletBasedSupplement 
> is not applicable for the arguments (DocumentEventRouter ?,capture#99-of ? extends N>, ObservablePrimitiveSupplement.Listener)
>  [ERROR] Line 928: The method 
> createWaveletArchiveState(DocumentEventRouter) in the type 
> WaveletBasedSupplement is not applicable for the arguments 
> (DocumentEventRouter)
>
>
> On Fri, Apr 22, 2022 at 1:56 AM Colin Alworth  wrote:
>
>> TL;DR: If you have the capability to do so, now would be an excellent 
>> time to help us test GWT in anticipation of a release, especially around 
>> the groupId change we're going to make.
>>
>> --
>>
>> We think that we're one merge away from being ready for a GWT 2.10 
>> release, so I'm starting the release process a bit early, since this last 
>> commit involves changing GWT's groupId away from com.google and to 
>> org.gwtproject.
>>
>> To that end, I have a maven repo with the maven changes along wit all of 
>> the other changes in the GWT 2.10 series. The repo's URL is 
>> https://r

Re: [gwt-contrib] Preliminary testing for GWT 2.10 release

[Colin Alworth]

I've pushed a new build with version 2.10.0-new-groupid-3 that has several 
@SuppressWarnings("deprecation")s added, and hopefully will solve the WARN 
logging issue.

-- 
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/28cff012-2206-48a8-8882-11b0ea945046n%40googlegroups.com.

Re: [gwt-contrib] Preliminary testing for GWT 2.10 release

[Colin Alworth]

https://gwt-review.googlesource.com/c/gwt/+/23861 is now the only merge 
remaining to cut the release. I just made a few more changes to it, having 
noticed that some maven samples weren't using the new groupId, and in doing 
so I noticed what appeared to be another problem with the new 
org.gwtproject:gwt pom. This is now deployed as version 
2.10.0-new-groupid-4, and should behave just as before, except only 
referencing org.gwtproject groupIds will behave better.


While this needs to be borne out in testing, if everything goes well, 
here's my proposed release process for this unusual release:


   - Get a final +2 for 23861, don't merge it yet.
   - Request that Google disable nightly SNAPSHOT builds, so that we don't 
   produce a build with 23861's changes (see the review for why this is 
   necessary)
   - Merge 23861, cut a release branch, and create a candidate 
   org.gwtproject release for 2.10.0. Note that I'm proposing to _not_ make a 
   RC1 this time, but to move right to the actual GA release. This is for 
   several reasons, mostly to avoid requesting more than one release from 
   Google. The zip download will be made available to testers, and the maven 
   build will be in a (closed) sonatype staging repo to verify it. (A "test" 
   repo will also be created with the com.google.gwt artifacts, so that 
   org.gwtproject:gwt:2.10.0 has its dependencies provided.)
   - Test volunteers will go through the "GWT Smoke Test Checklist", to 
   ensure across our supported platforms we don't have any last moment 
   surprises. This typically takes several days. Note that I’ve reduced the 
   browser/OS permutations, since recent browsers aren’t quite as tied to 
   their OS version as they were in the past.
   - Request that Google perform the com.google.gwt side of the release - 
   only poms will be released.
   - As soon as com.google.gwt is ready to be released, release 
   org.gwtproject 2.10.0 to maven central, and upload the new release zip as a 
   github release. There must be as little gap between these as possible, as 
   each depends on the other, neither release is usable until both are sync'd 
   to central.
   - Finish the release process (tag the release, update release notes, 
   update javadoc).
   - Finish the migration to github (disable the mirror, rename master to 
   main, enable github actions, enable pull requests, enable nightly builds).
   - Request that Google delete the com.google.gwt artifacts from 
   google-snapshots, since they can no longer be updated.

These steps (and a few other links) are in 
https://docs.google.com/document/d/10Cn0Z7SDv0ZW5OVZdoIdw5EAEDUbtK6vracOOnxj7po/edit
 
if you'd like to specifically add comments or suggest changes.

On Tuesday, April 26, 2022 at 6:50:12 AM UTC-5 juan_pablo_gardella wrote:

> After removing an old plexus-utils as suggested at #152 
> <https://github.com/tbroyer/gwt-maven-plugin/issues/152>, I was able to 
> compile and run the application without issues so far. Great work!
>
> On Mon, Apr 25, 2022 at 2:25 PM Freddy Boucher  
> wrote:
>
>> 2.10.0-new-groupid-3 works like a charm (in addition of 
>> net.ltgt.gwt.maven/gwt-maven-plugin 1.0.1)
>> Thanks
>>
>> Le dimanche 24 avril 2022 à 21:34:23 UTC+2, juan_pablo_gardella a écrit :
>>
>>> Tried with Maven 3.8.5 and still fails with same issue. Reported at 
>>> https://github.com/tbroyer/gwt-maven-plugin/issues/152
>>>
>>> On Sun, Apr 24, 2022 at 3:59 PM Colin Alworth  wrote:
>>>
>>>> I've pushed a new build with version 2.10.0-new-groupid-3 that has 
>>>> several @SuppressWarnings("deprecation")s added, and hopefully will solve 
>>>> the WARN logging issue.
>>>>
>>>> -- 
>>>>
>>> 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/28cff012-2206-48a8-8882-11b0ea945046n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/28cff012-2206-48a8-8882-11b0ea945046n%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-co...@googlegroups.com.
>>
&

[gwt-contrib] Testing for GWT 2.10.0 release

[Colin Alworth]

Hello all,

All of the preliminary testing that I'm aware of for the upcoming release 
is complete, leaving us with a decent level of confidence in the changes. 
We have a document that outlines the release plan (with a link to the 
standard release steps and the testing process) that has undergone a few 
small tweaks, and I think is ready to go:
https://docs.google.com/document/d/10Cn0Z7SDv0ZW5OVZdoIdw5EAEDUbtK6vracOOnxj7po/edit

I'm now asking for volunteers who are able to test the final release once 
it is ready to go. We're hoping for a cross section of testing that verifies

   - JVM Version: 8, 11, 17/18
   - OS: Linux, OS X, Windows 8.1, 10, 11
   - Browser: Chrome, Firefox, Safari, IE11, Edge (blink)

Windows 8.1 and 10 VMs are available at 
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/, I'm not 
presently aware of a source for Windows 11 VMs, so ideally we have a few 
people running that natively.

Please reply to this or contact me off-list (co...@colinalworth.com) with 
the combinations you have access to and are able to test, and we'll 
organize in the next few days, and start the next steps.

Thanks!

-- 
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/f28c40dc-796f-426c-92d4-2d14c9178b37n%40googlegroups.com.

[gwt-contrib] Re: Testing for GWT 2.10.0 release

[Colin Alworth]

The last step of the release process is under way, Google's 2.10.0 release 
is underway, we're just waiting for the release to be performed and 
synchronized to Maven Central. When that has finished we can formally 
announce the release.

I've created an issue for next steps to finish our transition to GitHub at 
https://github.com/gwtproject/gwt/issues/9756 and will follow up with a few 
proposed pull requests to make these changes.

Thanks for everyone's support and patience with this process!

On Sunday, May 22, 2022 at 11:00:14 AM UTC-5 mcmi...@gmail.com wrote:

> Hi,
> I could test on Windows 10 (and maybe Windows 11)
> Browser :
> - Firefox
> - Edge (but Chromium only)
> - IE 11 (End of Support on June 15th)
> - Chrome
>
> JVM:
> - 11
> - 17
> - 18
> - 19 eap
> Boris Brudnoy schrieb am Freitag, 20. Mai 2022 um 14:33:02 UTC+2:
>
>> I'll test. I'm on macOS Monterey 12.3.1. Can do whichever JVMs / browsers 
>> run on macOS, which AFAICT is everything but IE11.
>>
>> On Thursday, May 19, 2022 at 11:34:31 PM UTC-4 nilo...@gmail.com wrote:
>>
>>> Hello all,
>>>
>>> All of the preliminary testing that I'm aware of for the upcoming 
>>> release is complete, leaving us with a decent level of confidence in the 
>>> changes. We have a document that outlines the release plan (with a link to 
>>> the standard release steps and the testing process) that has undergone a 
>>> few small tweaks, and I think is ready to go:
>>>
>>> https://docs.google.com/document/d/10Cn0Z7SDv0ZW5OVZdoIdw5EAEDUbtK6vracOOnxj7po/edit
>>>
>>> I'm now asking for volunteers who are able to test the final release 
>>> once it is ready to go. We're hoping for a cross section of testing that 
>>> verifies
>>>
>>>- JVM Version: 8, 11, 17/18
>>>- OS: Linux, OS X, Windows 8.1, 10, 11
>>>- Browser: Chrome, Firefox, Safari, IE11, Edge (blink)
>>>
>>> Windows 8.1 and 10 VMs are available at 
>>> https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/, I'm 
>>> not presently aware of a source for Windows 11 VMs, so ideally we have a 
>>> few people running that natively.
>>>
>>> Please reply to this or contact me off-list (co...@colinalworth.com) 
>>> with the combinations you have access to and are able to test, and we'll 
>>> organize in the next few days, and start the next steps.
>>>
>>> Thanks!
>>>
>>

-- 
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/5df0ff8b-6d48-4c44-a814-3e27cb98427dn%40googlegroups.com.

[gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[Colin Alworth]

If there’s one thing that GWT has tried to be consistent about, it is 
retaining support for technologies past their “best by” dates. This is a 
sore point from time to time, as it makes the tooling feel dated even right 
after a release, but it has some specific advantages with regards to 
enabling projects that are otherwise in maintenance mode to still be able 
to upgrade to a newer version. Similarly, GWT has traditionally only 
supported the current release, with no fixes backported, due to the extra 
work that would need to be done in testing, backporting, etc.


To get stuck on a tangent before even reaching the point of this post, this 
is part of the reason that each of the GWT modules which previously lived 
in gwt-user.jar is getting its own git repo, and being released as its own 
pace, separate from the GWT compiler and its neighbors (and also separate 
from J2CL, with tests to ensure it can work with both toolkits). Migrating 
to a specific version of one of those modules might require some code 
changes be made to a project, but is intended to uncouple changes to that 
project from changes made to either J2CL or GWT2 toolchains. 

GWT 2.10 has been released, with a few important changes that border on 
breaking - the groupId has changed from com.google.gwt to org.gwtproject, 
Jetty was updated after languishing for years, and IE 8, 9, and 10 support 
has been dropped. The Jetty change has caused a few minute hiccups, one of 
which will probably result in a GWT 2.10.1 release, but otherwise things 
seem to have gone well.

Looking forward, we have some other decisions to make around deprecating or 
dropping support for certain features or compatibility. The chief issue is 
dropping support for Java 8. Jetty 9 is EOL (though still receiving 
occasional security updates for now), and Jetty 10 requires Java 11 at a 
minimum. Recent versions of the Eclipse JDT will also require Java 11, so 
we can’t add support for Java 17 language features without dropping support 
for running on Java 8. While it is possible that we might be able to 
continue to compile gwt-servlet and other production server-side code for 
Java 8, that is going to need dedicated testing to ensure it behaves as we 
expect, so I wouldn’t want to have it be one of our first choices.

We would be in good company with dropping Java 8 in our next release - the 
Spring Framework has gone so far as to drop Java 11 support as well, 
requiring Java 17 as the minimum supported Java version as of version 6 
. 

Other deprecations/updates/removals to consider - I haven’t spent a great 
deal of time investigating any of these, but wanted to at least open the 
door to some of these.


   - Legacy Dev Mode - the use cases are diminishing but not totally gone 
   yet. IE11 technically supports it, and HtmlUnit can use it as well. Some 
   testing tools like gwt-mockito and Emma require it as well. With that said, 
   if removed, there is considerable old code that can go with it, not just in 
   the compiler and dev mode, but simplification that can happen in emulation 
   as well.
   - Selenium - Selenium support is ancient, and I’m not aware of a way to 
   make it work with recent browsers. Moving to modern WebDriver would make 
   sense, though this is a bit of a moving target in my experience, but 
   downstream projects should be able to update without affecting GWT. It 
   might even make sense to leave this as an optional dependency, and rely on 
   the downstream project adding its own implementation.
   - javax.servlet -> jakarta.servlet - This could potentially be done in a 
   way to support both APIs in a single release, though that may also require 
   supporting two sets of dev mode implementations, for users that run their 
   own servlets in the dev mode server.


Inevitably, removing these before they are formally end-of-life’d is bound 
to inconvenience at least a few downstream developers, so this isn’t to be 
taken lightly, nor done without some plan to continue to support critical 
fixes. Some quick options, based on how much pushback we get on each:

   - Keep all compatibility until the dependency in question is formally 
   end-of-life’d. We’ll be waiting until something like 2026 to pick up the 
   Java 17 support through JDT, though other options might be possible along 
   the way.
   - Be very aggressive in dropping support, such as Spring’s model, where 
   the next release will only support Java 17+. This will undoubtedly cut off 
   support for many projects far before they are ready to update.
   - Let the main branch work towards updating some of these dependencies 
   for a 2.11 release, and backport any fixes that don’t directly relate to 
   upgrades to the release/2.10 branch. This would represent a shift in 
   existing policy around releases, and might require more support from 
   community members for testing and such. There is also the 

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[Colin Alworth]

Thanks to everyone for their insights. By my count, 25% of the replies have 
at least some use for Java 8 yet, so as the example that all responders 
latched on to, it seems unlikely that the time has come to drop support for 
it, at least in production deployments (a useful distinction that Jens 
drew).

With that said, I'd like to more specifically focus on the release side - 
as conflicts arise, do we "split" releases and support both "old" and 
"new", or do we find a single consistent path of least resistance? A single 
path could require a bit more work to implement up front (such as build 
wiring to ensure Java8 support in server jars, but runtime support for 
11+), while a split path would probably keep better coverage over use cases 
at the cost of additional release testing (backporting a fix requires a 
release for both leading and trailing versions). 

Historically we have held off updating dependencies until there was no 
choice, to ensure that nearly every GWT project could update promptly - so 
that any performance improvements or security fixes could be quickly put to 
use. Looking at Java 8 specifically, we have several years before Java 8 
will be EOLd. At a quick glance, I'm not seeing an obvious EOL for the 
implementations of javax.servlet packages (Jetty 10, specifically), so I'm 
not sure we can afford to do more than implement both sets of interfaces 
and hope for the best, unless we again split as "leading"/"trailing" 
builds... but to reiterate, there are other cases here where we could 
remove or improve code based on dependencies that someone might still have 
a need for.

Worst case, I'm wrong, and we should focus first and foremost on exactly 
what deprecations should be handled, but with 25% of respondents so far 
with need of a version of Java that Adoptium intends to support until at 
least 2026 <https://adoptium.net/support/>, I think there might be merits 
to considering how that support could look for GWT. The question I'm trying 
to pose is how will we manage that - lighter testing on the old builds, 
focusing on only old dependencies and encouraging adoption of the newer 
release?

Are developers on this list (deliberately sent to the contributors list, 
not the general user mailing list) who don't update right away to new APIs 
(new JDK, javax vs jakarta, etc) interested in supporting work to keep a 
"LTS" release active (i.e. mostly validating backported fixes and smoke 
testing releases)? If so, is 2.10 that LTS, or do we want a short round of 
2.11 for any more changes before beginning to "break" things in 2.12?

And if not, will it be acceptable to stay on stale versions of GWT, and 
while some effort will be put into keeping backwards compatibility, it will 
not outweigh needs like supporting modern servlet packages, drop "dev mode" 
htmlunit, etc? 
On Sunday, August 7, 2022 at 1:16:56 PM UTC-5 stuckagain wrote:

> In my case we have different codebases that overlap with reusable 
> components. Not all projects are willing to invest in a newer jdk since 
> they are basically in maintenance mode.
>
> If GWT would drop Java 8 it would be a problem. On the other hand, maybe 
> it will finally force people to move on faster. They tend to complain that 
> we are using old technology (GWT) but at the same time they stick with Java 
> 8.
> On 4 Aug 2022, 06:05 +0300, Colin Alworth , wrote:
>
>
>
> If there’s one thing that GWT has tried to be consistent about, it is 
> retaining support for technologies past their “best by” dates. This is a 
> sore point from time to time, as it makes the tooling feel dated even right 
> after a release, but it has some specific advantages with regards to 
> enabling projects that are otherwise in maintenance mode to still be able 
> to upgrade to a newer version. Similarly, GWT has traditionally only 
> supported the current release, with no fixes backported, due to the extra 
> work that would need to be done in testing, backporting, etc.
>
>
> To get stuck on a tangent before even reaching the point of this post, 
> this is part of the reason that each of the GWT modules which previously 
> lived in gwt-user.jar is getting its own git repo, and being released as 
> its own pace, separate from the GWT compiler and its neighbors (and also 
> separate from J2CL, with tests to ensure it can work with both toolkits). 
> Migrating to a specific version of one of those modules might require some 
> code changes be made to a project, but is intended to uncouple changes to 
> that project from changes made to either J2CL or GWT2 toolchains.
>
> GWT 2.10 has been released, with a few important changes that border on 
> breaking - the groupId has changed from com.google.gwt to org.gwtproject, 
> Jetty was updated after languis

[gwt-contrib] Re: GWT 2 Roadmap as it applies to future deprecations

[Colin Alworth]

I'd welcome a separate discussion about a backward compatibility contract, 
but clearly we have to contrast the "technically Java 8 is supported" with 
"realistically, any project that uses standard up-to-date tools can't use 
Java 8 by the end of 2023". We support _end users_ to the extreme, as so 
many huge enterprise apps built with GWT end up in situations with ancient 
PCs running out-of-date browsers, but we may need to consider Java or 
jakarta versioning to be different, as those face the developers and 
deployments.

If we assume that support Java 8 is required, we have roughly two options:
 * Support it only on the server, but not dev mode. GWT can migrate to Java 
11/17/etc but be sure that gwt-servlet.jar and the like are only built with 
with Java 8 bytecode. This add a small amount of complexity to the build, 
and limits use of new features, but unblocks the compiler and dev mode from 
supporting newer versions of Jetty, JDT, etc. Jetty 9 is EOL, and 10 and 11 
require Java 11. In turn, this is going to cut us off from HtmlUnit updates 
before much longer. Any recent JDT also requires Java 11, so we're cut off 
from records, multi-line strings, pattern matching, etc. Closure-compiler 
has also dropped Java 8 support, as another example (from Google, which 
famously requires Java 7 support for so long).
 * Support two long term releases, whereas we only support "the latest 
release" today, and don't backport fixes. This imposes very little burden 
today, as most commits will go in both branches, but costs will go up as 
time goes on, especially if we expect to make it until _at least_ 2030 with 
a long running 2.11 branch or whatever. It wouldn't quite double our 
current review/testing/release overhead, but I suspect it will be close to 
that in five years.

Either way we're starving for code reviewers and testers today - reported 
bugs may get fixes, but those fixes are not being tested and critical 
reviews are not being done. So I put this to teams that will require Java 8 
in 2023 and beyond: additional support of some kind or another is required 
to maintain your use case. Do you need to deploy to Java 8 environments, or 
do you need to do all development in Java 8 as well? Are you able to 
coordinate with us to help make your use case a reality?



On Monday, January 2, 2023 at 12:49:36 PM UTC-6 eliasbala...@gmail.com 
wrote:

> My 2 cents:
>
> We also have quite a few projects here based on GWT, still running DevMode 
> on Java 1.8 I am afraid.
> Like everyone else sharing the same fate, we are struggling to upgrade to 
> Java 11 which seems to be the next sensible move.
> Yet, the world is being indirectly and inevitably forced to embrace the 
> transformation challenge, as relevant tools and integrations have already 
> switched to Java 11 (e.g. Jenkins).
>
> In our experience, when using DevMode, it is best to run simpler variants 
> of the actual UI apps, or keep them as simple as possible so that they can 
> still run on Jetty even with an altered classpath.
>
> On Monday, 2 January 2023 at 13:10:59 UTC hthdjeu...@googlemail.com wrote:
>
>> We have a project here that uses GWT for all its web UI and is still 
>> running Java 1.8. The SAP JVM 8 will be supported at least until 2030. 
>> According to 
>> https://newrelic.com/resources/report/2022-state-of-java-ecosystem in 
>> April 2022 still close to half of the projects (46%) were using Java 1.8. 
>> We have made some efforts to move to 11 and 17 and succeeded to the degree 
>> that we have the build pipelines running for those two new LTS versions 
>> using their respective JDKs to compile, have our Docker images ready and 
>> can run the solution with both these new Java LTS releases. But this took a 
>> few months, and I find it very likely that from the 46% of the projects not 
>> all have the resources to invest into the migration. If only half of them 
>> do, we're still at those ~25% that Colin already sampled from the responses 
>> on this thread who will continue to use 1.8 for some time to come.
>>
>> Still, we're not yet decided on making the move. Even when using the 
>> sapmachine.io flavors of the new JDKs we will lose some beloved features 
>> we get from SAP JVM 8, among them a really neat profiler that integrates 
>> nicely with Eclipse, as well as reversible on-the-fly debugging. The only 
>> immediate incentive for a migration to 17 could be the performance 
>> improvements we measure (depending on the type of workload an average 
>> improvement by 10-20%), whereas language features or the new GCs (which 
>> frankly were a bit disappointing for our parallelizing workloads) are not 
>> in such high demand in our case.
>>
>> Ironically, since we live off a fork of the GWT project to already 
>> incorporate two PRs we've made into our production, Java 1.8 is still 
>> required to run the GWT build...
>>
>> The compatibility issues raised here are of course all very valid. Some 
>> things seem reasonably easy to de

[gwt-contrib] New home for GWT Eclipse Plugin

[Colin Alworth]

The GWT Eclipse Plugin has become unmaintained, and over the last several 
months several community members have stepped up to update it to run on 
recent Eclipse versions, and support the new GWT groupId.

As part of that process, we've created a new marketplace entry, and while 
it is still pointed at the old 3.0 release, we're preparing a new release, 
and hope to have it out within a week.

https://marketplace.eclipse.org/content/gwt-plugin/

In order to deploy a new version, we need to deploy the unpacked repository 
somewhere - which rules out a maven repository. The footprint of the 
unpacked workspace is fairly large, around 350mb, which would be too big 
for github pages after three releases. We could still deploy releases zips, 
but need somewhere else to put the unpacked content.

There is probably another clever solution, but the straightforward solution 
seems to be to add a subdomain on gwtproject.org and unpack the content 
there - I propose eclipse.gwtproject.org. As we did for www.gwtproject.org 
and samples.gwtproject.org, I've put an example of this at 
eclipse.gwtproject.org.vertispan.com, and deployed a single snapshot of the 
4.0 plugin (note that as with many eclipse plugin repos, this doesn't load 
correctly in a browser):
https://eclipse.gwtproject.org.vertispan.com/2023-01-18/

If there are no objections, once we've finished the 4.0 plugin and are 
ready for a release, I'll formally set up *eclipse.gwtproject.org*. For the 
moment I anticipate only a plugins/ directory, with each versioned release 
(and maybe a nightly build setup too), to allow for additional content 
later.

Using the gwtproject.org domain name seems natural as a large number of GWT 
developers use Eclipse and this plugin, and the documentation at 
gwtproject.org has long since offered Eclipse instructions, with little 
space given to IntelliJ or Maven/Gradle. I'd further propose we should 
improve that situation, but that's a separate discussion. Vertispan intends 
to host this new plugin content, and we are already hosting the 
gwtproject.org domain content.

If there are reservations about gwtproject.org also hosting the eclipse 
plugin, we can set up an alternate domain name for this work, though at 
least for the time being, Vertspan will be hosting these together.

-- 
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/66c5f0b1-5c33-4f43-8cb5-df97d8ca11adn%40googlegroups.com.

[gwt-contrib] Re: New home for GWT Eclipse Plugin

[Colin Alworth]

The marketplace entry is updated, and is using the 4.0.0 release at 
plugins.gwtproject.org. There is a subdirectory that lists all deployed 
versions, including a nightly build - each of these directories can be 
added directly to eclipse as an update site: 
https://plugins.gwtproject.org/eclipse/gwt-eclipse-plugin/.

This deployment is managed presently by 
https://github.com/Vertispan/gwtproject.org. 

On Friday, February 3, 2023 at 1:39:10 PM UTC-6 Jens wrote:

> Seems fine to use the gwtproject.org domain for it. I slightly tend 
> towards plugins.gwtproject.org/eclipse because it is slightly more 
> descriptive and then we could also provide 
> plugins.gwtproject.org/browser-extensions to publish the last working 
> classic dev mode browser extensions for people having such an old setup. 
> Currently they are all hosted on google.com domain (see: 
> https://www.gwtproject.org/missing-plugin/) and might disappear at any 
> time.
>
> As there was some trouble getting access to the marketplace maybe in the 
> long run some mechanisms should be put into place to avoid that situation 
> in the future. For example some online password manager with password 
> sharing between trustworthy community members. I appreciate the commitment 
> of Vertispan but there should be a backup plan in case something unexpected 
> happens.
>
> -- J.
>
> Colin Alworth schrieb am Samstag, 28. Januar 2023 um 03:45:13 UTC+1:
>
>> The GWT Eclipse Plugin has become unmaintained, and over the last several 
>> months several community members have stepped up to update it to run on 
>> recent Eclipse versions, and support the new GWT groupId.
>>
>> As part of that process, we've created a new marketplace entry, and while 
>> it is still pointed at the old 3.0 release, we're preparing a new release, 
>> and hope to have it out within a week.
>>
>> https://marketplace.eclipse.org/content/gwt-plugin/
>>
>> In order to deploy a new version, we need to deploy the unpacked 
>> repository somewhere - which rules out a maven repository. The footprint of 
>> the unpacked workspace is fairly large, around 350mb, which would be too 
>> big for github pages after three releases. We could still deploy releases 
>> zips, but need somewhere else to put the unpacked content.
>>
>> There is probably another clever solution, but the straightforward 
>> solution seems to be to add a subdomain on gwtproject.org and unpack the 
>> content there - I propose eclipse.gwtproject.org. As we did for 
>> www.gwtproject.org and samples.gwtproject.org, I've put an example of 
>> this at eclipse.gwtproject.org.vertispan.com, and deployed a single 
>> snapshot of the 4.0 plugin (note that as with many eclipse plugin repos, 
>> this doesn't load correctly in a browser):
>> https://eclipse.gwtproject.org.vertispan.com/2023-01-18/
>>
>> If there are no objections, once we've finished the 4.0 plugin and are 
>> ready for a release, I'll formally set up *eclipse.gwtproject.org 
>> <http://eclipse.gwtproject.org>*. For the moment I anticipate only a 
>> plugins/ directory, with each versioned release (and maybe a nightly build 
>> setup too), to allow for additional content later.
>>
>> Using the gwtproject.org domain name seems natural as a large number of 
>> GWT developers use Eclipse and this plugin, and the documentation at 
>> gwtproject.org has long since offered Eclipse instructions, with little 
>> space given to IntelliJ or Maven/Gradle. I'd further propose we should 
>> improve that situation, but that's a separate discussion. Vertispan intends 
>> to host this new plugin content, and we are already hosting the 
>> gwtproject.org domain content.
>>
>> If there are reservations about gwtproject.org also hosting the eclipse 
>> plugin, we can set up an alternate domain name for this work, though at 
>> least for the time being, Vertspan will be hosting these together.
>>
>

-- 
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/5a849455-6192-48aa-8c4d-cb724ebc120bn%40googlegroups.com.

[gwt-contrib] Re: Compiling gwt on Mac ?

[Colin Alworth]

That patch is delayed since it turns out there are some tests that rely on 
specific behavior from the JVM - a few JPMS violations in legacy dev mode, 
and apparently Annotation.toString() changed slightly breaking a few other 
tests. I think it is just about ready, but each round of testing takes a 
few hours, so it is hard to get it done in one sitting.

But it will produce working output, including docs, if you want to use it 
to build a GWT SDK locally.

On Wednesday, March 22, 2023 at 4:25:48 AM UTC-5 Jens wrote:

> Doctool hasn't been updated yet, see: 
> https://github.com/gwtproject/gwt/pull/9780
>
> You can install Java 8 for Mac x86 using 
> https://adoptium.net/de/temurin/releases/?version=8 
>
> If you use a Mac with Apple Silicon and don't want to install Rosetta 2 
> you would need to install Java 8 from a different vendor, e.g. Azul Zulu or 
> Amazon Corretto 8 (also available via brew.sh). Or you make/use a Docker 
> image with Java 8 + ANT (+ Maven if you want to push the build to a 
> corporate repository), mount the GWT SDK + Tools repositories and compile 
> inside the container.
>
> -- J.
>
> stuckagain schrieb am Mittwoch, 22. März 2023 um 09:21:42 UTC+1:
>
>> Is it possible to compile GWT on a Mac ? Is it mandatory to use Java 8, 
>> that version is no longer available.
>>
>> I have Java 11 installed, but I get the following error:
>>
>>
>>
>> compile:
>>
>> [mkdir] Created dir: 
>> /Users/me/Projects/gwt/build/out/build_tools/doctool/bin
>>
>> [javac] Compiling 10 source files to 
>> /Users/me/Projects/gwt/build/out/build_tools/doctool/bin
>>
>> [javac] -Xbootclasspath/p is no longer a supported option.
>>
>> [javac] Error: Could not create the Java Virtual Machine.
>>
>> [javac] Error: A fatal exception has occurred. Program will exit.
>>
>>
>>
>>

-- 
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/a72e40cb-8dd4-4e20-be09-5739020c8c55n%40googlegroups.com.

[gwt-contrib] Preparing for GWT 2.11 release

[Colin Alworth]

There have been a few suggestions of making a release in the near future, 
and it seemed like it might be a good idea to summarize pending 
development, ask for help to land these, and see if anything else needs to 
be addressed before shipping.


   - There is a pending branch (not yet a PR for GWT itself) working on 
   adding a new gwt-servlet-jakarta.jar and requestfactory-server-jakarta.jar 
   as part of https://github.com/gwtproject/gwt/issues/9727. There is no plan 
   at this time to update the DevMode server to Jakarta, though that will 
   eventually be inevitable if we move to a newer version of Jetty. Work on 
   this can be found at https://github.com/niloc132/gwt/pull/3.
   - There is a pending fix for eliminating a false positive from using 
   some internals of protobuf to deobfuscate client side exceptions 
   https://github.com/gwtproject/gwt/pull/9785. This is probably safe to land 
   without more testing, but none of the reporters of this bug have verified 
   the fix.
   - There's a pending fix for a bug in type unions, which can be caused by 
   some ternary expressions and var type declarations 
   https://github.com/gwtproject/gwt/pull/9799. A review found a few 
   oversights in testing, and I'd appreciate another look.
   - There's a pending fix for a bug where debugging in firefox when 
   assertions are enabled (for example in SDM). It turns out the bug can 
   happen in other cases too in more subtle ways. A draft fix it at 
   https://github.com/gwtproject/gwt/pull/9800.
   - GWT itself can now be built on Java 11, but not yet 17. There are a 
   few changes pending that will permit this. Additionally, this will enable 
   adding more Java 9-11 JRE emulation, see the list at 
   https://github.com/gwtproject/gwt/issues/9547.


Finally, we have an open question about future Java 8 support. Beyond this 
release, we likely will no longer support running the compiler in Java 8, 
which will enable adding support for Java 12-17 language features. We can 
likely still build jars that will run on a Java 8 server, but just can't 
compile newer JS. To that end, this 2.11 release branch may be longer-lived 
than usual, depending on feedback and support to continue bugfix releases 
after 2.12 eventually ships.

Are there other changes that 2.11 should included, or other considerations 
for this release cycle?

-- 
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/18e9c767-a2e8-42e2-9b6c-764dc0088629n%40googlegroups.com.

[gwt-contrib] Re: Preparing for GWT 2.11 release

[Colin Alworth]

It has taken longer than we had hoped, but I think we're just about ready - 
GWT itself can build on Java 17 (and can run on Java 23), JRE emulation is 
nearly caught up to where we wanted with Java 11, and jakarta.servlet 
support is hopefully finished and partially tested in non-trivial apps.

Here's my view of what might land before we cut a release:

   - The jakarta.servlet patch is now at 
   https://github.com/gwtproject/gwt/pull/9845, and is effectively ready to 
   land. To my knowledge, no jakarta project has tested the 
   requestfactory-*.jars yet.
   - As above, we need confirmation that 
   https://github.com/gwtproject/gwt/pull/9785 solves the problem it was 
   created for.
   - As above https://github.com/gwtproject/gwt/pull/9799 (fixing some 
   ternary expressions and other type unions) should get at least one more 
   review, approval. This will be applicable for Java 17 language support.
   - Two more JRE emulation patches: 
   https://github.com/gwtproject/gwt/pull/9860 needs a review, and 
   https://github.com/gwtproject/gwt/pull/9862 needs follow-up and another 
   review.
   
If this is the last release that can run the compiler and dev mode on Java 
8, we will want to update Jetty in the next release as well. That might 
suggest one more change, deprecating the use of "-server" in DevMode. 
Please see https://github.com/gwtproject/gwt/issues/9863 for more details. 
In the coming days I'll put together a patch for this.

After we've merged or deferred these PRs, the next step will be asking for 
testing volunteers and cutting an RC release. I'm hoping we can begin that 
process within two weeks - if you're interested in helping us test this 
release, please reply to this message or directly with the OS/JVM/Browsers 
you have at your disposal, and I'll make sure you are included. As usual, 
the testing process will probably take a week or so to get the desired 
coverage, and then we'll formally release GWT 2.11.0.

On Tuesday, May 23, 2023 at 3:11:51 PM UTC-5 Rocco De Angelis wrote:

> Hi Colin,
>
> if you need some help, I'm feeling to help. 
> Specially the jakarta stuff is important for us.
> Do you find the time to have a look to the open PR?
>
> BR
> Rocco
>
> Colin Alworth schrieb am Mittwoch, 17. Mai 2023 um 16:44:58 UTC+2:
>
>> There have been a few suggestions of making a release in the near future, 
>> and it seemed like it might be a good idea to summarize pending 
>> development, ask for help to land these, and see if anything else needs to 
>> be addressed before shipping.
>>
>>
>>- There is a pending branch (not yet a PR for GWT itself) working on 
>>adding a new gwt-servlet-jakarta.jar and 
>> requestfactory-server-jakarta.jar 
>>as part of https://github.com/gwtproject/gwt/issues/9727. There is no 
>>plan at this time to update the DevMode server to Jakarta, though that 
>> will 
>>eventually be inevitable if we move to a newer version of Jetty. Work on 
>>this can be found at https://github.com/niloc132/gwt/pull/3.
>>- There is a pending fix for eliminating a false positive from using 
>>some internals of protobuf to deobfuscate client side exceptions 
>>https://github.com/gwtproject/gwt/pull/9785. This is probably safe to 
>>land without more testing, but none of the reporters of this bug have 
>>verified the fix.
>>- There's a pending fix for a bug in type unions, which can be caused 
>>by some ternary expressions and var type declarations 
>>https://github.com/gwtproject/gwt/pull/9799. A review found a few 
>>oversights in testing, and I'd appreciate another look.
>>- There's a pending fix for a bug where debugging in firefox when 
>>assertions are enabled (for example in SDM). It turns out the bug can 
>>happen in other cases too in more subtle ways. A draft fix it at 
>>https://github.com/gwtproject/gwt/pull/9800.
>>- GWT itself can now be built on Java 11, but not yet 17. There are a 
>>few changes pending that will permit this. Additionally, this will enable 
>>adding more Java 9-11 JRE emulation, see the list at 
>>https://github.com/gwtproject/gwt/issues/9547.
>>
>>
>> Finally, we have an open question about future Java 8 support. Beyond 
>> this release, we likely will no longer support running the compiler in Java 
>> 8, which will enable adding support for Java 12-17 language features. We 
>> can likely still build jars that will run on a Java 8 server, but just 
>> can't compile newer JS. To that end, this 2.11 release branch may be 
>> longer-lived than usual, depending on feedback and support to continue 
>> bugfix 

[gwt-contrib] Re: Preparing for GWT 2.11 release

[Colin Alworth]

Yes, I'll create a staging repository with the actual artifacts that we 
intend to release to Maven Central, and will also provide a .zip download 
for the SDK itself.

On Wednesday, November 15, 2023 at 8:16:40 AM UTC-6 Zbyněk Konečný wrote:

> Hi,
>
> I can do some testing on Windows with Java 11 and Chrome/Edge/Firefox. 
> Will the jars for testing be available in some Maven repo?
>
> Cheers,
> Zbynek
>
> On Wednesday, November 15, 2023 at 3:37:38 AM UTC+1 Colin Alworth wrote:
>
>> It has taken longer than we had hoped, but I think we're just about ready 
>> - GWT itself can build on Java 17 (and can run on Java 23), JRE emulation 
>> is nearly caught up to where we wanted with Java 11, and jakarta.servlet 
>> support is hopefully finished and partially tested in non-trivial apps.
>>
>> Here's my view of what might land before we cut a release:
>>
>>- The jakarta.servlet patch is now at 
>>https://github.com/gwtproject/gwt/pull/9845, and is effectively ready 
>>to land. To my knowledge, no jakarta project has tested the 
>>requestfactory-*.jars yet.
>>- As above, we need confirmation that 
>>https://github.com/gwtproject/gwt/pull/9785 solves the problem it was 
>>created for.
>>- As above https://github.com/gwtproject/gwt/pull/9799 (fixing some 
>>ternary expressions and other type unions) should get at least one more 
>>review, approval. This will be applicable for Java 17 language support.
>>- Two more JRE emulation patches: 
>>https://github.com/gwtproject/gwt/pull/9860 needs a review, and 
>>https://github.com/gwtproject/gwt/pull/9862 needs follow-up and 
>>another review.
>>
>> If this is the last release that can run the compiler and dev mode on 
>> Java 8, we will want to update Jetty in the next release as well. That 
>> might suggest one more change, deprecating the use of "-server" in DevMode. 
>> Please see https://github.com/gwtproject/gwt/issues/9863 for more 
>> details. In the coming days I'll put together a patch for this.
>>
>> After we've merged or deferred these PRs, the next step will be asking 
>> for testing volunteers and cutting an RC release. I'm hoping we can begin 
>> that process within two weeks - if you're interested in helping us test 
>> this release, please reply to this message or directly with the 
>> OS/JVM/Browsers you have at your disposal, and I'll make sure you are 
>> included. As usual, the testing process will probably take a week or so to 
>> get the desired coverage, and then we'll formally release GWT 2.11.0.
>>
>> On Tuesday, May 23, 2023 at 3:11:51 PM UTC-5 Rocco De Angelis wrote:
>>
>>> Hi Colin,
>>>
>>> if you need some help, I'm feeling to help. 
>>> Specially the jakarta stuff is important for us.
>>> Do you find the time to have a look to the open PR?
>>>
>>> BR
>>> Rocco
>>>
>>> Colin Alworth schrieb am Mittwoch, 17. Mai 2023 um 16:44:58 UTC+2:
>>>
>>>> There have been a few suggestions of making a release in the near 
>>>> future, and it seemed like it might be a good idea to summarize pending 
>>>> development, ask for help to land these, and see if anything else needs to 
>>>> be addressed before shipping.
>>>>
>>>>
>>>>- There is a pending branch (not yet a PR for GWT itself) working 
>>>>on adding a new gwt-servlet-jakarta.jar and 
>>>>requestfactory-server-jakarta.jar as part of 
>>>>https://github.com/gwtproject/gwt/issues/9727. There is no plan at 
>>>>this time to update the DevMode server to Jakarta, though that will 
>>>>eventually be inevitable if we move to a newer version of Jetty. Work 
>>>> on 
>>>>this can be found at https://github.com/niloc132/gwt/pull/3.
>>>>- There is a pending fix for eliminating a false positive from 
>>>>using some internals of protobuf to deobfuscate client side exceptions 
>>>>https://github.com/gwtproject/gwt/pull/9785. This is probably safe 
>>>>to land without more testing, but none of the reporters of this bug 
>>>> have 
>>>>verified the fix.
>>>>- There's a pending fix for a bug in type unions, which can be 
>>>>caused by some ternary expressions and var type declarations 
>>>>https://github.com/gwtproject/gwt/pull/9799. A review found a few 
>>>>oversights in testing, and I'

Re: [gwt-contrib] Re: Preparing for GWT 2.11 release

[Colin Alworth]

We're still in the "please help us review the last few merges" phase 
(especially looking for notes on deprecating using DevMode as an app 
server, and comments on if tests added for other PRs seem sufficient), then 
we'll make some release artifacts (late next week is my guess). I'm hoping 
to merge most of the open PRs, so we want to not start testing until we've 
landed that changes that will make this release.

That being said, we ship HEAD-SNAPSHOT every night off of main, you can add 
https://oss.sonatype.org/content/repositories/snapshots/ as a snapshot 
repository to your project to use that build (be certain you are using 
org.gwtproject groupids). If you need nightly download zips, they are 
available at 
https://github.com/gwtproject/gwt/actions/workflows/full-check.yml, click 
any build, scroll down artifacts, and download gwt-java17.zip. While this 
was built with Java 17, it is compatible with Java 8+ and will be used for 
the release. The other builds should be nearly identical - the main change 
should be in the javadoc output. The build produced from Java8 is 
substantially smaller since it doesn't include javadoc at all, since the 
APIs we now use are not compatible there.

On Thursday, November 23, 2023 at 7:36:55 AM UTC-6 Juan Pablo Gardella 
wrote:

> Hello, is gwt-2.11 artifacts available somewhere for testing against the 
> applications I am currently working on?
>
> On Tue, Nov 14, 2023, 11:37 PM Colin Alworth  wrote:
>
>> It has taken longer than we had hoped, but I think we're just about ready 
>> - GWT itself can build on Java 17 (and can run on Java 23), JRE emulation 
>> is nearly caught up to where we wanted with Java 11, and jakarta.servlet 
>> support is hopefully finished and partially tested in non-trivial apps.
>>
>> Here's my view of what might land before we cut a release:
>>
>>- The jakarta.servlet patch is now at 
>>https://github.com/gwtproject/gwt/pull/9845, and is effectively ready 
>>to land. To my knowledge, no jakarta project has tested the 
>>requestfactory-*.jars yet.
>>- As above, we need confirmation that 
>>https://github.com/gwtproject/gwt/pull/9785 solves the problem it was 
>>created for.
>>- As above https://github.com/gwtproject/gwt/pull/9799 (fixing some 
>>ternary expressions and other type unions) should get at least one more 
>>review, approval. This will be applicable for Java 17 language support.
>>- Two more JRE emulation patches: 
>>https://github.com/gwtproject/gwt/pull/9860 needs a review, and 
>>https://github.com/gwtproject/gwt/pull/9862 needs follow-up and 
>>another review.
>>
>> If this is the last release that can run the compiler and dev mode on 
>> Java 8, we will want to update Jetty in the next release as well. That 
>> might suggest one more change, deprecating the use of "-server" in DevMode. 
>> Please see https://github.com/gwtproject/gwt/issues/9863 for more 
>> details. In the coming days I'll put together a patch for this.
>>
>> After we've merged or deferred these PRs, the next step will be asking 
>> for testing volunteers and cutting an RC release. I'm hoping we can begin 
>> that process within two weeks - if you're interested in helping us test 
>> this release, please reply to this message or directly with the 
>> OS/JVM/Browsers you have at your disposal, and I'll make sure you are 
>> included. As usual, the testing process will probably take a week or so to 
>> get the desired coverage, and then we'll formally release GWT 2.11.0.
>>
>> On Tuesday, May 23, 2023 at 3:11:51 PM UTC-5 Rocco De Angelis wrote:
>>
>>> Hi Colin,
>>>
>>> if you need some help, I'm feeling to help. 
>>> Specially the jakarta stuff is important for us.
>>> Do you find the time to have a look to the open PR?
>>>
>>> BR
>>> Rocco
>>>
>>> Colin Alworth schrieb am Mittwoch, 17. Mai 2023 um 16:44:58 UTC+2:
>>>
>>>> There have been a few suggestions of making a release in the near 
>>>> future, and it seemed like it might be a good idea to summarize pending 
>>>> development, ask for help to land these, and see if anything else needs to 
>>>> be addressed before shipping.
>>>>
>>>>
>>>>- There is a pending branch (not yet a PR for GWT itself) working 
>>>>on adding a new gwt-servlet-jakarta.jar and 
>>>>requestfactory-server-jakarta.jar as part of 
>>>>https://github.com/gwtproject/gwt/issues/9727. There is no plan at 
>>>&g

[gwt-contrib] Re: Infinite loop at compile time

[Colin Alworth]

Thanks for reporting - perhaps better for the bug tracker, and indeed we do 
this (or something like it) filed already, see 
https://github.com/gwtproject/gwt/issues/9840.

Your email title says that this is a compile time infinite loop, but then 
the body suggests that it was a runtime error. If it were to be exhibited 
at runtime, it would almost certainly be a stackoverflow rather than 
looping forever (barring some sort of tail call optimization). The actual 
loop that you're seeing is waaay up the stack in 

at 
com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimizeJsLoop(JavaToJavaScriptCompiler.java:1001)

where the compiler decides to optimize until it reaches your optimization 
level, or until nothing changes. While SDM stands for "Super Dev Mode", it 
can also be understood to mean "Super Draft Mode", so the compiler builds 
as quickly and cheaply as possible, letting your app escape with very 
little optimization. This means that in SDM, you will not get stuck in this 
loop - the optimization loop won't run at all (see one frame up, 
shouldOptimize will return false), and you'll instead experience a 
stackoverflow at runtime.

I didn't continue investigation of the problem further yet, but the linked 
ticket does have some analysis to consider.
On Monday, January 22, 2024 at 8:30:50 AM UTC-6 Paul Robinson wrote:

> I just found an infinite loop while running the GWT compiler.
>
> There was a trivial bug in my code which resulted in an infinite loop at 
> *runtime*. This is a method that was calling itself recursively. It was 
> inside a generic class, and the method had a single line that was something 
> like this:
>
> public class A extends C {
> public static  A getA(D d, E e, F f) {
> return getA(d, e, null);
> }
> }
>
> I have been running in dev mode with it like this, but not hitting this 
> code so I didn't notice the infinite loop.
>
> Wanting to test GWT 2.11.0, I switched from GWT 2.10.0 and did a full GWT 
> compile. The interesting thing is that the GWT compile also hit an infinite 
> loop. Or rather, it was apparently infinite. I stopped it after 50 minutes, 
> where it would normally complete in about about 90 seconds. I dropped back 
> to 2.10.0, and found the same behaviour. So it's not caused by the new 
> release.
>
> Fixing the bug in my code meant it then compiled properly (in both 2.11.0 
> and 2.10.0).
>
> Is this interesting enough to warrant further investigation? This is code 
> inside a large application, so isolating a simple example that demonstrates 
> it might not work easily.
>
> FWIW there's a stack trace taken while stuck in the loop, compiling with 
> 2.11.0 here: https://pastebin.com/qckpswRD
>
> Paul
>
>

-- 
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/58e74afc-7677-4a92-8895-880d884cd802n%40googlegroups.com.

[gwt-contrib] Preparing for GWT 2.12 release

[Colin Alworth]

The 2.12 release seems to be almost ready - we're trying to do releases a 
little more frequently when we have changes to be made, and this is going 
to end up being about nine months after the 2.11 release.

Considerations for this release:
 * *Java 8 support is formally dropped* for running the compiler and dev 
mode. It may continue to work for the server, but our testing here is light 
- if it is important to you, please help with testing the early release to 
be sure.
 * *Java 17 language support has been added* - everything except 
switch-expression is merged, consider reviewing/testing 
https://github.com/gwtproject/gwt/pull/9981 to finalize that PR so we can 
finish this aspect of the release.
 * Several deprecated classes have been removed, and more still are now 
marked deprecated and will be removed in a future release. These are likely 
not used by your project, as most are unusable today anyway, but the change 
can be reviewed here https://github.com/gwtproject/gwt/pull/9925
 * Browsers have deprecated the unload event, and GWT has been interfering 
with some applications that don't directly use it. A PR is up to resolve 
this, but could use testing from anyone who might be affected by this: 
https://github.com/gwtproject/gwt/pull/9984
 * Sourcemap support has been updated - no major impact here aside from 
dropping the need to use (a very old version of) protobufs in the server, 
and supporting writing all source files as part of the sourcemap JSON file 
rather than needing all source files copied to a server to be useful.

Next steps:
 * Help review, finalize the pending PRs.
 * Let us know if there are other pending reviews or fixes that need to be 
targeted to the 2.12 milestone.
 * Test HEAD-SNAPSHOT builds to confirm no regressions in your own projects 
(either download from the Sonatype snapshot repo, or download the SDK zips 
from one of the builds at 
https://github.com/gwtproject/gwt/actions/workflows/full-check.yml).
 * In a week or so, volunteer for testing when a release is prepared.
 * *If you need to run only on Java 8* and you need some of these changes, 
help us start a separate release process for GWT 2.11.x. Many of these 
changes can be backported, but we need assistance to make that work happen.

All commits since 2.11: 
https://github.com/gwtproject/gwt/compare/2.11.0...main

-- 
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/155bce20-d224-4b9f-8eea-98071d4547ccn%40googlegroups.com.

Re: [gwt-contrib] Preparing for GWT 2.12 release

[Colin Alworth]

The org.gwtproject groupId uses the oss.sonatype.org server, rather than 
s01. So, check 
https://oss.sonatype.org/content/repositories/snapshots/org/gwtproject/ for 
the gwt-dev, gwt-user, etc artifacts.

On Wednesday, August 21, 2024 at 6:47:21 AM UTC-5 Juan Pablo Gardella wrote:

> Where is the gwt head snapshot? I cannot find it at 
> https://s01.oss.sonatype.org/content/repositories/snapshots/org/. 
>
> On Sun, Aug 11, 2024 at 5:48 PM Juan Pablo Gardella  
> wrote:
>
>> I will help with testing Colin! Thanks a lot for all your effort 
>>
>>
>> On Sun, Aug 11, 2024 at 1:31 PM Colin Alworth  wrote:
>>
>>> The 2.12 release seems to be almost ready - we're trying to do releases 
>>> a little more frequently when we have changes to be made, and this is going 
>>> to end up being about nine months after the 2.11 release.
>>>
>>> Considerations for this release:
>>>  * *Java 8 support is formally dropped* for running the compiler and 
>>> dev mode. It may continue to work for the server, but our testing here is 
>>> light - if it is important to you, please help with testing the early 
>>> release to be sure.
>>>  * *Java 17 language support has been added* - everything except 
>>> switch-expression is merged, consider reviewing/testing 
>>> https://github.com/gwtproject/gwt/pull/9981 to finalize that PR so we 
>>> can finish this aspect of the release.
>>>  * Several deprecated classes have been removed, and more still are now 
>>> marked deprecated and will be removed in a future release. These are likely 
>>> not used by your project, as most are unusable today anyway, but the change 
>>> can be reviewed here https://github.com/gwtproject/gwt/pull/9925
>>>  * Browsers have deprecated the unload event, and GWT has been 
>>> interfering with some applications that don't directly use it. A PR is up 
>>> to resolve this, but could use testing from anyone who might be affected by 
>>> this: https://github.com/gwtproject/gwt/pull/9984
>>>  * Sourcemap support has been updated - no major impact here aside from 
>>> dropping the need to use (a very old version of) protobufs in the server, 
>>> and supporting writing all source files as part of the sourcemap JSON file 
>>> rather than needing all source files copied to a server to be useful.
>>>
>>> Next steps:
>>>  * Help review, finalize the pending PRs.
>>>  * Let us know if there are other pending reviews or fixes that need to 
>>> be targeted to the 2.12 milestone.
>>>  * Test HEAD-SNAPSHOT builds to confirm no regressions in your own 
>>> projects (either download from the Sonatype snapshot repo, or download the 
>>> SDK zips from one of the builds at 
>>> https://github.com/gwtproject/gwt/actions/workflows/full-check.yml).
>>>  * In a week or so, volunteer for testing when a release is prepared.
>>>  * *If you need to run only on Java 8* and you need some of these 
>>> changes, help us start a separate release process for GWT 2.11.x. Many of 
>>> these changes can be backported, but we need assistance to make that work 
>>> happen.
>>>
>>> All commits since 2.11: 
>>> https://github.com/gwtproject/gwt/compare/2.11.0...main
>>>
>>> -- 
>>> 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/155bce20-d224-4b9f-8eea-98071d4547ccn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/155bce20-d224-4b9f-8eea-98071d4547ccn%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/a71ae24f-9a2f-4e83-bfec-f1b6c21819b2n%40googlegroups.com.

Re: [gwt-contrib] Re: widget interfaces

[Colin Alworth]

What are we looking at having in these interfaces? The discussion that
Goktug and I had a few months ago got stalled around the concept that these
interfaces were trying to both be a) implementation independent but also b)
rich enough to be useful. Doing both is hard/meaningless.

To pick an example, button has a few basic premises (in the standard GWT
widgets) - it has text (or html if you support a base other than an
), it can receive focus, and it is a source of click events. In a
perfect world an implementation could be backed by an appearance (perhaps
wrapped itself in a cell) like the TextButton...

But this ends up meaning that 'click' events aren't the only thing to worry
about - a  won't pass along key events like space or enter as a means
of activating the button. So we either need to also emit key events, and
touch events, or need to wrap all of these in one event (GXT calls it a
SelectEvent).

Either we have a backward compat problem (can't represent both past and
future button-ish widgets with the same interface), or we limit the button
implementations to a single setup (must be backed by  or ,
or perhaps an ?).

So, my point: Is the purpose of the IsButton *only* to be an interface for
com.google.gwt.user.client.ui.Button? Or are we trying to build this out
for the ideal button (and ideal text box, etc)?

On Wed, Jun 5, 2013 at 4:28 PM, Ed  wrote:

> The simpler thing than buffering is just to have a StubButton, e.g.:
>
> A, how could I forget ;)... I just remember the Stubs* Widgets in your
> gitHub  ;)
>
> But is this even needed ?
> If you use a template mechanism it might not be needed.
> The template is created during setStyle() and other operations and only
> used in GWT client mode when the underlying "Widget" is created...
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
218.248.6165
niloc...@gmail.com

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: widget interfaces

[Colin Alworth]

Slight follow up to both Stephen's comments here and my own prev post - If
the interfaces are for existing, standard, built-in GWT widgets, type 2
makes a lot more sense, whereas for type 1, we really seem to need a
general, ideal button that can be replaced by any implementation (with
possibly any internal rebuilding via appearance/cells/etc).

-Colin

On Wed, Jun 5, 2013 at 4:36 PM, Stephen Haberman
wrote:

>
> > Yeah this Type 1 style is really PITA in the long term, especially if
> > views are a bit more complex.
>
> I disagree; I actually prefer Type 1. Although to each their own, of
> course.
>
> > However, with the release of UiBinder we constantly tell
> > people/recommend to use the Type 2 style of MVP with UiBinder +
> > @UiHandler and a delegate interface if they ask for MVP in
> > gwt-discuss.
>
> UiHandler makes inner classes 2 lines shorter, but IMO it still leads
> to the same spaghetti code (reactive/imperative, instead of
> declarative).
>
> Tessell's binding DSL makes simple/common operations one line
> declarations (explicitly via Type 1-exposed widget interfaces, not
> UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as
> succinct as:
>
>
> https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43
>
> > So I think this argument looses some weight as probably no one really
> > wants to do the type 1 way anymore and only a minority still choose
> > it for new projects.
>
> Well, that is unfortunate, as MVP Type 1 with Tessell's view generation
> and binding DSL is quite pleasant. But, again, to each their own. :-)
>
> > No need for GWTMockUtilities.disarm() or gwtmockito then.
>
> Exactly.
>
> - Stephen
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
218.248.6165
niloc...@gmail.com

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..


Patch Set 6: Code-Review+1

Nope, we can work with it - a wrapper isn't really an option, since we get  
real benefit from getting static methods that look like instance ones  
without the mess of static imports or new-ing up instances that wrap the  
original elt just long enough to run a method on them and gc them (unless  
the compiler now can unwrap that single final field and method and treat it  
as if it were static to begin with?). We used to have a great big flyweight  
thing going on to avoid the extra object creation, but move to extending  
Element to avoid that little extra cost...


My main point was to bring it up as a point to discuss, to make sure that  
adding a new final method to a non-final class was deliberate. GXT is happy  
to plan ahead and remove it before 2.6 lands (and thanks for the heads up  
on toggleClassName), and move to something else in the meantime, we'd just  
rather not make a habit of that, cutting new specific gxt minor releases to  
accommodate specific gwt minor releases, and I'm sure we're not alone in  
that.


--
To view, visit https://gwt-review.googlesource.com/3070
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Andrey Korzhevskiy 
Gerrit-Reviewer: Colin Alworth 
Gerrit-Reviewer: Daniel Kurka 
Gerrit-Reviewer: Goktug Gokdogan 
Gerrit-Reviewer: Stephen Haberman 
Gerrit-Reviewer: Thomas Broyer 
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..


Patch Set 6:

Thanks Goktug - one of the distinct advantages of extending Element is that  
we can subclass UiObject.getElement and already have access to the methods  
we want, and on the other side the subclass can invoke Element methods  
(without the pretend-jso-cast). As I understand it, from your example,  
GxtElement is superfluous - we'd need to .cast() to GxtElement to even get  
the .cast() method to get GxtExtensions ;).


(wrapping up, as Andrey's code review probably isn't the place...) W.R.T.  
devirtualization, that doesn't quite go far enough - constructors do not go  
away, and the this$static is still needed, even though it is only to grab  
the one field inside it. And while v8 might do the alias analysis and drop  
the ctor, I'm all by certain that IE6-9 don't (and 10 would be a guess).


--
To view, visit https://gwt-review.googlesource.com/3070
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Andrey Korzhevskiy 
Gerrit-Reviewer: Colin Alworth 
Gerrit-Reviewer: Daniel Kurka 
Gerrit-Reviewer: Goktug Gokdogan 
Gerrit-Reviewer: Stephen Haberman 
Gerrit-Reviewer: Thomas Broyer 
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add interfaces for widgets.
..


Patch Set 6:

(4 comments)


File user/src/com/google/gwt/dom/client/HasStyle.java
Line 29:   void setStyleName(String styleName);
Might be worth adding hasStyleName, as this was recently added to Element -  
Goktug indicated in that review that a toggleStyleName is on the way as  
well. https://gwt-review.googlesource.com/#/c/3070/




File user/src/com/google/gwt/dom/client/IsElement.java
Line 61:   void appendChild(IsElement element);
This method seems out of place - it is the closest we get to dom  
manipulation - no removeChild(IsElement) nor IsElement getParentElement()  
or any getChild (which may not be). Is there a reason you picked this and  
removeFromParent, but not other dom methods? Variance issues almost explain  
it, but then I noticed that you needed to add new methods just to support  
this in Element itself.


And since you already are needing to add new methods in Element to deal  
with IsElement vs Node, would it make sense then to add new methods for  
these?




File user/src/com/google/gwt/user/client/ui/IsUIObject.java
Line 27:   IsElement getIsElement();
My concern there would be that we'd no longer have a way to get access to  
the element as a jso in the code that needs it. If I wanted the element so  
I could treat it as a InputElement, the JSO.cast() is no longer available  
to me, only the regular Java cast. Not a huge loss, but it definitely is a  
breaking change.


Simple/ugly way around that might be to rename IsElement.asElement to  
IsElement.cast, with the JSO.cast generics. Returns null for stubs, and  
with a real element lets you cast as usual.




File user/src/com/google/gwt/user/client/ui/IsWidget2.java
Line 28: public interface IsWidget2 extends IsWidget, IsUIObject,  
EventListener, HasHandlers,
(Sorry if I missed this discussion elsewhere, but) What is the  
philosophical thinking on IsWidget vs IsWidget2? This is for mocking  
Widget, while IsWidget is for Composite-free composition? If that is the  
idea, what about another name than IsWidget2, which seems to  
suggest 'better isWidget' rather than 'mockable iswidget'.



--
To view, visit https://gwt-review.googlesource.com/3231
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Colin Alworth 
Gerrit-Reviewer: Daniel Kurka 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Thomas Broyer 
Gerrit-HasComments: Yes

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Colin Alworth has uploaded a new change for review.

  https://gwt-review.googlesource.com/3361


Change subject: Ensure clinits get called for JSO instance methods.
..

Ensure clinits get called for JSO instance methods.

In following Java semantics, any static initialization code in a class
(collectively a clinit) should be run before any part of that class is  
used. To

achieve this, GWT ensures that this clinit was invoked before any (actually)
static method, and as part of any constructor. This way, instance methods  
are

sure to have already run the clinit, so it doesn't need to be run again.

However, JSO constructors don't exist, so instance methods are not  
guaranteed to
have had the clinit already run. This is the bug that this patch is trying  
to

fix.

Two locations are changed, both with the effect of ensuring that a clinit is
emitted for JSOs. First, the MethodInliner must not skip adding a call to  
the
clinit when the jso body is inlined and the method invocation (and ref to  
the

class) is dropped, and second, GenerateJavaScriptAST must likewise write out
explicit clinits for any static method or jso instance method.

Bug: issue 3192
Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
2 files changed, 4 insertions(+), 4 deletions(-)



diff --git  
a/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java

index 240f6a0..1c7944a 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
@@ -2189,10 +2189,10 @@
   if (!crossClassTargets.contains(x)) {
 return null;
   }
-  if (x.canBePolymorphic() || program.isStaticImpl(x)) {
+  JDeclaredType enclosingType = x.getEnclosingType();
+  if (x.canBePolymorphic() || (program.isStaticImpl(x)  
&& !program.isJavaScriptObject(enclosingType))) {

 return null;
   }
-  JDeclaredType enclosingType = x.getEnclosingType();
   if (enclosingType == null || !enclosingType.hasClinit()) {
 return null;
   }
diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java

index d2b05ae..6acbb49 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
@@ -169,8 +169,8 @@
 // Access from this class to the target class won't trigger a  
clinit

 return null;
   }
-  if (program.isStaticImpl(x.getTarget())) {
-// No clinit needed; target is really an instance method.
+  if (program.isStaticImpl(x.getTarget())  
&& !program.isJavaScriptObject(x.getTarget().getEnclosingType())) {

+// No clinit needed; target is really a non-jso instance method.
 return null;
   }
   if (JProgram.isClinit(x.getTarget())) {

--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth 

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 1:

Afraid not, this is the exact same patch we looked at - only difference was  
that I pulled the sys.out.println I was using to debug the circumstances  
for this fix.


W.r.t. test cases, would those be best in the form of a test JSO that  
demonstrates the issue, or something that actually builds a sample ast and  
verifies that JsInvocations or JMethodCalls are created for the clinit? I  
have the test sample from the original bug report that could be made into a  
GwtTestCase, but that seems a little more testing the effect than the bug.  
That said, I'm not seeing (or perhaps not looking in the right place for) a  
lot of test cases that make sure the generated JS is sane.


One last thought - while moving this from SVN to Git, it occurred to me  
that this same fix could potentially be achieved in another way: In the  
same way that MakeCallsStatic ties newly static calls to their original  
instance version via JProgram.putStaticImpl, it appears that  
JsoDevirtualizer could do the same. This would make these methods show up  
as needing a clinit when the `program.isStaticImpl(x.getTarget())` check is  
made (as in MethodInliner.createClinitCall. From your general gwtc point of  
view, does that seem to be a reasonable (as well as clearer) fix?


--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth 
Gerrit-Reviewer: Colin Alworth 
Gerrit-Reviewer: John A. Tamplin 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3361

to look at the new patch set (#2).

Change subject: Ensure clinits get called for JSO instance methods.
..

Ensure clinits get called for JSO instance methods.

In following Java semantics, any static initialization code in a class
(collectively a clinit) should be run before any part of that class is  
used. To

achieve this, GWT ensures that this clinit was invoked before any (actually)
static method, and as part of any constructor. This way, instance methods  
are

sure to have already run the clinit, so it doesn't need to be run again.

However, JSO constructors don't exist, so instance methods are not  
guaranteed to
have had the clinit already run. This is the bug that this patch is trying  
to

fix.

Two locations are changed, both with the effect of ensuring that a clinit is
emitted for JSOs. First, the MethodInliner must not skip adding a call to  
the
clinit when the jso body is inlined and the method invocation (and ref to  
the

class) is dropped, and second, GenerateJavaScriptAST must likewise write out
explicit clinits for any static method or jso instance method.

The jso methods for the unit tests include methods that seem slightly  
convoluted
to avoid being inlined - once inlined, the clinit would re-appear (as it  
shoud,
since the static field is being accessed directly). Each situation being  
tested
requires its own type, since the test app would require being restarted to  
empty
out each static field. Note that prior to this fix, only the "instance  
method"
case failed and returned null - the other situations are added just to  
ensure

that everything else is behaving as expected going forward.

Bug: issue 3192
Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
M user/test/com/google/gwt/dev/jjs/test/JsoTest.java
3 files changed, 70 insertions(+), 4 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth 
Gerrit-Reviewer: Colin Alworth 
Gerrit-Reviewer: John A. Tamplin 
Gerrit-Reviewer: Leeroy Jenkins 

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 2:

(2 comments)


File user/test/com/google/gwt/dev/jjs/test/JsoTest.java
Line 49:   static final class ClinitStaticFieldFirst extends  
JavaScriptObject {

Correct - the commit message documents this, but I'll stick a comment too.


Line 54:   if (FIELD == null) {
Again, commit message touched on it. The bug only manifests in compiled  
code, and the compiler will inline this if it is too simple. I was going  
for the simplest code I could write that would not be optimized out (at  
least in draft mode) without using JSNI. Not that there is an issue with  
JSNI here, just that I wanted to keep the issue on track for following Java  
semantics. Once the method gets inlined, the bug goes away, since the  
outside code is accessing the field, and any static field access requires a  
clinit (which the compiler doesn't forget before this patch).



--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth 
Gerrit-Reviewer: Colin Alworth 
Gerrit-Reviewer: John A. Tamplin 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-HasComments: Yes

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 2:

(1 comment)


File dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
Line 172:   if (program.isStaticImpl(x.getTarget())  
&& !program.isJavaScriptObject(x.getTarget().getEnclosingType())) {
The extra condition (both here and in GenerateJavaScriptAST) deals with the  
fact that MakeCallsStatic registers instance methods as static with  
JProgram, while JsoDevirtualizer does not. This seems reasonable at first,  
though since JSOs are *always* made static, there might be other  
implications. I suggested this in my first comment in this change request,  
but John seemed to think that this approach made more sense. That said, I  
haven't actually tried making that change, and seeing what else is affected  
(i.e. all other callsites of JProgram.isStaticImpl or .getStaticImpl).



--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth 
Gerrit-Reviewer: Colin Alworth 
Gerrit-Reviewer: John A. Tamplin 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-HasComments: Yes

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add interfaces for widgets.
..


Patch Set 8:

What is the thinking for the remaining 10%-ish of widgets - all of the cell  
widgets (except CellPanel), remaining *boxes (DateBox, various number-Box),  
RichTextArea, missing *LayoutPanels (SplitLayoutPanel, LayoutPanel,  
HeaderPanel, DeckLayoutPanel), etc? Future patch, or less important? I  
could see skipping most of the boxes, since the api should be relatively  
similar since subclasses mostly modify internal behavior, but then you have  
IsNumberLabel which just makes the generics more explicit (and should  
almost certainly be extending IsValueLabel to get those other  
super-interfaces...). Then there are the layout panels which arguably look  
like HasWidgets.ForIsWidget, but if IsElement gets so specific as to allow  
direct dom manipulation, it seems reasonable to allow layout manipulation  
as well.


AbstractHasData and subclasses (lots of cell widgets) is a nice abstract  
class which already has most -- but not all -- methods declared in various  
interfaces.


Unless we're waiting for a future patch to finish the job, I'm not yet  
understanding the approach in which classes get selected for this treatment  
and which types/methods get a pass. I don't mean for this to stand in the  
way of this patch, but to suggest that the strategy is sufficiently unclear  
that we could probably use a gwt-site doc on this or a body of javadoc that  
covers how these are intended to be used, and how widget  
authors/maintainers should behave to make their code usable by downstream  
users who like these interfaces for testing.


--
To view, visit https://gwt-review.googlesource.com/3231
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 8
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Colin Alworth 
Gerrit-Reviewer: Daniel Kurka 
Gerrit-Reviewer: Goktug Gokdogan 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Stephen Haberman 
Gerrit-Reviewer: Thomas Broyer 
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Nextgen GWT/JS Interop (Public) (google-web-tool...@googlegroups.com)

[Colin Alworth]

Nice writeup. Comments/questions (since comments seem disabled in the docs):

 * @Entry looks great - there has been some discussion in IRC about some 
way to do this for easier library wrapping code, but every direction we 
looked at with JSOs ended up with a little more cruft than we really wanted 
to see. Maybe worth mentioning that $entry doesn't just do exceptions, but 
also makes scheduleFinally behave as expected.
 * Constructors - how is one supposed to new up an object that implements a 
specific interface without making your own implementation (and thus 
declaring new implementations)? Are we keeping the static-method-only 
restriction, or can we use new? Similarly, how will these objects pass 
through the java/js barrier - are they to be a special class of objects in 
JSNI, allowed to be manipulated in plain JS instead of opaque objects, but 
still able to be instanceof'd?
 * Java 8 support/requirement - currently the GWT release jars are compiled 
to target java 6 (according to common.ant.xml), so that they can be used in 
a project that supports either 6 *or* 7 (and of course newer). If this new 
code is used at all internally with java8-only features, does this mean 
that support will be *dropped* for both 6 and 7 instead of merely *adding* 
java 8 support?
 * (JSNI doc) primitives - why support for long, which JS VMs don't 
actually support, but not float/short/byte?
 * (JSNI doc) forEach - will there be a function/callback interface that 
will be autowrapped in $entry and bind to be passed in, or will this simply 
access a JSO that will be treated as a function?


On Tuesday, August 6, 2013 2:24:47 AM UTC-5, Goktug Gokdogan wrote:
>
> I've shared an item with you.
>
> This is a design doc that describes a proposal for improving interoperability 
> with GWT and javascript. The proposal provides some essential pieces to 
> provide better and easier interoperability with JS while putting more complex 
> scenarios (e.g. Web Components) and testability into account.
>
> Please take a look and provide us some feedback.
>
> Cheers,
>
>  - Goktug
>
> [image: Document] Nextgen GWT/JS Interop 
> (Public)
>  
> Google Drive: create, share, and keep all your stuff in one place. [image: 
> Logo for Google Drive] 
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Colin Alworth]

I got a tweet from you asking for a donation (or rather a 'partner', which
apparently means 'money'), but couldn't frame a useful response in 140
chars, so since this thread is coming back, I thought to do so here
instead.

What license are you offering these code samples under - if it isn't
something open and available, what is the benefit to an advance copy of the
jar if I, an author of a library and several open source tools and
applications, cannot provide it to my customers or other downstream users?

We've found that https://gist.github.com/niloc132/3906501 goes a heck of a
long ways toward offering optional debug info - if not enabled, the user
gets the normal-size application with zero size or performance hit, and by
redirecting to a slightly different url, the full trace info can be pulled
out (with the quirks you mention of course*), which typically goes a long
ways toward identifying the real issue.

* How often have you needed to know which line of Impl.java or DOMImpl.java
a stack trace intersects? To make your case more effectively, you might
consider using code where it is meaningful to see those lines, something
other than the equivelent of
java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
JSNI, or an annoying IE6-9 focus() or setAttribute issue?

You touch briefly on the risk of '[exposing] your application’s
implementation details', but unless I am mistaken, the extra metadata
included in the file:line ints should still be enough to take apart an app
and map it to discrete files and reconstruct methods, even un-inlining (as
you mention) to pull out clearer details. My understanding was that the
premise of the sourceMap was to work entirely from the stack to allow the
actual source to be obfuscated, and avoid any other metadata from being
left in the compiled output. Combine this with the fact that many of those
classes are publicly available (GWT itself, etc), and it seems that you
could reverse out a significant portion of the app - the "secret sauce".
Can you comment on using this for public applications and any reverse
engineering attempts you've made?


On Mon, Aug 19, 2013 at 3:06 PM, Alex Epshteyn  wrote:

> Hello folks,
>
> I just wanted to remind everyone that the last day to fund this project is
> this Friday, August 23.
>
> I've been using this framework in production in my app now for 2 months,
> and it works great.  Have logged 70,000 perfect stack traces so far!
>  Already fixed 3 major bugs in my GWT-based UI code that I would NEVER
> found otherwise.
>
> Let's get this capability into GWT by the end of the year.  Please donate!
>
> Thanks,
> Alex
>
>
>
> On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:
>>
>> Dear fellow GWT users,
>>
>> I would like to announce that I have finally solved what I always thought
>> to be GWT's greatest weakness: its lack of debugging information for
>> client-side exceptions in production.
>>
>> With my patch, your deployed app will be able to report stack traces like
>> this:
>>
>> com.google.gwt.core.client.**JavaScriptException: (TypeError) : a is null
>> com.google.gwt.dom.client.**DOMImplMozilla.$**getBodyOffsetLeft(**
>> DOMImplMozilla.java:145)
>> com.google.gwt.user.client.ui.**PopupPanel.$setPopupPosition(**
>> Document.java:1287)
>> com.google.gwt.user.client.ui.**PopupPanel.setPopupPosition(**
>> PopupPanel.java:884)
>> com.google.gwt.user.client.ui.**PopupPanel.PopupPanel(**
>> PopupPanel.java:453)
>> com.typeracer.commons.client.**widgets.EnhancedPopup.**
>> EnhancedPopup(EnhancedPopup.**java:32)
>> com.typeracer.commons.client.**widgets.PopupWithIcon.**PopupWithIcon(**
>> PopupWithFocusableTextBox.**java:28)
>> com.typeracer.main.client.**controller.**TyperacerUncaughtExceptionHand**
>> ler$1.execute(**TyperacerUncaughtExceptionHand**ler.java:55)
>> com.google.gwt.core.client.**impl.SchedulerImpl.**runScheduledTasks(**
>> SchedulerImpl.java:50)
>> etc... :-)
>>
>>
>> instead of the current state of affairs that looks like this:
>>
>> lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:
>> http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**B8.cache.html
>>
>> stack: @http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:2422
>>
>> Rub@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:2423
>>
>> dSb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:3190
>>
>> tA@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:2810
>>
>> Xmb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:2289

[gwt-contrib] Gwt benchmarks without Benchmark

[Colin Alworth]

Shortly after 2.5.1, the Benchmark classes were removed from GWT 
(https://gwt.googlesource.com/gwt/+/39eb6001a037fd8b6580a73a2540e6e9c04e54c2 
and 
https://gwt.googlesource.com/gwt/+/00c7ce43df3a629b7302ab902a07431db7224e2b) 
- what are folks using for low-level performance testing these days?

I'm wrapping up a changeset to emit JS TypedArrays when int[], double[], 
etc are used in code, and while I can see that some projects clearly 
improve with this, others seem to take a hit (specifically in rapidly 
allocating arrays that have a short lifetime). I'd like to record some 
numbers to paint this picture without rolling my own benchmark/gwtPerf 
tool, but I'm not quite clear on the current state of this sort of metrics. 

>From the comment that originally deprecated the Benchmark class:

> This didn't get enough adaption externally or internally. The way it's 
> implemented requires special support from GWTTestCase infrastructure. Also, 
> we are not going have an environment to automate benchmarks written on this 
> any time soon.
>
> If there is enough demand later, parts of this code can be resurrected to 
> build a new benchmark system.
>

Thoughts?
-Colin

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?

[Colin Alworth]

I'd be interested in helping with either approach. The phloc-css project 
looks interesting if we are only trying to add support for newer CSS 
features, while integration with Closure Stylesheets seems geared more 
toward extending the CssResource featureset. Much of the existing 
functionality in GWT's CssResource is also in closure in some capacity, 
though the implementation is likely different enough to cause interesting 
issues. There are advantages to making it through those differences - 
mixins for example.

Another thought would be to implement both - expand CssResource to support 
new properties with phloc-css, and create a new ResourcePrototype 
(StylesheetResource perhaps?) with its own resource generator to put code 
through closure's wringer. 

-Colin

On Monday, August 26, 2013 5:38:45 AM UTC-5, Julien Dramaix wrote:
>
> Hi all,
>
> Just to inform you that I would like to give a try to add support of CSS3 
> in GWT if nobody is working on.
>
> After some research, I found another open source CSS parser in java 
> supporting CSS3 : https://code.google.com/p/phloc-css If we need only a 
> parser it could be a interesting alternative to Closure syle sheet.
>
> What do you think ?
>
> Julien
>
>
> On Thursday, February 2, 2012 9:38:02 AM UTC+1, Thomas Broyer wrote:
>>
>> On Thu, Feb 2, 2012 at 7:05 AM, Ray Cromwell  wrote:
>> > Sorry to hear that. This is actually on our list of priorities for
>> > GWT, so we will have to take this up internally.
>>
>> Just a clarification: I was trying to replace Flute with the parser
>> from Closure Stylesheets, replacing the whole CssResource processing
>> (or creating a GssResource) with one based on Closure Stylesheets
>> should be relatively easy though. For now, my priorities are fixing
>> the remaining RF bugs and hope my half-a-dozen-or-so patches will land
>> in 2.5 (we're helping a company switch to web apps in GWT, and I'd
>> recommend them to use RF over RPC if there wasn't so many pitfalls
>> [1], having the fixes in 2.5 would help make the choice based on the
>> actual features and limitations due to their designs, rather than
>> ditch RF based only on its known bugs [2]). I had very little time
>> these past weeks so I couldn't even try fixing issue 6710 which, to
>> me, is higher priority.
>>
>> So, when I'll have time and have fixed 6710 (the last remaining
>> "blocker" IMO), I'll see if I can help integrating Closure
>> Stylesheets, but I'm afraid not before. Does that sound good to you?
>>
>> [1] That one in particular caught me when upgrading to a "recent
>> trunk" last fall, it's not documented and I can't say if it's a bug or
>> simply a limitation due to batching:
>> http://code.google.com/p/google-web-toolkit/issues/detail?id=7120#c1
>> [2] One such example:
>> http://code.google.com/p/google-web-toolkit/issues/detail?id=7120#c2
>>
>>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?

[Colin Alworth]

I spent an hour or two last night playing with phloc-css, and it doesn't 
seem to be quite as flexible as flute in terms of adding custom behavior 
for unknown @-rules (@def, @sprite, etc), or handling arbitrary (and 
unknown to both flute and phloc-css) functions like literal() and value(). 
I played briefly with modifying the jjt file, but realized that any gain 
made there comes at the cost of re-namespacing and trying to rebase such a 
change along as phloc-css changes. As a drop-in replacement, I'm not seeing 
a good strategy here, though I'm open to suggestions. 

Closure doesn't quite seem a perfect fit either, though perhaps I am 
missing some details about it (I've only gone through the docs at 
http://code.google.com/p/closure-stylesheets/ and the wiki), specifically 
around the @sprite/gwt-image feature in CssResource, but also the other 
Java-specific pieces like @eval to get outside values into the css and @def 
to get inside values back out again. Can anyone comment on those aspects of 
how a GssResource could look?

On Tuesday, August 27, 2013 2:19:39 PM UTC-5, Julien Dramaix wrote:
>
> Thanks all,
>
> I will focus on Closure stylesheets integration and the introduction of a 
> new GssResource
>
> Julien
>
>
> On Tue, Aug 27, 2013 at 5:25 PM, Goktug Gokdogan 
> 
> > wrote:
>
>> What we were planning was to add support for GSS, add the missing 
>> features and then migrate existing users and deprecate the older 
>> eventually. This would decrease the maintenance cost a lot in the long term.
>> We really want to see GSS support for GWT in the long term. On top of 
>> additional features, there are other benefits with moving to GSS; Google is 
>> committed to maintain GSS and support it in the long term, we can get 
>> direct support from the authors as they are close to us. One other major 
>> advantage more specific to us is, we can reuse tons of already available 
>> GSS resources. For that reason, we would love to see you moving in this 
>> route and will definitely help you along the way, and also provide you 
>> additional contact points from the team for support.
>>
>>
>>
>> On Tue, Aug 27, 2013 at 3:24 AM, Thomas Broyer 
>> 
>> > wrote:
>>
>>>
>>>
>>> On Tuesday, August 27, 2013 1:42:35 AM UTC+2, Colin Alworth wrote:
>>>>
>>>> I'd be interested in helping with either approach. The phloc-css 
>>>> project looks interesting if we are only trying to add support for newer 
>>>> CSS features, while integration with Closure Stylesheets seems geared more 
>>>> toward extending the CssResource featureset. Much of the existing 
>>>> functionality in GWT's CssResource is also in closure in some capacity, 
>>>> though the implementation is likely different enough to cause interesting 
>>>> issues. There are advantages to making it through those differences - 
>>>> mixins for example.
>>>>
>>>> Another thought would be to implement both - expand CssResource to 
>>>> support new properties with phloc-css, and create a new ResourcePrototype 
>>>> (StylesheetResource perhaps?) with its own resource generator to put code 
>>>> through closure's wringer.
>>>>
>>>
>>> +1 to that (obviously, as I think that's what I was proposing) 
>>>
>>> -- 
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>> --- 
>>> 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
>>> .
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  -- 
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "GWT Contributors" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/google-web-toolkit-contributors/e0qUfkqBSog/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> google-web-toolkit-contributors+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] gwt.junit.testcase.includes broken?

[Colin Alworth]

When I run that command it doesn't run all of the tests, but it does run
*other* tests. The parameter used specifies which gwt tests to run, but
there is also a batch of non-gwt tests (i.e. traditional JUnit test cases)
that get kicked off as part of the 'test' target.

One option is to specify *exactly* which kind of test you want to run
(dev/emma/draft/web/nometa, htmlunit/remote/selenium, plus nongwt and
coverage) like this, reusing the other args you specified:
ant -Demma.enabled=false '-Dgwt.junit.testcase.includes=**/I18NSuite.class'
*test.draft.htmlunit*

There is also a target that grabs up all of the test.*.htmlunit targets:
ant -Demma.enabled=false '-Dgwt.junit.testcase.includes=**/I18NSuite.class'
*test.htmlunit*

as well as several others that work in much the same way (test.dev,
test.web, test.emma, test.draft, test.nometa).

The other is to turn off the nongwt tests using the
-Dtest.nongwt.disable=true flag:
ant -Demma.enabled=false '-Dgwt.junit.testcase.includes=**/I18NSuite.class'
*-Dtest.nongwt.disable=true* test

You may also want to turn off the coverage test, since that explicitly runs
its own test case:
  
   wrote:

> Hi, my guess is that it's just an oversight; at Google we have our own
> build stystem so we don't use the ant scripts all that often. If you want
> to dive in, I'd be interested in what you find.
>
> - Brian
>
>
> On Sat, Aug 31, 2013 at 2:33 PM, Daniel Trebbien wrote:
>
>> Hi,
>>
>> I am trying to run only the I18NSuite tests in
>> user/test/com/google/gwt/i18n/I18NSuite.java but I am finding
>> that gwt.junit.testcase.includes is no longer working.
>>
>> This used to work:
>>
>> ant -Demma.enabled=false
>> '-Dgwt.junit.testcase.includes=**/I18NSuite.class' test
>>
>>
>> but now this runs all of the tests instead of just the tests in I18NSuite.
>>
>> I also tried adapting the command line mentioned in the thread How to
>> run a single test 
>> ?,
>> but all of the tests for the user subproject are still run.
>>
>> Was support for gwt.junit.testcase.includes removed?
>>
>> Daniel
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
218.248.6165
niloc...@gmail.com

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Making user.agent easier to extend to add new permutations

[Colin Alworth]

I've got to second Thomas on this point - adding a new user.agent is very
non-trivial at least without an overhaul of CssResource generation. In GXT
3 we took the route of providing our own PropertyProviderGenerator and
adding a few new user agents (ie7, ie10 for a start), but quickly found
that doing this broke internals of a variety of GWT widgets. The fallback
attribute let ie7 behave as ie6 (and ie10 as ie9) if a replace-with rule
set did not define specific behavior for it, but the CssResource generation
process creates types based on all properties available, not just the
properties that the CSS file was written to expect. This means that if you
have

@if user.agent ie6 ie8 {
  //...
}

then the enclosed content will only be in the _ie6 and _ie8 generated
classes, not _ie9 (good), _ie10 (good), or ie7 (bad). Without a fallback
mechanism that makes sense in CssResource, any existing GWT widget that
uses ClientBundle may be unusable in a project that builds its own user
agents.

This is the only case we ran into before we decided it wasn't worth it -
GXT 3 can and should run along side or in conjunction with standard GWT
widgets, so this was a deal-breaker right off the bat.


On Wed, Sep 11, 2013 at 4:40 AM, Thomas Broyer  wrote:

>
> On Wednesday, September 11, 2013 3:10:56 AM UTC+2, Goktug Gokdogan wrote:
>>
>> I recently noticed that developers are forking c.g.gwt.useragent in order
>> to be able to add new browser permutations to existing ones. This is
>> suboptimal and causes code duplication and possibly trying keep it in sync
>> with the original during updates.
>> The root cause of this is the determination of user.agent during runtime
>> is statically defined in this package. I created a patch so that code
>> snippets to extract user agent can be defined and injected from outside so
>> that new permutations can be added externally without forking the original
>> package.
>>
>> If you hit this issue before, please take a look at https://gwt-review.**
>> googlesource.com/4500  and see
>> if would make your life easier.
>>
>
> Not opposed to it in principle, but adding a new user.agent is not an easy
> task, and more often than not people actually want to add a new property to
> be used in conjunction to user.agent in deferred-binding rules (e.g.
> https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion);
> so I'm not sure this is the right move, as it makes it easier to do things
> the wrong way.
>
> As a side note, I think we should add a way to "alias" property values so
> we can progressively rename "gecko1_8" to "gecko" and possibly "safari" to
> "webkit" [1] without breaking anyone. I think this can be "faked" today
> using fallback-value and excluding the fallback value from the possible
> values (i.e.  fallback-value="gecko1_8"/> value="ie6,ie8,ie9,gecko,safari,opera"/> notice the absence of "gecko1_8"
> here but thanks to the fallback-value,  value="gecko1_8"/> should continue to work and match the "gecko"
> permutation) but we cannot  the user.agent property in GWT
> proper as it would break those who new values and expect the set of
> "possible values" to automatically grow with their new value.
>
> [1] Daniel thinks we should add a "chromium" permutation –he said "blink",
> but I believe "chromium" would be a better name: it's not only about the
> rendering engine, but also the JS engine–, I know "webkit" can be used with
> other JS engines than JavaScriptCore but I'm unsure anyone would do it
> nowadays, and "webkit" probably still better matches reality than "safari".
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
218.248.6165
niloc...@gmail.com

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Possible firefox leak fix

[Colin Alworth]

at change to hosted.html (or a copy in my project's public/ dir) and 
the attached patch, the leak seems to be resolved. Questions I have:
 * How does one perform the complete plugin build process? How far back in 
time do we rebuild and test?
 * How many auto-generated files (mostly .h from the idl, but also the 
.dll/.dylib/etc) do we commit when such a change is made?
 * Apparently plugins don't need to provide a disconnect() method, but if 
any do, are we *sure* they are actually being called as expected? Or is 
onUnload a long-lived typo?

Looking forward to discussing this here, in ##gwt on freenode, or on the 
call tomorrow,
Colin

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.
commit 6969765b5b60731f12ce529bbc6f730922b7e817
Author: Colin Alworth 
Date:   Tue Sep 24 18:29:13 2013 -0500

Initial work on supporting a disconnect message from the browser to close off the connection to the code server

diff --git a/xpcom/ExternalWrapper.cpp b/xpcom/ExternalWrapper.cpp
index ab0423e..f4d61cb 100644
--- a/xpcom/ExternalWrapper.cpp
+++ b/xpcom/ExternalWrapper.cpp
@@ -399,6 +399,13 @@ NS_IMETHODIMP ExternalWrapper::Connect(const nsACString& suppliedUrl,
   return NS_OK;
 }
 
+NS_IMETHODIMP ExternalWrapper::Disconnect() {
+  Debug::log(Debug::Info) << "Disconnecting..." << Debug::flush;
+  sessionHandler.get()->disconnect();
+  Debug::log(Debug::Info) << "...Disconnected" << Debug::flush;
+  return NS_OK;
+}
+
 // nsISecurityCheckedComponent
 static char* cloneAllAccess() {
   static const char allAccess[] = "allAccess";
@@ -422,7 +429,7 @@ NS_IMETHODIMP ExternalWrapper::CanCreateWrapper(const nsIID * iid,
 NS_IMETHODIMP ExternalWrapper::CanCallMethod(const nsIID * iid,
 const PRUnichar *methodName, char **_retval) {
   Debug::log(Debug::Spam) << "ExternalWrapper::CanCallMethod" << Debug::flush;
-  if (strEquals(methodName, "connect") || strEquals(methodName, "init")) {
+  if (strEquals(methodName, "connect") || strEquals(methodName, "init") || strEquals(methodName, "disconnect")) {
 *_retval = cloneAllAccess();
   } else {
 *_retval = nullptr;
diff --git a/xpcom/IOOPHM.idl b/xpcom/IOOPHM.idl
index 1aeea54..14e4d6f 100644
--- a/xpcom/IOOPHM.idl
+++ b/xpcom/IOOPHM.idl
@@ -8,4 +8,5 @@ interface IOOPHM : nsISupports
   boolean init(in nsIDOMWindow window);
   boolean connect(in ACString url, in ACString sessionKey, in ACString addr,
   in ACString moduleName, in ACString hostedHtmlVersion);
+  void disconnect();
 };

Re: [gwt-contrib] Possible firefox leak fix

[Colin Alworth]

The patch I provided only tweaks the normal source, and leaves the 
generated sources and binaries alone - I think that is already what you are 
after. 

Note that this does *not* stop the leak by itself - we need to decide what 
to do about hosted.html/devmode.js. One (ugly) option is to try to have the 
ff plugin add an event handler to the window's close to call back to its 
own disconnect? I think there are other ways we could think about doing 
this as well, but changing hosted.html keeps it consistent across the board.

On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:
>
> Hi,
>
> Wow, thanks for tracking this down! Could you send a patch that just 
> modifies the source (not worrying about the autogenerated files)? I will 
> rebuild them when I do the next release.
>
> Usually I just leave the existing dll's alone and move forward; it's not 
> worth fixing older plugins. However, I believe Firefox 24 will be an ESR 
> release so I think it's worth rebuilding that version.
>
>
>
> On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth 
> > wrote:
>
>> I spent a little time this weekend learning how to build firefox plugins, 
>> and a little time spilled out into this week, but I think I'm at a point 
>> where I can share what I've done, what I'm seeing, and start asking for 
>> help to finalize this (if it is as meaningful as I hope it is).
>>
>> First, the issue itself: It looks like we're actually leaking on both 
>> ends - that is, not just in the JVM, but in the browser itself. When Dev 
>> Mode transfers control back to the browser itself, it runs 
>> BrowserChannelServer.reactToMessages(). This listens at the open socket 
>> between the browser's plugin and itself, and waits for the next byte to 
>> float over the wire, meaning that the browser wants something. This waiting 
>> specifically happens in Message.readMessageType, where we block on 
>> stream.readByte(). Once a tab/window has been closed, the thread that is 
>> actively watching that connection stays stuck in readByte(), waiting for 
>> that next message to float over the wire.
>>
>> My first thought was "why can't we just ask if that socket is closed?" - 
>> well, the socket *isn't* closed, which means that the browser is leaking 
>> the socket itself, along with whatever supporting objects were set up to 
>> manage that socket. Note that this suggests a workaround to the leak - quit 
>> and relaunch firefox, and since the socket will be forcibly closed then, 
>> readByte() will throw a EOF exception, and reactToMessages will trip off a 
>> RemoteDeathError (not ideal, but at least it just logs it and moves on, 
>> finishing the leak off).
>>
>> Next I dug into how to make the plugin actually disconnect when the page 
>> was closed. I started this by finding exactly where the socket was opened 
>> (common/HostChannel.{h|cpp}), then what creates HostChannel objects in the 
>> firefox plugin. This turns out to be achieved in this line in 
>> xpcom/ExternalWrapper.cpp (plus instructive comments):
>>   // TODO(jat): leaks HostChannel -- need to save it in a session object 
>> and
>>   // return that so the host page can call a disconnect method on it at 
>> unload
>>   // time or when it gets GC'd.
>>   HostChannel* channel = new HostChannel();
>>
>> Okay, so at the time it was written, it was known that this leaks the 
>> channel. This is where I started losing confidence, as it doesnt look like 
>> it could be this easy... The next block actually opens the connection, and 
>> passes it off to a FFSessionHandler instance, which is stored away in a 
>> field:
>>   Debug::log(Debug::Debugging) << "Connecting..." << Debug::flush;
>>
>>   if (!channel->connectToHost(hostPart.c_str(),
>>   atoi(portPart.c_str( {
>> *_retval = false;
>> return NS_OK;
>>   }
>>
>>   Debug::log(Debug::Debugging) << "...Connected" << Debug::flush;
>>   sessionHandler.reset(new FFSessionHandler(channel/*, ctx*/));
>>
>> All this code is part of ExternalWrapper::Connect (note, defined twice 
>> for varying ff versions), and since Connect is never invoked internally, it 
>> was my assumption that I could build a ExternalWrapper::Disconnect that 
>> simply unwound this channel:
>>
>> NS_IMETHODIMP ExternalWrapper::Disconnect() {
>>   Debug::log(Debug::Info) << "Disconnecting..." << Debug::flush;
>>   sessionHandler.get()->disconnect();
>>   Debug::log(Debug::Info) << "

Re: [gwt-contrib] Possible firefox leak fix

[Colin Alworth]

Done, change is at https://gwt-review.googlesource.com/4680.

Concern about breaking WindowImpl#initWindowCloseHandler was my guess as 
well - after connect() is called and the app starts up, the app has already 
wired up its own close handler, so it is too late when connect is 
successful to replace unload. 

Both the standard WindowImpl and the IE specific one replace onunload and 
call the old version, so provided those stay consistent with 
hosted.html/devmode.js, this approach should be okay...

I'd love to get any independent verification on this as even being a viable 
fix - I've only tried it in FF24/mac so far.

-Colin

On Tuesday, September 24, 2013 8:02:54 PM UTC-5, Brian Slesinsky wrote:
>
> +cromwellian since he did unload support.
>
> Oops, I see now that you attached it. Could you upload it to Gerrit?
>
> I looked pretty hard for a reason why it's window.onUnload and not 
> window.onload and I can't find any. It dates back to 2010 at least and was 
> copied from hosted.html, whether deliberately I don't know.
>
> One issue is that it's possible the app itself might want an onunload 
> handler. See 
> user/src/com/google/gwt/user/client/impl/WindowImpl.java line 32 where it 
> can install an onunload handler. It does preserve the old one but it still 
> seems kind of fragile to install one in the devmode.js. I wonder if there's 
> some way to detect the unload event in C++?
>
> - Brian
>
>
>
> On Tue, Sep 24, 2013 at 5:25 PM, Colin Alworth 
> > wrote:
>
>> The patch I provided only tweaks the normal source, and leaves the 
>> generated sources and binaries alone - I think that is already what you are 
>> after. 
>>
>> Note that this does *not* stop the leak by itself - we need to decide 
>> what to do about hosted.html/devmode.js. One (ugly) option is to try to 
>> have the ff plugin add an event handler to the window's close to call back 
>> to its own disconnect? I think there are other ways we could think about 
>> doing this as well, but changing hosted.html keeps it consistent across the 
>> board.
>>
>>
>> On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:
>>
>>> Hi,
>>>
>>> Wow, thanks for tracking this down! Could you send a patch that just 
>>> modifies the source (not worrying about the autogenerated files)? I will 
>>> rebuild them when I do the next release.
>>>
>>> Usually I just leave the existing dll's alone and move forward; it's not 
>>> worth fixing older plugins. However, I believe Firefox 24 will be an ESR 
>>> release so I think it's worth rebuilding that version.
>>>
>>>
>>>
>>> On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth wrote:
>>>
>>>> I spent a little time this weekend learning how to build firefox 
>>>> plugins, and a little time spilled out into this week, but I think I'm at 
>>>> a 
>>>> point where I can share what I've done, what I'm seeing, and start asking 
>>>> for help to finalize this (if it is as meaningful as I hope it is).
>>>>
>>>> First, the issue itself: It looks like we're actually leaking on both 
>>>> ends - that is, not just in the JVM, but in the browser itself. When Dev 
>>>> Mode transfers control back to the browser itself, it runs 
>>>> BrowserChannelServer.**reactToMessages(). This listens at the open 
>>>> socket between the browser's plugin and itself, and waits for the next 
>>>> byte 
>>>> to float over the wire, meaning that the browser wants something. This 
>>>> waiting specifically happens in Message.readMessageType, where we block on 
>>>> stream.readByte(). Once a tab/window has been closed, the thread that is 
>>>> actively watching that connection stays stuck in readByte(), waiting for 
>>>> that next message to float over the wire.
>>>>
>>>> My first thought was "why can't we just ask if that socket is closed?" 
>>>> - well, the socket *isn't* closed, which means that the browser is leaking 
>>>> the socket itself, along with whatever supporting objects were set up to 
>>>> manage that socket. Note that this suggests a workaround to the leak - 
>>>> quit 
>>>> and relaunch firefox, and since the socket will be forcibly closed then, 
>>>> readByte() will throw a EOF exception, and reactToMessages will trip off a 
>>>> RemoteDeathError (not ideal, but at least it just logs it and moves on, 
>>>> finishing the l

Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?

[Colin Alworth]

Its never too late - I don't know how far Julien has gotten, but I've been 
distracted by other work, as well as trying to nail down conceptually where 
GSS meets ClientBundle.

For my part, SASS or LESS are a major step down from what we already have - 
the purpose of GWT in general is to let you write maintainable code that 
compiles to well-performing code, but not expose features that will perform 
badly (consider the lack of java.text, reflection support). The scoping 
feature that sass/less/compass has (allowing you to nest rules within other 
rules) makes for much longer selectors in the compiled out code, which 
equates pretty directly to worse performance (longer selectors take longer 
to find/track what they apply to). In contrast, Closure Stylesheets gives 
us the same sorts of variables, mixins, and @if syntax, but puts as much of 
this work on the compiler rather than adding more classes at runtime. It is 
a little more limited (and I'm not sure how we can even achieve things such 
as @def and @eval... which current CssResource has), but those limitations 
seem designed to provide better runtime performance.

On a different note, less/sass are implemented in Ruby, not Java, so either 
they must be made to work in JRuby or we'd need to require an existing Ruby 
installation.

OOCSS could be worth looking at - I don't know anything about it yet but 
would be interested in learning. At a glance, it *appears* to be more of a 
philosophy about writing html/css and a single set of starting structural 
css, rather than a more 'useful' css language - do I have it right?

Also, just as GssResource can be added as a new ResourcePrototype type, you 
could just as easily create a LessResource or OocssResource with its own 
generator to perform the required transformations.

I hang out in ##gwt on freenode, and would love to talk more about this 
whole task with anyone who is interested, otherwise i'd be open for a 
hangout to chat too.

On Wednesday, September 25, 2013 2:24:06 AM UTC-5, Samuel Schmid wrote:
>
> I'm a little bit late in this discoussion, i see there is a lot of work 
> already on going.
> But +1 for this.
> SASS or LESS would be a big plus.
> For me I think supporting OOCSS is more important than supporting CSS3 
> without workarounds.
>
> Thank you guys!
> Sam
>
>
> On Friday, December 16, 2011 11:51:43 PM UTC+1, Michael Vogt wrote:
>>
>> Hello.
>>
>> > How could I refuse?  :) SGTM. We will of course, still have to
>> > maintain all of the GWT-isms. Actually, I've been wondering if we
>> > shoudn't just adopt LESS or SASS extensions too.
>> >
>> Yes, please.
>>
>>
>> Greetings,
>> Michael
>>
>>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Build failures after deprecated tree/treeitem methods removed

[Colin Alworth]

It looks like a recent commit that removed some deprecated methods may not 
have gone far enough, as there is still code that makes use of those 
methods - the 
https://gwt.googlesource.com/gwt/+/f9630059081921b195ee4f7014e1a78c4b570f79 
commit dropped several methods from Tree and TreeItem, but the 'json' 
sample used those methods, so our nightly builds are seeing failures.

Source file that continues to use removed addItem methods:
https://gwt.googlesource.com/gwt/+/master/samples/json/src/com/google/gwt/sample/json/client/JSON.java

Build log errors:
compile:
[mkdir] Created dir: 
/Users/colin/Documents/idea/gwt/build/out/samples/JSON/war/WEB-INF/classes
[gwt.javac] Compiling 1 source file to 
/Users/colin/Documents/idea/gwt/build/out/samples/JSON/war/WEB-INF/classes
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:132:
 
error: no suitable method found for addItem(String)
[gwt.javac] TreeItem child = treeItem.addItem(getChildText("["
[gwt.javac]  ^
[gwt.javac] method TreeItem.addItem(Widget) is not applicable
[gwt.javac]   (actual argument String cannot be converted to Widget by 
method invocation conversion)
[gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to IsTreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(TreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to TreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable
[gwt.javac]   (actual argument String cannot be converted to SafeHtml 
by method invocation conversion)
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:139:
 
error: no suitable method found for addItem(String)
[gwt.javac] TreeItem child = treeItem.addItem(getChildText(key));
[gwt.javac]  ^
[gwt.javac] method TreeItem.addItem(Widget) is not applicable
[gwt.javac]   (actual argument String cannot be converted to Widget by 
method invocation conversion)
[gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to IsTreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(TreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to TreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable
[gwt.javac]   (actual argument String cannot be converted to SafeHtml 
by method invocation conversion)
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:144:
 
error: no suitable method found for addItem(String)
[gwt.javac]   treeItem.addItem(jsonString.stringValue());
[gwt.javac]   ^
[gwt.javac] method TreeItem.addItem(Widget) is not applicable
[gwt.javac]   (actual argument String cannot be converted to Widget by 
method invocation conversion)
[gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to IsTreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(TreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to TreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable
[gwt.javac]   (actual argument String cannot be converted to SafeHtml 
by method invocation conversion)
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:147:
 
error: no suitable method found for addItem(String)
[gwt.javac]   treeItem.addItem(getChildText(jsonValue.toString()));
[gwt.javac]   ^
[gwt.javac] method TreeItem.addItem(Widget) is not applicable
[gwt.javac]   (actual argument String cannot be converted to Widget by 
method invocation conversion)
[gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to IsTreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(TreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to TreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable
[gwt.javac]   (actual argument String cannot be converted to SafeHtml 
by method invocation conversion)
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:154:
 
error: no suitable method found for addItem(String)
[gwt.javac] TreeItem treeItem = jsonTree.addItem(errorType);
[gwt.javac] ^
[gwt.javac] method Tree.addI

[gwt-contrib] gwtproject.org javadoc missing files

[Colin Alworth]

According to the the gwt-site git repo (at 
https://gwt.googlesource.com/gwt-site/+/master/src/main/site/javadoc/latest), 
the package-list file is present, but it can't be downloaded from 
http://www.gwtproject.org/javadoc/latest/package-list. It *is* still 
available from 
http://google-web-toolkit.googlecode.com/svn/javadoc/latest/package-list.

This file is useful for projects that are building javadoc that should link 
up to GWT itself - without it, the javadoc tool apparently doesn't link to 
referenced classes in GWT.

I'm not seeing anything useful in terms of a web.xml file or a 
servlet/filter/htaccess that can be customized to correct for this in the 
git repo, so I'm assuming that this is a server configuration change that 
needs to be made. Can someone confirm that, or point me in the right 
direction for a change I can make as a contributor?

Thanks,
Colin

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Non-client apis and breaking changes

[Colin Alworth]

Just wandered by https://gwt-review.googlesource.com/#/c/1040/ and noticed 
that with this change, any downstream generator/linker using the static 
helper methods in Name will no longer build across 2.5.1 to 2.6.0. With the 
other discussions going on about JRE and browser support, perhaps we could 
discuss something policy-like around 'internal' code like this? 

If the policy that internal public methods are not actually for public 
consumption, or subject to breakage across minor releases, we should note 
that somewhere to keep people away. My inclination is that we want to 
encourage downstream code to use utility methods like this rather than 
copying them into their own projects.

And again on the side of discouraging use of code like this, how far and 
wide can public code be expected to be 'usable by downstream'? The 
com.google.gwt.editor.rebind.model.ModelUtils class is very handy for 
getting specifics about generic types, but from its package it is clearly 
part of editor so could change with modifications to that framework, 
whereas Name and StringKey seem to be in the relatively 'safe' package of 
com.google.gwt.dev.util with other benign classes like Util.

Thoughts?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Bad news for GWT DevMode!

[Colin Alworth]

I end up debugging IE in dev mode on a regular basis as well, though in a
VM, through to my host OS's Eclipse or IntelliJ debugger. It is
significantly slower than running the IDE and browser on the same OS, but
it does let you set up your env once and debug multiple OSes whenever you
like.




On Mon, Oct 21, 2013 at 8:56 AM, Thomas Broyer  wrote:

> I don't think any committer to the GWT project uses Windows (other than
> for testing, using VMs then), so it'd be either Firefox or Chrome (no other
> choice on Linux; and on OSX, Safari is no longer supported started with
> 5.1, and I don't think anyone uses OmniWeb or similar).
> Both work well.
>
> To answer the question about a “preferred browser”, I've been told that,
> on Windows, IE works best (is the fastest); that was a while back though,
> so things might have changed.
>
>
> On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote:
>>
>> IMO Firefox
>>
>> On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote:
>>>
>>> Just curious, is there a preferred browser for Classic DevMode?
>>>
>>> What do the cool kids use? :)
>>>
>>> On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote:

 Just saw this passing on Twitter: http://blog.chromium.**
 org/2013/09/saying-goodbye-to-**our-old-friend-npapi.html
 This is really bad for DevMode in Chrome (maybe also in Firefox, which
 was already a nightmare). Means we really need to improve SuperDevMode, or
 find a non-NPAPI way to plug into the browser.

>>>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
218.248.6165
niloc...@gmail.com

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Reminder: GWT 2.6 feature complete is Nov 4

[Colin Alworth]

Patrick, looking at these, only two appear to have code reviews, and both 
are in the pre-git system. Gerrit, the current system, needs a CLA before 
it allows changes, to make sure that there are no copyright/licensing 
issues with contributions, and makes history/change management a little 
easier. Can you migrate those to Gerrit so they can be reviewed and merged? 
Link back to the original so any discussion there can be read and taken 
into account by future reviewers.

On Friday, October 18, 2013 7:18:40 AM UTC-5, Patrick Tucker wrote:
>
> I really would like to see some of these make the cut.  Most of the which 
> are trivial fixes, some have patches proposed.
>  
> title set on parent TreeItem appears also on its children
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=1393
>
> HeaderPanel setHeaderWidget is broken
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=7037
>
> BorderStyle enum is missing values
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=8071
>
> Inconsistent TextArea border-top style
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=8176
>
> Vertical MenuBar popup is always left aligned even if there is not enough 
> right-space to do so.
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=3888
>
> Add max-height and max-width support to Style
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=7905
>
>  
>  
> I don't necessarily care about this one but it is just a documentation 
> fix...
>  
> Documentation for TabBar doesn't list gwt-TabBarItem-disabled
>
> *http://code.google.com/p/google-web-toolkit/issues/detail?id=4050*
>
>  
>  
>  
>  
>  
>
> On Thursday, October 17, 2013 1:22:56 PM UTC-4, Matthew Dempsky wrote:
>
>> Hi all,
>>
>> Just writing to remind everyone that the GWT 2.6 feature complete 
>> deadline is November 4th.  On that day I'll fork the GWT 2.6 release 
>> branch, and I'll only approve patches for release critical bug fixes.
>>
>> The GWT 2.6 Release 
>> Plan
>>  contains 
>> the handful of outstanding issues that I know we still want to get in for 
>> 2.6, and I'll be following up with people to try to make sure they're 
>> merged in time.  If there are other features you think should be included 
>> but aren't listed, please speak up now so I can add them and track their 
>> progress.
>>
>> Thanks
>>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Where is gwt-customchecks.jar?

[Colin Alworth]

Tentative patch up at https://gwt-review.googlesource.com/5063 - can 
someone sanity check it for me? It looks like step 4 (now step 3) should 
have previously been pointing to step 3 (now step 2), so is now more 
correct.

On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote:
>
> Thanks Thomas. I think it should be removed from eclipse/README.txt. 
>
> - Andrés Testi
>
> El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió:
>>
>>
>> On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote:
>>>
>>> Where is the gwt-customchecks.jar file referred in eclipse/README.txt? 
>>> Is it no longer required to configure codecheck?
>>> Thanks in advance.
>>>
>>
>> It's gone, and no longer required.
>> See https://gwt-review.googlesource.com/1051
>>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Where is gwt-customchecks.jar?

[Colin Alworth]

If only *all* of my changes were that easy to make...

On Tuesday, October 22, 2013 8:15:12 AM UTC-5, Andrés Testi wrote:
>
> Thanks Colin! I'm glad to see the power of the community in action :-)
>
> - Andrés Testi
>
> El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió:
>>
>> Tentative patch up at https://gwt-review.googlesource.com/5063 - can 
>> someone sanity check it for me? It looks like step 4 (now step 3) should 
>> have previously been pointing to step 3 (now step 2), so is now more 
>> correct.
>>
>> On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote:
>>>
>>> Thanks Thomas. I think it should be removed from eclipse/README.txt. 
>>>
>>> - Andrés Testi
>>>
>>> El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió:
>>>>
>>>>
>>>> On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote:
>>>>>
>>>>> Where is the gwt-customchecks.jar file referred in eclipse/README.txt? 
>>>>> Is it no longer required to configure codecheck?
>>>>> Thanks in advance.
>>>>>
>>>>
>>>> It's gone, and no longer required.
>>>> See https://gwt-review.googlesource.com/1051
>>>>
>>>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Bad news for GWT DevMode!

[Colin Alworth]

Amazingly, it still works great in the IE11 preview too! Only gotcha is 
that the missing plugin page thinks you are running firefox, so you need to 
manually grab the right copy of the IE plugin.

On Tuesday, October 22, 2013 12:58:57 PM UTC-5, Brian Slesinsky wrote:
>
> I expect that by next summer devmode will *only* work in IE and perhaps an 
> older version of Firefox. Oddly enough, the IE plugin has apparently worked 
> for years with no complaints. (But the issue is that nobody currently on 
> the team has ever built it.)
>
> - Brian
>
> On Mon, Oct 21, 2013 at 6:56 AM, Thomas Broyer 
> > wrote:
>
>> I don't think any committer to the GWT project uses Windows (other than 
>> for testing, using VMs then), so it'd be either Firefox or Chrome (no other 
>> choice on Linux; and on OSX, Safari is no longer supported started with 
>> 5.1, and I don't think anyone uses OmniWeb or similar).
>> Both work well.
>>
>> To answer the question about a “preferred browser”, I've been told that, 
>> on Windows, IE works best (is the fastest); that was a while back though, 
>> so things might have changed.
>>
>>
>> On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote:
>>>
>>> IMO Firefox
>>>
>>> On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote:

 Just curious, is there a preferred browser for Classic DevMode?

 What do the cool kids use? :)

 On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote:
>
> Just saw this passing on Twitter: http://blog.chromium.**
> org/2013/09/saying-goodbye-to-**our-old-friend-npapi.html
> This is really bad for DevMode in Chrome (maybe also in Firefox, which 
> was already a nightmare). Means we really need to improve SuperDevMode, 
> or 
> find a non-NPAPI way to plug into the browser.
>
  -- 
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> --- 
>> 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
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/groups/opt_out.