[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.

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 
>>>>this time to update the DevMode server to Jakarta, though that w

[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'd appreciate another look.
>>>>- The

[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 releases after 2.12 eventually ships.
>>
>> Are there

[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: 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] 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] 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: 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 

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 languishing for years, and IE 8, 9, a

[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 

[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] 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.

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_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.
>>
> To view this discussion on the web visit 
>> https:/

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]

e 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://repo.vertispan.com/gwt-groupid-migration-test/, and the only GWT 
>> version that exists there is "2.10.0-new-groupid-2".
>>
>> Based on earlie

[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.

[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] 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] 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.

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.

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 

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 in that area.
>>

[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]

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] 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] 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=MXVmcmw1czU5cHMxYm5lcHEzZWQ0MjR2ODUgY29saW5AdmVydGlzcGFuLmNvbQ=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_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] 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.

[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 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.

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" working 
> with both JDK 8 

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

[Colin Alworth]

eans 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 build glue like we 
>>>> did for Java7 vs Java8. The firs

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 filters, only actually produce javadoc on 
>> java9+ builds
>> 
>

[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] 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.

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] 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_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_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.

[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.

[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.

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_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.

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_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]

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_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: 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 Project or refs, we only call ZipScanner methods directly), 
> >

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's internals to use the new behavior 
>>

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: 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/defineProperty.
>>>> 
>&

[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.

[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, 
>> using multiple parts of the GWT ecosystem:

[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] 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] 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.

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.

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] ^
>> [gwt.java

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] 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 1261366 Oct 18 2017 
>>> requestfactory-server+src.jar

&

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

>> scrappy:gwt-2.9.0-rc1 jimdouglas$ 

>> 
&

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-7, Michael Seele wrote:
>> I've downloaded
>> 
>> - gwt-

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

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_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_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.

[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.

[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] 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: 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] 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 

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 John
>>>>> Tamplin.>>>>> 

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_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] 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_source=footer
  5. 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/2f378177-0f77-626e-c3a6-b297bccbbdfc%40newsrx.com?utm_medium=email_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.

[gwt-contrib] Re: "GWT RPC" and its role in the future of GWT

[Colin Alworth]

At the risk of sounding like I'm telling off the people who agree with me 
that GWT-RPC has value, the purpose of this thread isn't to establish that 
RPC will live on in some form, but to discuss how it will be maintained. It 
_will_ still exist in some form, either as part of the "official GWT 
project", or as an external "spiritual successor", and will largely provide 
the same functionality we all either love or hate. If you'd like to support 
that goal directly, please contact me off-list.

I'm looking for some consensus among maintainers and contributors if 
something that looks like the GWT-RPC of old belongs under the general 
umbrella of GWT, even if it has slightly different setup and configuration, 
and grows to be general enough to function on non-GWT clients, servers. Of 
the discussed modules being migrated, this one seems to have the most 
"diverse" opinions around it, so I started this thread to take our 
collective temperature on keeping the "GWT" name on it and supporting it. 
Barring any strong disagreement, I'm going to take a day and renamespace 
everything in the next few days and open the repository up for review and 
comments, before starting to actually migrate it to the gwtproject github.

On Wednesday, October 17, 2018 at 9:36:23 AM UTC-5, Relja Pcela wrote:
>
> I have never seen any other solution (for GWT) that is even close to RPC. 
> It doesn't matter for me if it's part of GWT or it will be a separate 
> library. You can change the name if it's not popular any more why not ? Not 
> only that, I really think it's better to change the name of future GWT (v3) 
> to something else, as "GWT "is not popular any more. In contrary it's very 
> unpopular last few years and almost everyone is trying to escape from it.
>

-- 
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/2a88f3f6-4fc1-4fb3-9ec8-abfeefc25e2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] "GWT RPC" and its role in the future of GWT

[Colin Alworth]

As has been discussed previously in various venues, I have a mostly-working 
port of GWT-RPC that drops the use of legacy GWT APIs like Generators and 
JSNI, future-proofing both beyond GWT 2.x, and making it functional in 
other runtimes (JVM, Android, TeaVM, etc). It isn't perfect, and isn't 
quite complete, but before I work on softening those rough edges, I wanted 
to have a conversation here about whether it should remain a part of GWT 
going forward, and be migrated to the org.gwtproject package/groupId, and 
hosted at github.com/gwtproject.

There are two main reasons I see that would lead us to avoid doing this - 
RPC doesn't enjoy the popularity it once did, and the use of my current 
draft implementation could be considered to be far enough a way from the 
old Generator implementation that it might seem to be a different tool 
entirely. 

 * RPC-based mechanisms in general seem to be out of favor (though with 
gRPC gaining popularity, the idea might be coming back), with REST (whether 
JSON, Protobuf, or whatever else you like) leading in one direction and 
query mechanisms like GraphQL in another. I don't want to debate the pros 
and cons of these, or even to break down how "GWT-RPC" can be treated like 
a RPC or query mechanism, only to note that if RPC is considered by itself 
to be "too old-school", that might be are a reason to do nothing more than 
provide upgrade paths *within GWT itself*. 

 * In order to support being run by annotation processors in a performant 
way, my particular implementation all but mandates that the RPC interfaces 
and beans exist in their own "shared" project, apart from either client or 
server. Arguably this is a best practice to begin with, but it hasn't 
actually been required. Additionally, to support external dependencies 
(either other projects within your own product, or outside artifacts like 
the JRE or Guava that might have serializable types you'd be interested in) 
a manifest of some kind is required to point at the classes that should be 
considered while compiling. Presently this is supported through annotation 
processor arguments, but other mechanisms could be supported as well, but 
nothing as simple and obvious as "just assume that all possible subclasses 
will work" that GWT2's RPC supports. Reading private members isn't 
supported either - it is assumed that either those members will be 
non-private, or that getters and setters will be provided.

These two points probably need to be weighed relative to each other as 
well: we could decide that as long as the migration path for 90% of 
projects out there is simple enough that despite being out of favor, at 
least part of this tool should end up in org.gwtproject for now. Or, 
perhaps despite its continued popularity, the project is different enough 
that it shouldn't be included in org.gwtproject merely due to having its 
roots in "classic" GWT-RPC.

--

A quick technical overview - I don't want to get bogged down in this 
discussion just yet, just providing a summary to inform the topic at hand 
(though I'll be happy to provide more details as it helps to make this 
decision).

The project is composed of two annotation processors, and is intended to 
support a variety of use cases out of the box:
 * old pipe-delimited string format, or TypedArray/ByteBuffer based 
encoding (including not writing Strings to the typedarray at all but 
leaving them in a plain JS array for cheaper copying between the window and 
workers)
 * transport tools for page/worker, websockets, and fetch/xhr calls
 * interface-based approach to handling streams allowing other 
implementations to be added or further specialized, and transport 
mechanisms to be built per-platform so interfaces, beans, and generated 
serializers can be reused between platforms, easily enabling adding new 
platforms, or devising your own stream formats or transport mechanisms.

At runtime, the serialization stream interface is nearly identical to the 
old one, with the addition of one additional method when reading from the 
stream, to generalize mitigation on a class of attack that GWT-RPC 
historically only handled in the servlet. No reflection is used in the 
server implementation for de/serializing fields in objects, but it is 
instead assumed that either a field serializer has been created by the code 
generation mechanism, or a custom field serializer has been provided. 

Instead of a .gwt.rpc file on the server to enumerate types that are 
serializable and a JSNI map on the client, a single class is generated to 
describe this for each platform - server gets one, and client gets another 
for example, and these are almost certainly compliments of each other. 
Avoiding the JSNI map may pose a small risk at increasing generated code 
size, but I've tried to mitigate this by generating specific serializer 
types which describe exactly which operations are supported, so that any 
pruning step when compiling code can delete as much code as 

[gwt-contrib] Re: Unable to get GwtTestCase back up running

[Colin Alworth]

Glad you've got it sorted.

Since we are in the gwt-contrib list after all... if you're interested in 
seeing GWT updated to the latest HtmlUnit, there's no time like the present 
for a contribution to avoid this sort of issue in the future!

On Wednesday, August 29, 2018 at 4:54:48 PM UTC-5, Jörg Hohwiller wrote:
>
> Thanks Colin for your quick response.
> The broken JAR was 2.619.380 bytes. The correct JAR is 1.906.761 bytes.
> I am not using an intermediate maven repo (nexus, artifactory, archiva).
> However, I moved/backuped the JAR once more and now maven downloaded a 
> correct version.
> Whatever the reason for that error was. I hope it is not reproducable and 
> we can ignore that.
> So my assumption was wrong and then GWT release is fine.
>
> Am Mittwoch, 29. August 2018 23:39:07 UTC+2 schrieb Colin Alworth:
>>
>> For what its worth, I'm not seeing any such issues in opening classes 
>> within the 2.19 jar (source or binary) - any chance you've just got a 
>> corrupt local copy, or that your org has a maven repo with a corrupt copy?
>>
>> On Wednesday, August 29, 2018 at 4:24:59 PM UTC-5, Jörg Hohwiller wrote:
>>>
>>> Hi there,
>>> I am maintaining my project and did some upgrades including gwt 2.8.2 
>>> from 2.7.0.
>>> Now my JUnit based on GwtTestCase is failing with:
>>>
>>> java.lang.NoSuchFieldError: FIREFOX_38
>>> at 
>>> com.google.gwt.junit.RunStyleHtmlUnit.(RunStyleHtmlUnit.java:203)
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:264)
>>> at 
>>> com.google.gwt.junit.JUnitShell.createRunStyle(JUnitShell.java:1181)
>>> at com.google.gwt.junit.JUnitShell.doStartup(JUnitShell.java:942)
>>> at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:913)
>>> at 
>>> com.google.gwt.junit.JUnitShell.getUnitTestShell(JUnitShell.java:698)
>>> at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:672)
>>> at 
>>> com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)
>>> at junit.framework.TestCase.runBare(TestCase.java:141)
>>> at junit.framework.TestResult$1.protect(TestResult.java:122)
>>> at junit.framework.TestResult.runProtected(TestResult.java:142)
>>> at junit.framework.TestResult.run(TestResult.java:125)
>>> at junit.framework.TestCase.run(TestCase.java:129)
>>> at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:252)
>>> at junit.framework.TestSuite.run(TestSuite.java:247)
>>> at 
>>> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>>> at 
>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>>> at 
>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>> at 
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
>>> at 
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
>>> at 
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
>>> at 
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
>>>
>>> I found out that gwt-dev is depending on htmlunit 2.19 but due some 
>>> dependency management I was using 2.29 instead.
>>>
>>> So I overrode this again in my pom.xml:
>>>
>>> 
>>>   net.sourceforge.htmlunit
>>>   htmlunit
>>>   2.19
>>>   test
>>> 
>>>
>>> Now I am getting this error:
>>>
>>> java.lang.NoClassDefFoundError: 
>>> com/gargoylesoftware/htmlunit/BrowserVersion
>>> at 
>>> com.google.gwt.junit.RunStyleHtmlUnit.(RunStyleHtmlUnit.java:202)
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:264)
>>> at 
>>> com.google.gwt.junit.JUnitShell.createRunStyle(JUnitShell.java:1181)
>>> at com.google.gwt.junit.JUnitShell.doStartup(JUnitShell.java:942)
>>> at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:913)
>>> at 
>>> com.google.gwt.junit.JUnitShell.getUnitTestShell(JUnitShell.java:698)
>>> at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:672)
>>> at 
>>> com.google.gwt.junit.cl

[gwt-contrib] Re: Unable to get GwtTestCase back up running

[Colin Alworth]

With that update, you might need to look more at your test or project setup 
- can you share the full log from a mvn test (or whatever you do to run the 
gwt test cases)?

Any chance of another corrupt local jar?

On Wednesday, August 29, 2018 at 4:38:02 PM UTC-5, Jörg Hohwiller wrote:
>
> Indeed. I downloaded htmlunit 2.19 from here:
> https://sourceforge.net/projects/htmlunit/
> after replacing the JAR in my local maven repo it works or at least I get 
> a more promising error:
>
> com.google.gwt.junit.JUnitFatalLaunchException: The test class 
> 'net.sf.mmm.util.gwt.UtilCoreGwtTest' was not found in module 
> 'net.sf.mmm.util.gwt.UtilCoreGwtTest'; no compilation unit for that type 
> was seen
> at 
> com.google.gwt.junit.JUnitShell.checkTestClassInCurrentModule(JUnitShell.java:734)
> at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1327)
> at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1283)
> at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:672)
> at 
> com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
>
> However from a perspective of a maven user gwt 2.8.x is kind of broken...
>

-- 
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/e9f53686-d2ea-41ae-886a-3e9e3c746445%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Unable to get GwtTestCase back up running

[Colin Alworth]

For what its worth, I'm not seeing any such issues in opening classes 
within the 2.19 jar (source or binary) - any chance you've just got a 
corrupt local copy, or that your org has a maven repo with a corrupt copy?

On Wednesday, August 29, 2018 at 4:24:59 PM UTC-5, Jörg Hohwiller wrote:
>
> Hi there,
> I am maintaining my project and did some upgrades including gwt 2.8.2 from 
> 2.7.0.
> Now my JUnit based on GwtTestCase is failing with:
>
> java.lang.NoSuchFieldError: FIREFOX_38
> at 
> com.google.gwt.junit.RunStyleHtmlUnit.(RunStyleHtmlUnit.java:203)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at com.google.gwt.junit.JUnitShell.createRunStyle(JUnitShell.java:1181)
> at com.google.gwt.junit.JUnitShell.doStartup(JUnitShell.java:942)
> at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:913)
> at 
> com.google.gwt.junit.JUnitShell.getUnitTestShell(JUnitShell.java:698)
> at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:672)
> at 
> com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
>
> I found out that gwt-dev is depending on htmlunit 2.19 but due some 
> dependency management I was using 2.29 instead.
>
> So I overrode this again in my pom.xml:
>
> 
>   net.sourceforge.htmlunit
>   htmlunit
>   2.19
>   test
> 
>
> Now I am getting this error:
>
> java.lang.NoClassDefFoundError: 
> com/gargoylesoftware/htmlunit/BrowserVersion
> at 
> com.google.gwt.junit.RunStyleHtmlUnit.(RunStyleHtmlUnit.java:202)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at com.google.gwt.junit.JUnitShell.createRunStyle(JUnitShell.java:1181)
> at com.google.gwt.junit.JUnitShell.doStartup(JUnitShell.java:942)
> at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:913)
> at 
> com.google.gwt.junit.JUnitShell.getUnitTestShell(JUnitShell.java:698)
> at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:672)
> at 
> com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
> Caused by: java.lang.ClassNotFoundException: 
> com.gargoylesoftware.htmlunit.BrowserVersion
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 24 more
>
> What is also interesting: When I do go to BrowserVersion.class in the 
> htmlunit-2.29.jar 

Re: [gwt-contrib] Re: Migrating and update gwt-user.jar modules to github.com/gwtproject

[Colin Alworth]

https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit#gid=0
 is the list and status of various modules, though independently working on one 
isn't necessarily a bad thing (especially as most of the "easy" ones are off 
and going, and getting your feet wet in a "hard" one might be rather 
intimidating).
There is also lots of discussion at https://gitter.im/gwtproject/gwt if
you have questions, you may get answers or advice there.
--
  Colin Alworth
  co...@colinalworth.com



On Thu, Apr 12, 2018, at 11:47 AM, Grzegorz Nowak wrote:
> Hi
> 
> I saw that some people already started work on this. Is there a
> document / registry with information what is done by who to prevent 2+
> people working on the same thing?> 
> I guess a table with gwt module, and "WIP repo on github" /
> contributor name would be helpful.> 
> Regards
> Greg
> 
> On Friday, January 12, 2018 at 10:58:32 PM UTC+1, Colin Alworth wrote:>> 
> Hello contributors,
>> We've decided to change how we manage official gwt modules a bit, to
>> allow modernization and faster updates to gwt-user while still
>> supporting developers who need backward compatibility. We're now
>> allowing creation of repositories at github.com/gwtproject by
>> contributors who wish to help in this effort - send an email to the
>> list to request creation of a project, and we'll make it happen. CLAs
>> will not be required for these projects, and changes can be managed
>> via GitHub pull requests.>> 
>> Contributed code must follow a few guidelines - here is a brief (but
>> not official or exhaustive) list:>> * Support deployment to maven central, 
>> using org.gwtproject groupIds>> * Use org.gwtproject package
>> * Projects to be created must be updated versions of existing modules
>>   already within the GWT project sources - we are not looking to
>>   adopt new projects at this time.>> 
>> While the new project gets going, we will accept most pull requests
>> for the contributor who has adopted that module, and will enable
>> jenkins builds and SNAPSHOT releases for that project. Once it has
>> reached a stable state, we will require a review from a trusted
>> contributor for the existing code and for all future pull requests.
>> Then, once it has been reviewed, we will start official releases to
>> maven central.>> 
>> Updated modules should try to remain backward compatible (except for
>> package name) at least for the first release, then make appropriate
>> use of "@Deprecated" when preparing for breaking changes. Anything
>> already annotated with Deprecated can be removed, since users who are
>> looking to move to this will have already checked their code for
>> deprecation warnings. These practices will enable teams to switch to
>> these new projects by replacing imports with
>> com.google.gwt.modulename with org.gwtproject.modulename. More advice
>> to come from the work we've done thus far.>> 
>> Since this will only include existing modules that are already part
>> of GWT, we already have a reference for what tests should look like,
>> what they should cover, but of course contributors can also add more.
>> Removing support for old browsers is reasonable as well, since teams
>> who require legacy will have the versions still in gwt-user to fall
>> back on.>> 
>> As we make use of this new way of contributing to GWT, we'll make
>> this process more official based on things we learn along the way.> 


> --
>  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/0541cf43-6f36-4186-a67a-5d9c784080bd%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/0541cf43-6f36-4186-a67a-5d9c784080bd%40googlegroups.com?utm_medium=email_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/1523552288.262831.1335900592.24414506%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Naming convention for ported GWT modules

[Colin Alworth]

"gwt.org" is not available - it refers to a hiking trail.

My suggestion is org.gwtproject.$module:gwt-$module. 

Cons:
 - Redundant appearance of $module, and of "gwt"

Pros:
 - Multi-module maven projects all have the same groupid, instead of 
requiring that the gwt-event project all be under org.gwtproject, or 
inconsistently using org.gwtproject.$module for multi-module projects or 
org.gwtproject for single-module projects. Very reasonably we might have 
projects switch between these states (adding examples, etc), so we should 
be consistent between types of projects
 - The "gwt-" prefix makes it clear by looking at just the jar's name (in 
your IDE's maven dependency jar list, etc) where an artifact comes from
 - Room is left at the top for more modules, without assuming that all 
org.gwtproject:* modules are for the client (org.gwtproject.tools, etc)


While that's my preferred option, my only strong opinion here is that we 
plan for future maintainability - the need to change structure and add 
additional modules to any one project (ideally maintaining coordinates of a 
dependency that is in use), and consistency across modules.
On Saturday, March 24, 2018 at 3:27:01 PM UTC-5, Ahmad Bawaneh wrote:
>
> OK then, this means that gwt-timer should use *org.gtwproject* as group 
> id and *gwt-timer* as artifact id.
>
> On Saturday, March 24, 2018 at 11:30:10 AM UTC+2, Mincong Huang wrote:
>>
>> Hi,
>>
>> I'd like to have a clarification about the naming convention for ported 
>> GWT modules. Because I'm porting the module `gwt-safecss` and 
>> `gwt-animation`. When I go to Vertispan repository [1], the available 
>> modules do not use the same rule for the group ID and artifact ID. This is 
>> a pain when you reference them as dependencies. Here're 5 rules that I 
>> found.
>>
>> *Rule 1:*
>> Use "org.gwtproject" + module name as group id; module name with "gwt-" 
>> prefix as artifact id. This rule is used by `gwt-http`:
>>
>> GROUP_ID:org.gwtproject.$MODULE
>> ARTIFACT_ID: gwt-$MODULE
>>
>> *Rule 2:*
>> Use "org.gwtproject" + module name as group id; module name without 
>> "gwt-" prefix as artifact id. This rule is used by `gwt-event`, 
>> `gwt-place`, `gwt-safehtml`, `gwt-storage`, `gwt-timer`:
>>
>> GROUP_ID:org.gwtproject.$MODULE
>> ARTIFACT_ID: $MODULE
>>
>> *Rule 3:*
>> Use "org.gwtproject" as group id; module name with "gwt-" prefix as 
>> artifact id. This rule is used by `gwt-xhr`:
>>
>> GROUP_ID:org.gwtproject
>> ARTIFACT_ID: gwt-$MODULE
>>
>> *Rule 4:*
>> Use "org.gwtproject" as group id; module name without "gwt-" prefix as 
>> artifact id. This rule is used by `gwt-json`, `gwt-typedarrays`, `gwt-xml`, 
>> `gwt-xhr`:
>>
>> GROUP_ID:org.gwtproject
>> ARTIFACT_ID: $MODULE
>>
>> *Rule 5:*
>> Other rules: `gwt-window`, `gwt-history`.
>>
>> I suggest we apply rule 4 to all the modules. It means always using 
>> "org.gwtproject` as group id, and use `gwt-` + module name as artifact id. 
>> There're several benefits. It helps people to find all the artifacts via 
>> the same group id. It also keeps consistency for the generated JAR files: 
>> each of them contains a "gwt-" prefix, thus they are GWT artifacts.
>>
>> Cheers,
>> Mincong Huang
>>
>> [1]: https://repo.vertispan.com/gwt-snapshot/
>>
>

-- 
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/7532d726-df51-457c-a29c-70d773d0bb25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Updating GWT CLDR data from v25 to v32

[Colin Alworth]

With no replies in two weeks, I'd say you should proceed with a change 
request to the tools repo to add the new jar, and the changes required to 
the gwt project itself to support the new version.

On Friday, February 16, 2018 at 1:34:16 PM UTC-6, Colin Alworth wrote:
>
> From our discussion in Gitter, it sounds like many/most of the changes in 
> GoogleMods are no longer needed to get tests to pass - either the existing 
> tests are insufficient to make sure that these changes are still there, or 
> the important changes have been folded in upstream.
>
> I do recall that there were large portions of the patch that no longer 
> apply cleanly (not a huge surprise since it is 7 versions apart), either 
> because the change is already there, or because that region of code 
> changed, and the diff no longer makes sense.
>
> Googlers: If these changes are important, can you weigh in on how we will 
> evaluate the jar before it gets pushed to tools? If not, are we comfortable 
> just using the standard CLDR 32 release, so we can fix the out-of-date 
> timezones that currently plague GWT?
>
> On Friday, February 2, 2018 at 1:51:18 PM UTC-6, Ahmad Bawaneh wrote:
>>
>> Sorry i forgot to link my work to this issue
>>
>> https://github.com/gwtproject/gwt/issues/9557
>>
>> On Friday, February 2, 2018 at 9:47:59 PM UTC+2, Ahmad Bawaneh wrote:
>>>
>>> Dears
>>> I have been working on updating the CLDR data from cldr version 25 to 
>>> cldr version 32, the generation of the new data have been done successfully 
>>> and all gwt test cases pass.
>>>
>>> i would like to make a pull request for both the cldr tools and gwt but 
>>> first i need to discuss the part related to the *GoogleMods.patch*
>>>
>>> this patch was supposed to be version 25 which is too old now and since 
>>> we are going to a new version of cldr data 32 Do we still need to fix and 
>>> apply the patch, or should we go with a more standard cldr data?
>>>
>>> i need to decide on this before i finish my work and make a pull request.
>>>
>>> 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/311fb6e8-f20d-4ba4-8f10-c30fc9097c16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] JUnit tests without Generators

[Colin Alworth]

Several things I'd like to achieve:
 * I'd like to support JUnit 4 in GWT2 (well, I'd actually like to support 
JUnit 5 in both, but one step at a time) - JUnit 3 practically doesn't 
exist outside of GWT2.
 * There are probably better ways to do testing than the existing junit 
shell wiring in GWT2, such as leveraging SDM to quickly make changes and 
re-run tests, finding other ways to serve content, avoiding generators and 
arcane servlet tags, etc. Adopting JUnit4 to replace the current generator 
in GWT2 gets part of that work done up front.
 * Existing junit shell wiring has some annoying dependencies and needs a 
rewrite anyway if we are to continue migrating and updating official 
modules - even if we decide that JUnit 3 is superior to 4, and that 
recompiling without SDM is better in GWT2, we still can't (for example) 
properly unit test an updated I18n module which uses a system property 
named `locale` without running into issues with the existing I18n module, 
which the old junit wiring makes every test use (JUnit -> Logging -> 
LoggingDisabled -> UI, which includes basically everything else in 
gwt-user).

On Friday, February 16, 2018 at 1:59:12 PM UTC-6, Goktug Gokdogan wrote:
>
> I haven't thought about separating it from J2CL, not sure if it is a good 
> idea.
> Why do you need it for GWT2? For code sharing, we simply use Junit3 style 
> and we didn't feel much pain about it.
>
>
> On Thu, Feb 15, 2018 at 12:15 PM Colin Alworth <nilo...@gmail.com 
> > wrote:
>
>> Anything we can do to facilitate this? Also, if it is released under 
>> j2cl, is there an expectation that it could be factored out and made to 
>> work with GWT2, and released generally instead of just under J2CL (in its 
>> binaries and its deadlines)?
>>
>> On Friday, January 26, 2018 at 9:17:39 PM UTC-6, Goktug Gokdogan wrote:
>>>
>>> Yes, that's correct.
>>>
>>> It is a simple system with two part generation.
>>> First part in bazel that generates an empty java class with a class 
>>> annotation that points to JUnit suite to trigger APT.
>>> The second part in APT that generates the wrapper around junit3/junit4 
>>> tests that are listed in the suite to export test function to the global 
>>> scope (as the javascript framework expects).
>>>
>>> There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to 
>>> compile or make things look like regular JVM test. End result is a pure 
>>> javascript suite executed by a javascript test framework driver.
>>>
>>> On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer <t.br...@gmail.com> 
>>> wrote:
>>>
>>>> Correct me if I'm wrong, this is relying on JUnit 4 suited to generate 
>>>> appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically, 
>>>> possibly simply TestCase), with a "new" emulation of those classes based 
>>>> on 
>>>> JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 
>>>> 3 
>>>> to find test, setup, teardown methods/functions by naming rules)
>>>>
>>>> --
>>>> 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/a083c6c4-43aa-44f0-a639-2eab1a12a2c7%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/daeccad3-886f-4fda-801d-694c3d4f19d3%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/daeccad3-886f-4fda-801d-694c3d4f19d3%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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/afe40d9c-a652-413c-a776-e2a6df9bba15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Updating GWT CLDR data from v25 to v32

[Colin Alworth]

>From our discussion in Gitter, it sounds like many/most of the changes in 
GoogleMods are no longer needed to get tests to pass - either the existing 
tests are insufficient to make sure that these changes are still there, or 
the important changes have been folded in upstream.

I do recall that there were large portions of the patch that no longer 
apply cleanly (not a huge surprise since it is 7 versions apart), either 
because the change is already there, or because that region of code 
changed, and the diff no longer makes sense.

Googlers: If these changes are important, can you weigh in on how we will 
evaluate the jar before it gets pushed to tools? If not, are we comfortable 
just using the standard CLDR 32 release, so we can fix the out-of-date 
timezones that currently plague GWT?

On Friday, February 2, 2018 at 1:51:18 PM UTC-6, Ahmad Bawaneh wrote:
>
> Sorry i forgot to link my work to this issue
>
> https://github.com/gwtproject/gwt/issues/9557
>
> On Friday, February 2, 2018 at 9:47:59 PM UTC+2, Ahmad Bawaneh wrote:
>>
>> Dears
>> I have been working on updating the CLDR data from cldr version 25 to 
>> cldr version 32, the generation of the new data have been done successfully 
>> and all gwt test cases pass.
>>
>> i would like to make a pull request for both the cldr tools and gwt but 
>> first i need to discuss the part related to the *GoogleMods.patch*
>>
>> this patch was supposed to be version 25 which is too old now and since 
>> we are going to a new version of cldr data 32 Do we still need to fix and 
>> apply the patch, or should we go with a more standard cldr data?
>>
>> i need to decide on this before i finish my work and make a pull request.
>>
>> 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/b8a7fd2d-81ab-4390-a618-dc742bb17fac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] JUnit tests without Generators

[Colin Alworth]

Anything we can do to facilitate this? Also, if it is released under j2cl, 
is there an expectation that it could be factored out and made to work with 
GWT2, and released generally instead of just under J2CL (in its binaries 
and its deadlines)?

On Friday, January 26, 2018 at 9:17:39 PM UTC-6, Goktug Gokdogan wrote:
>
> Yes, that's correct.
>
> It is a simple system with two part generation.
> First part in bazel that generates an empty java class with a class 
> annotation that points to JUnit suite to trigger APT.
> The second part in APT that generates the wrapper around junit3/junit4 
> tests that are listed in the suite to export test function to the global 
> scope (as the javascript framework expects).
>
> There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to 
> compile or make things look like regular JVM test. End result is a pure 
> javascript suite executed by a javascript test framework driver.
>
> On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer  > wrote:
>
>> Correct me if I'm wrong, this is relying on JUnit 4 suited to generate 
>> appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically, 
>> possibly simply TestCase), with a "new" emulation of those classes based on 
>> JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 3 
>> to find test, setup, teardown methods/functions by naming rules)
>>
>> --
>> 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/a083c6c4-43aa-44f0-a639-2eab1a12a2c7%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/daeccad3-886f-4fda-801d-694c3d4f19d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] JUnit tests without Generators

[Colin Alworth]

As we look at how to keep migrating GWT provided user modules to modern 
best practices, the JUnit runner is a hairy one - it relies on a lot of the 
practices we discourage, including a great many modules in GWT that we 
might prefer it not use. It also assumes

As has been discussed on other lists, Google has an internal APT-based 
JUnit runner that presumably emits some Java and/or JS to enable some 
JS-based test running tools to iterate through the required tests and 
notify the user of failing code, including hints as to why it failed, with 
stack traces, etc. It has been previously discussed that this might be 
something that could be shared in whole or in part with the open source 
community, time permitting.

Is this still in the cards? Can any aspects of this implementation be 
discussed ahead of time so we can prepare our own tests for it? For 
example, does it use JUnit 4, and if so, can it use Rules, or just 
before/after methods? 

--

Along similar lines, I did some work last fall to try to get JUnit 5 tests 
to work in a browser, but stopped shortly after working out how to replace 
the Engine with one that could in theory hand off control to a browser, and 
report back when complete. My idea was that if the JVM could dictate which 
tests were available to run, then JUnit 4 emulation could work, and JUnit 5 
wiring would just ask our custom engine to transpile and run those tests, 
and report back all results in the familiar junit xml, with the expected 
build tool and IDE integration. This still might be worth pursuing, perhaps 
in parallel with any work Google already has working and is able to share.

Thanks,
Colin

-- 
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/7ecb26e6-e315-4e99-a89f-29a1a1a3c1b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Migrating and update gwt-user.jar modules to github.com/gwtproject

[Colin Alworth]

Hello contributors,
We've decided to change how we manage official gwt modules a bit, to allow 
modernization and faster updates to gwt-user while still supporting 
developers who need backward compatibility. We're now allowing creation of 
repositories at github.com/gwtproject by contributors who wish to help in 
this effort - send an email to the list to request creation of a project, 
and we'll make it happen. CLAs will not be required for these projects, and 
changes can be managed via GitHub pull requests.

Contributed code must follow a few guidelines - here is a brief (but not 
official or exhaustive) list:
* Support deployment to maven central, using org.gwtproject groupIds
* Use org.gwtproject package
* Projects to be created must be updated versions of existing modules 
already within the GWT project sources - we are not looking to adopt new 
projects at this time.

While the new project gets going, we will accept most pull requests for the 
contributor who has adopted that module, and will enable jenkins builds and 
SNAPSHOT releases for that project. Once it has reached a stable state, we 
will require a review from a trusted contributor for the existing code and 
for all future pull requests. Then, once it has been reviewed, we will 
start official releases to maven central.

Updated modules should try to remain backward compatible (except for 
package name) at least for the first release, then make appropriate use of 
"@Deprecated" when preparing for breaking changes. Anything already 
annotated with Deprecated can be removed, since users who are looking to 
move to this will have already checked their code for deprecation warnings. 
These practices will enable teams to switch to these new projects by 
replacing imports with com.google.gwt.modulename with 
org.gwtproject.modulename. More advice to come from the work we've done 
thus far. 

Since this will only include existing modules that are already part of GWT, 
we already have a reference for what tests should look like, what they 
should cover, but of course contributors can also add more. Removing 
support for old browsers is reasonable as well, since teams who require 
legacy will have the versions still in gwt-user to fall back on. 

As we make use of this new way of contributing to GWT, we'll make this 
process more official based on things we learn along the way.

-- 
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/0d213bd6-fc0a-4eed-bd15-6c2f87e2641e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Porting gwt-i18n module to gwt3

[Colin Alworth]

In response to both Learner and Thomas, I think those "dynamic"
solutions would be great to have in later releases, so as to first
support GWT 2's existing functionality, and second optimize for use
cases like runtime strings changing or leaning on closure directly to
improve compile times (and directly interop with other js libs that also
happen to use closure, though in my experience this sadly tends not to
be a long list).
I've been playing with the new Intl for both NumberFormat and
DateTimeFormat, and both seem somewhat lacking compared to what GWT
offers - there is no option to provide your own format string as far as
I can tell, only request various options. This might work for 80% or so
of cases, but I can imagine things getting very frustrating for that
last 20% without each project writing their own parser if GWT's i18n
doesn't support it. DateTimeFormat.formatToParts looks like it could
potentially be used as a primitive in building this functionality (if we
wanted to forgo any JVM support) perhaps. That said, formatToParts is
still not well supported yet (no Edge, no IE11, no FF ESR).
--
  Colin Alworth
  co...@colinalworth.com



On Sun, Jan 7, 2018, at 1:06 PM, Thomas Broyer wrote:
> 
> 
> On Sunday, January 7, 2018 at 7:00:45 PM UTC+1, Thomas Broyer wrote:
>> 
>> On Friday, January 5, 2018 at 6:33:48 PM UTC+1, Ahmad Bawaneh wrote:>>> Dears
>>> I am working on porting the *i18n* module, so far all i did is
>>> extract the module and the tests into and external repository and
>>> make the tests pass, not real change to the code have been yet. but
>>> the *i18n* module is an important module and is being used by so
>>> many gwt application so porting this one should be taken with care,
>>> this why i am opining this discussion so that i can hear and share
>>> idea's.>> 
>> Thanks for taking this initiative; i18n support indeed is a
>> must-have.>> I however think we need to critically reevaluate our current 
>> design
>> (particularly in light of the new JS Intl APIs that already have wide
>> browser support:
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl).>>
>>  Constants, ConstantsWithLookup, Messages, and CustomDateTimeFormat
>> however are likely to stay similar though (and have their
>> implementation rely on those new APIs).>>  
>>> i would like to start this discussion by sharing some of my
>>> thoughts, which are limited to my knowledge of the gwt *i18n*, and i
>>> would love to get corrections and feedback to what ever wrong or
>>> good thinking i have.>>> 
>>> so first in a gwt 2.x application using *i18n* with generators
>>> assumes that the set of locales available is known during the code
>>> generation, for example if you an application that has a module lets
>>> call it module *A* that define a messages interface (*MessagesA*)
>>> and defines the locales to be `*en*`, `*fr*` for example, then once
>>> the application is compiled, the generator should produce
>>> *MessagesA* class for each locale and we end up with *MessagesA_en*
>>> and *MessagesA_fr* having that we provide properties files for both.>>> 
>>> now assume we add a new module to our application module *B* and B
>>> defines another messages interface *MessagesB* and extends the
>>> locale property to add a third locale `*it*` and provide properties
>>> files for *MessagesB en,fr and it* and also provide a properties
>>> file for* MessagesA it*, then when we compile we will end up with
>>> *MessagesA_en*, *MessagesA_fr*, and *MessagesA_it*, *MessagesB_en*,
>>> *MessagesB_fr*, and *MessagesB_it*.>>> 
>>> with this i could extends the application messages by adding a new
>>> module thanks to the Property oracle that provide information about
>>> all defined and extended locales.>>> 
>>> now in the APT world with multi modules things are different, the
>>> processors does not rum for all modules as one unit instead the
>>> processor will run for a single module and will have knowledge
>>> limited to that module,  so  module *A* processor wont know about
>>> locales defined in module *B*, and module *B* processor wont know
>>> about locale values provided by module *A*, so and expected result
>>> that i will end up with *MessagesA_en*, *MessagesA_fr* for module
>>> *A* and *MessagesB_it* for module *B*.>>> 
>>> what do you think?
>> 
>> I think anything that supports localization should expose ways to
>> replace the constants or messages being used, like SimplePage

[gwt-contrib] Re: Porting gwt-i18n module to gwt3

[Colin Alworth]

I would be interested in hearing about concrete cases where one jar adds 
.properties files for a class declared in a completely different jar - I 
haven't seen that done in the wild before, it sounds like a bit of a 
stretch to me. It might also be something that we could formally discourage 
in the "new and improved i18n tool" docs. Alternatively, I've heard of 
cases where the upstream jar doesn't run the processor, but just defines 
the sources and lets the downstream jar run it when it provides the rest of 
the impl details. 

At the risk of sounding like I'm speaking for the team that built the 
original i18n module, I see it as trying to replicate 
PropertyResourceBundle behavior in the JVM, without the need to have 
runtime access to the classpath. I could be mistaken, but using 
PropertyResourceBundle in the way you describe (loading .properties files 
from a different jar) may no longer work correctly in Java 9 anyway, at 
least without custom module permissions for access (somewhat akin to 
running or re-running the processor on the downstream project)? Might be 
wrong on that. Reusing that .properties format for localized files and 
BundleName_locale.properties file name format seems like an express design 
goal to me, no matter what other changes happen along the way.

On Friday, January 5, 2018 at 11:33:48 AM UTC-6, Ahmad Bawaneh wrote:
>
> Dears
> I am working on porting the *i18n* module, so far all i did is extract 
> the module and the tests into and external repository and make the tests 
> pass, not real change to the code have been yet. but the *i18n* module is 
> an important module and is being used by so many gwt application so porting 
> this one should be taken with care, this why i am opining this discussion 
> so that i can hear and share idea's.
>
> i would like to start this discussion by sharing some of my thoughts, 
> which are limited to my knowledge of the gwt *i18n*, and i would love to 
> get corrections and feedback to what ever wrong or good thinking i have.
>
> so first in a gwt 2.x application using *i18n* with generators assumes 
> that the set of locales available is known during the code generation, for 
> example if you an application that has a module lets call it module *A* 
> that define a messages interface (*MessagesA*) and defines the locales to 
> be `*en*`, `*fr*` for example, then once the application is compiled, the 
> generator should produce *MessagesA* class for each locale and we end up 
> with *MessagesA_en* and *MessagesA_fr* having that we provide properties 
> files for both.
>
> now assume we add a new module to our application module *B* and B 
> defines another messages interface *MessagesB* and extends the locale 
> property to add a third locale `*it*` and provide properties files for 
> *MessagesB 
> en,fr and it* and also provide a properties file for* MessagesA it*, then 
> when we compile we will end up with *MessagesA_en*, *MessagesA_fr*, and 
> *MessagesA_it*, *MessagesB_en*, *MessagesB_fr*, and *MessagesB_it*.
>
> with this i could extends the application messages by adding a new module 
> thanks to the Property oracle that provide information about all defined 
> and extended locales.
>
> now in the APT world with multi modules things are different, the 
> processors does not rum for all modules as one unit instead the processor 
> will run for a single module and will have knowledge limited to that 
> module,  so  module *A* processor wont know about locales defined in 
> module *B*, and module *B* processor wont know about locale values 
> provided by module *A*, so and expected result that i will end up with 
> *MessagesA_en*, *MessagesA_fr* for module *A* and *MessagesB_it* for 
> module *B*.
>
> what do you think?
>

-- 
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/e40829d8-fbda-47b9-9516-27ea7995cc81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Which API for a future, modern JSON library?

[Colin Alworth]

Thanks Thomas, I'm excited to see where this will lead.

Can you talk a little more about plans POJO support, as none of the three 
existing options have any? Would you envision a wrapping tool that looks 
like AutoBean/gwt-jackson, and where on that continuum are you thinking 
(autobean is as late as possible, and generic enough to handle xml or other 
underlying data formats, gwt-jackson parses then copies all json tree nodes 
directly to bean values)? I also know there have been some experiments 
around passing a reviver func to JSON.parse that could be interesting here. 
Any thoughts on handling collections, whether to go with java.util, or try 
for something shared js/jvm and only used within this library?

As a replacement for elemental.json or c.g.g.json, I would personally 
imagine only the json node tree support. I'm aware that work is ongoing 
already to update gwt-jackson to move to APT, and am considering trying 
AutoBeans myself, mostly because i find it so handy when I want to write 
strongly typed java around plain json.

My only thought on adapter vs starting with a specific jre parser is that 
there is a lot of flexibility/depth already in this project - perhaps just 
keep the internals as private as possible, and leave room for such adapters 
in vers 2?

On Monday, December 11, 2017 at 6:25:04 AM UTC-6, Thomas Broyer wrote:
>
> Hi all,
>
> Following up on 
> https://github.com/gwtproject/gwt/issues/9484#issuecomment-277216304, 
> I've been toying around to build a new JSON library for GWT.
> Note that my goal is to have a lightweight library that could be used both 
> on the client-side with GWT (and then j2cl), and on the server-side or in 
> any JVM; and "mapping" to/from POJOs is (currently) out of scope.
>
> What do you think would be the best API?
>
>
>- Same as com.google.gwt.json.
>This API is IMO verbose, and is based on wrapper objects that add 
>runtime overhead.
>- Same as elemental.json, except for JsonNull which goes away 
>(represented by a Java 'null' and interchangeable with 'undefined').
>Lighter-weight, both in terms of API verbosity and runtime overhead 
>(no wrapper object).
>Based on type coercion (you can ask every JsonValue to be returned as 
>a boolean, double, or String, and value will be coerced accordingly).
>elemental.json "JRE" types are also usable on client-side, and can be 
>transported through GWT-RPC; I believe this is an aspect that we cannot 
>preserve.
>- Similar to jsinterop-base's Any, JsPropertyMap and JsArrayLike (for 
>JsonValue, JsonObject and JsonArray respectively), and using Java String 
>and primitives for other value types; and probably with the addition of a 
>JsonType enum (or isXxx methods) on Any/JsonValue to be able to tell value 
>types apart before you call the (throwing) asXxx methods.
>This is actually similar to elemental.json but without the 
>JsonBoolean, JsonNumber, and JsonString types; and it throws rather than 
>coercing values.
>This could even go farther and directly use JsonValue[] instead of 
>JsonArray.
>- Something else?
>
> One question also is whether this should be used for consuming JSON 
> mostly, or also for creating JSON (you'd generally use POJOs and serialize 
> them to JSON I believe, but there may be cases where you want to create a 
> dynamic structure that you cannot easily represent as a tree of POJOs), 
> and/or "updating/modifying JSON" (parse, update, stringify).
>
> Fwiw, this would also be a good opportunity to shape how a cross-platform 
> library would be developed in terms of project layout and tooling (in both 
> Gradle and Maven).
>
> Wrt the JVM/server-side support, what JSON parsing library should be used? 
> I was heading towards the lightweight Moshi from Square, but I believe 
> there could possibly be several "adapters" for Moshi, GSON, Jackson, etc. 
> (and even org.json's JsonTokenizer/JsonStringer)
>

-- 
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/3c1d1f76-6da7-4a5f-bda0-7ddcbe2eaddd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Elemental2:1.0.0-beta-2 released

[Colin Alworth]

com.google.jsinterop:base:1.0.0-beta-3 was released to maven central on
nov 10:
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.google.jsinterop%22%20AND%20a%3A%22base%22

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

On Sun, Dec 3, 2017, at 07:28 PM, Hristo Stoyanov wrote:
> Hm ... Julien states it only works with the latest get head snapshot,
> maybe not 2.8.2? Also, seems like beta-3 with Colin's findings was never
> pushed out to maven?
> 
> -- 
> 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/214ed3ca-ddf7-46e4-a588-09ff28d731fc%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/1512404451.1048938.1193498520.6BB7DB76%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Elemental2:1.0.0-beta-2 released

[Colin Alworth]

It looks like the poms weren't correctly updated - they still depend on 
jsinterop-base 1.0.0-beta-1, tickling 
https://github.com/google/elemental2/issues/20 again. The gwt2 compiler 
fails on this with this sort of error:
[INFO][ERROR] Errors in 
'jar:file:/Users/colin/.m2/repository/com/google/elemental2/elemental2-dom/1.0.0-beta-2/elemental2-dom-1.0.0-beta-2.jar!/elemental2/dom/Element.java'
[INFO]   [ERROR] Line 260: The method asString(Element.
ReplaceWithNodesUnionType) is undefined for the type Js
[INFO]   [ERROR] Line 303: The method asBoolean(Element.
ScrollIntoViewTopUnionType) is undefined for the type Js
[INFO]   [ERROR] Line 326: The method asBoolean(Element.
SetAttributeNSValueUnionType) is undefined for the type Js
[INFO]   [ERROR] Line 331: The method asDouble(Element.
SetAttributeNSValueUnionType) is undefined for the type Js
[INFO]   [ERROR] Line 336: The method asString(Element.
SetAttributeNSValueUnionType) is undefined for the type Js
[INFO]   [ERROR] Line 364: The method asBoolean(Element.
SetAttributeValueUnionType) is undefined for the type Js
[INFO]   [ERROR] Line 369: The method asDouble(Element.
SetAttributeValueUnionType) is undefined for the type Js
[INFO]   [ERROR] Line 374: The method asString(Element.
SetAttributeValueUnionType) is undefined for the type Js

Simple workaround, manually add excludes on jsinterop-base, and inherit the 
correct version in your project:

  com.google.elemental2
  elemental2-dom
  1.0.0-beta-2
  

  com.google.jsinterop
  base

  


  com.google.jsinterop
  base
  1.0.0-beta-3


Julien, if you do happen to release an updated beta to solve this, perhaps 
also update jsinterop-annotations to 1.0.2, the version that was released 
with GWT 2.8.2.


On Wednesday, November 22, 2017 at 7:13:29 PM UTC-6, Julien Dramaix wrote:
>
> The beta version of Elemental2 using the JsInterop specification has been 
> released on Sonatype today and is available on Maven central. This release 
> should be the last beta release and I expect to release the first RC in few 
> weeks.
>
>
> This release introduces -- among others:
>
> - a better granularity for api with numbers. Config files list APIs using 
> integer instead of double.
>
> - usage of wildcard type for more flexibility.
>
> - support for javascript constructor function 
>
> - static factory methods for dictionary type.
>
> Elemental2 is split into small jar files:
>
>
> Jar file
>
> artifact-id
>
> GWT module
>
> elemental2-core.jar 
> 
>
> elemental2-core
>
> elemental2.core.Core
>
> elemental2-promise.jar 
> 
>
> elemental2-promise
>
> elemental2.promise.Promise
>
> elemental2-dom.jar 
> 
>
> elemental2-dom
>
> elemental2.dom.Dom
>
> elemental2-svg.jar 
> 
>
> elemental2-svg
>
> elemental2.svg.Svg
>
> elemental2-webgl.jar 
> 
>
> elemental2-webgl
>
> elemental2.webgl.WebGl
>
> elemental2-media.jar 
> 
>
> elemental2-media
>
> elemental2.media.Media
>
> elemental2-indexeddb.jar 
> 
>
> elemental2-indexeddb
>
> elemental2.indexeddb.IndexedDb
>
> elemental2-webstorage.jar 
> 
>
> elemental2-webstorage
>
> elemental2.webstorage.WebStorage
>
>
>
> You can try them by downloading the jar files or adding Maven dependencies:
>
>
> 
>
>  com.google.elemental2
>
>  ${artifact-id}
>
>  1.0.0-beta-2
>
> 
>
>
> Then inherit the right gwt module in your gwt.xml file.
>
>
> This beta version works only with the latest HEAD_SNAPSHOT release of GWT 
> 
> .
>
>
> Don’t hesitate to report any bugs, issues, concerns you have on the 
> github bug tracker .
>
>
> Important note: This is a beta releases and future updates (up until the 
> final 

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

[Colin Alworth]

On Friday, November 17, 2017 at 10:37:59 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:
>>
>> Sounds like there is enough diversity of opinion that this discussion 
>> should go on - first step seems to be deciding if we think the CLA
>>
>
> Some links about CLAs:
> https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ 
> & 
> https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/
>
> https://web.archive.org/web/20150917011232/http://www.computerworlduk.com/blogs/simon-says/should-open-source-communities-avoid-contributor-agreements-3569648/
> http://contributoragreements.org/
> Some tools to manage CLAs: https://cla-assistant.io/ (by SAP), 
> https://www.clahub.com/
>
> As a) purely "community-driven projects", that b) won't even be used by 
> Google (their original author), I would say that we don't need CLAs (also, 
> the choice of the Apache License protects the users from a lot of things 
> already).
> That said, IANAL, and I'm not doing any work here on behalf of my 
> employer; so people for whom CLAs are important should weigh in.
>  
>
>> and/or gerrit-style review is important for all artifacts deployed to 
>> org.gwtproject. 
>>
>
> I *love* Gerrit, and use it daily at work; but I cannot ignore that GitHub 
> pull requests have gotten a whole lot better those past years, and I have 
> absolutely no problem using them instead of Gerrit; which is a barrier to 
> entry that many don't even try passing (Go has had the same issue, they 
> built tooling around it instead, and documentation, and despite that it's 
> apparently still seen as a barrier to entry to many –Chrome and Android are 
> different, as they're much bigger beasts already).
> Keeping in mind that gwt.googlesource.com is maintained by Google which 
> wouldn't be involved in those projects, this poses the problem of who would 
> admin Gerrit, and whether Google would host it indefinitely for us (Google 
> is using pull requests for a lot of projects, and this includes j2cl –still 
> a private repository–, jsinterop-base, jsinterop-generator, and elemental2).
> This all pushes for using GitHub pull requests.
> Now, from my PoV, each project maintainer would be free to choose how to 
> manage code in their repo (see below): whether to use PRs for everything 
> (never push to master), choosing a branching and merging strategies (I for 
> one would use rebase and/or squash, possibly manually to squash some 
> commits and preserve others, and follow "trunk based development" 
> <https://trunkbaseddevelopment.com/> –this is actually what we do for GWT 
> already; I'd love to see everyone embrace the same view, but I'm not sure 
> forcing a "standard" is the way to go –bikeshedding, etc.), and versioning 
> and release strategies (I think everyone would agree on using semver, but 
> what about maintaining several versions in parallel? releasing at a 
> scheduled cadence –like Guava and Dagger do for instance– vs. "release when 
> it's ready", etc.)
>
> For the time being, it sounds like individual groupIds are the way 
>> forward, with the expectation of migrating projects to org.gwtproject and 
>> github.com/gwtproject once they reach a certain level of quality and 
>> stability, once we decide what that is.
>>
>
> As far as I'm concerned, I'm formatting all my code using 
> google-java-format (and enforce it in build) and checking it with Error 
> Prone (FindBugs could possibly be a good addition).
> Wrt google-java-format, just like gofmt for Go, rustfmt for Rust, 
> prettier+eslint for JS/CSS/etc., ktlint for Kotlin, etc. prevents 
> bikeshedding on the formatting. I don't always like how it formats things, 
> but at least I don't have to worry about it. “Gofmt's style is no one's 
> favorite, yet gofmt is everyone's favorite.” 
> <https://www.youtube.com/watch?v=PAAkCSZUG1c=8m43s>
> Similarly for Error Prone, nothing to configure, just let it fail your 
> build (early, really early).
> But that's only a fraction of code quality (see also branching strategies 
> above for another fraction).
> With smaller projects, I think we might be able to run tests on 
> BrowserStack or SauceLabs, through Travis.
>
> Now, I'd like to advocate for more autonomy and responsibility for 
> maintainers: manage their project the way they want, release when they 
> want,  use Maven or Gradle as they prefer, etc. This means that there might 
> be projects that are more stable and/or of greater quality than others (but 
> so are modules inside gwt-user already actually).
> Jenkins CI host a

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

[Colin Alworth]

Sounds like there is enough diversity of opinion that this discussion 
should go on - first step seems to be deciding if we think the CLA and/or 
gerrit-style review is important for all artifacts deployed to 
org.gwtproject. 

For the time being, it sounds like individual groupIds are the way forward, 
with the expectation of migrating projects to org.gwtproject and 
github.com/gwtproject once they reach a certain level of quality and 
stability, once we decide what that is. As per our name use policy, that 
should fall to the steering committee to decide, but I at least would 
welcome more feedback from contributors on what those standards might look 
like.

Likewise from that name use document, we should avoid the use of 
org.gwtproject packages as well until that time. This might make migration 
a little trickier (changing packages multiple times) as we refactor various 
modules out from gwt-user. For my part, I would like to see this line 
blurred slightly or at least clarified - code which started its life in 
com.google.gwt but isn't presently "controlled" by the committee due it it 
being in progress should perhaps not be restricted in this way (in the same 
way that Vaadin ships a GWT fork, but still uses com.google.gwt packages 
for compatibility). We could phrase this in individual projects as "This 
code came from GWT, and is incubating here until it is contributed back to 
GWT", making it clear that the project is not intended to be a third party 
tool, but is using the name in good faith that this will be again part of 
GWT soon.


On Wednesday, November 15, 2017 at 2:23:02 PM UTC-6, Goktug Gokdogan wrote:
>
> It could be hard to communicate and set expectations with a live 
> work-in-progress gwt-project repository and via publishing on maven 
> central. I agree with Jens on first setting up a foundation, rules and also 
> maturing what GWT3 is; and in the meantime let people iterate in their own 
> repos which will set expectation accordingly.
>
> On Wed, Nov 15, 2017 at 9:31 AM, Jens  
> wrote:
>
>> Oh and if its just about making these small projects more discoverable 
>> then one could also create a single project, e.g. gwtproject/gwt3-migration 
>> and use the wiki for documentation and/or git submodules to link in all 
>> these small projects as well.
>>
>> -- 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/ee2066ec-2b18-4921-8476-6a2195cffecc%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/a7b91aa5-c26d-496b-ae1a-95fb5dd42d84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

[Colin Alworth]

I've been over your gwt-events - looked good from 30 mins or so of poking 
around, but largely copy/paste, so that makes sense right?

Removing old browsers seems reasonable - if we get issues filed asking for 
old browser support, we can deal with that as needed, but these are meant 
to be modern builds of modules that still have support for old browsers. 
GWT 3 won't support the modern browsers, and even IE11 doesn't support 
Promises, so implementing Scheduler.scheduleFinally might not be possible 
without JSNI and $entry anyway... That's always been my understanding of 
the approach at least.

I'll read those other three today, but if the tests pass and the API holds 
(aside from renaming packages), it sounds like they could already be out 
there and ready for use ;). So what's the holdup? I'm being facetious, but 
I'm hoping we can make a plan that even we active contributors can follow, 
and set an easy example for others to follow.

That said, with Jens's reply in mind: If we want a CLA for projects that 
get under gwtproject.org, if we want strict code review (though I did put 
the checkstyle in my sample project), I'm going to advocate strongly for 
individual projects and personal groupIds to start with, until people who 
want to build that process are happy with it and have it deployed. The 
downside of having strict standards seems clear: not even active 
contributors are trying to meet them. At least Git gives us the ability to 
look back in history, and see where code came from in an external project, 
make sure everyone is on board with moving to gwtproject.

On Wednesday, November 15, 2017 at 11:14:34 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote:
>>
>> Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
>> projects so far in their own repos, and not in github.com/gwtproject - I 
>> was following that example. If you guys are ready to move them now and ship 
>> them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
>> objection.
>>
>> My main goal was to lower the barrier to entry - if we don't ship things 
>> that aren't under gwtproject, and we don't even put *our own projects* 
>> on gwtproject, I was concerned about how this might look to external 
>> contributors, especially given how many small projects we're going to need 
>> to have started and finished in the near future. 
>>
>> If you guys can move your projects and get them out on central,
>>
>
> I'd prefer if someone reviewed them before (particularly gwt-events; 
> gwt-http, gwt-window and gwt-history have nothing controversial in there 
> IIRC, except maybe for the fact I removed support for "old browsers" –they 
> should theoretically work in IE10+, Firefox ESR, and evergreen browsers).
> Also wrt the choice of groupId and artifactId.
> If you'd prefer that I don't wait before I move them, that works for me; 
> but I'd rather have a second pair of (critical) eyes look at the code 
> before I push anything to Central (btw, we need to ask Sonatype OSSRH for 
> the org.gwtproject groupId, and grant release rights to a few people; who 
> does that?)
>
> I'll change my yet-unpublished advice to be "start the project in your own 
>> repo, and ask it be moved once it is ready" or perhaps "ask for a new repo 
>> to be created in gwtproject, then push your sources there in a large pull 
>> request"?
>>
>
> I'd rather go for the second advice then.
>
> (fwiw, I tried to follow your yet-unpublished blog post for gwt-http, 
> gwt-window and gwt-history, and have it show clearly and cleanly in the 
> commit history; it took some time but at least they can serve as examples)
>

-- 
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/ac438217-1e68-4d98-9b4f-b53fded66538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

[Colin Alworth]

Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
projects so far in their own repos, and not in github.com/gwtproject - I 
was following that example. If you guys are ready to move them now and ship 
them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
objection.

My main goal was to lower the barrier to entry - if we don't ship things 
that aren't under gwtproject, and we don't even put *our own projects* on 
gwtproject, I was concerned about how this might look to external 
contributors, especially given how many small projects we're going to need 
to have started and finished in the near future. 

If you guys can move your projects and get them out on central, I'll change 
my yet-unpublished advice to be "start the project in your own repo, and 
ask it be moved once it is ready" or perhaps "ask for a new repo to be 
created in gwtproject, then push your sources there in a large pull 
request"?

-- 
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/7e14e048-a2ba-4d56-b314-909a19cc55b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Deploying to org.gwtproject.* groupId

[Colin Alworth]

 I'm about to put out a blog post with a bunch of details on how one might 
port gwt-user.jar modules out (thanks to the hard work of those who have 
started this effort already, especially Dan Kurka and Thomas Broyer), and 
once those are ready to be consumed, we'll certainly want the various 
artifacts on maven central. The goal in this is to start motivating 
contributors and community members to assist in the migration work 
necessary to get us within reach of a GWT 3 ecosystem.

The topic of "where we deploy early efforts" has come up a few times behind 
relatively closed doors - multiple times in steering calls, and of course 
at length at GwtCon this year. So, opening it up for broad discussion: 
should we expect to start pushing release to org.gwtproject.* right away, 
and if not, are we encouraging individual contributors to push to their own 
groupIds until we *are* ready?

Case for org.gwtproject: "centralized" jenkins server with creds to push, 
making it easy to add a project (automatically?) and get it out there so 
others can use it. Might want some manual checks on what is going out (or 
else whoever is responsible for the groupId will look silly if it turns out 
we are shipping malware), which implies full or partial review (manual 
process) of each release before pushing the button. Makes it clear right 
away to people searching maven central that they have found the right new 
modules, since they are all under the org.gwtproject umbrella.

Case for individual groupIds: makes it clear to early adopters that these 
are "incubator" projects, and they should probably vet them themselves, or 
they are relying on the community and goodwill of other developers, and 
that these migrated modules are *not* official - at least not yet. Lower 
friction, gets snapshots and releases out faster.

No matter how we go, I am certain that we'll want to push to org.gwtproject 
once these modules are stabilizing and we (gwt maintainers and 
contributors) are confident in the code being shipped. 

Thoughts? Which ever way we go, I'd like to see the already ready-for-use 
artifacts deployed within a few days - if that is too soon for 
org.gwtproject, then I think that makes the choice clear, or else who knows 
how long we'll be waiting.

-- 
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/88b63997-3178-4d63-9f32-61cf531461c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT csrf protection EXPERIMENTAL methods

[Colin Alworth]

To answer the original question, no - no changes are planned in the Xsrf 
variants of generator-based RPC. We should remove those comments. I am 
aware of no reason to not use the Xsrf variants in production code.

Looking forward, beyond gwt-user.jar, I have the core of RPC working 
correctly in Annotation Processors (i.e. so that it is compatible with GWT 
3). I do not have the equivalent of RemoteService ready yet, but when I get 
there I will make sure tools are available akin to XsrfProtectedService. 
However, while migration should be minimal to this updated version, it will 
not be zero - at the very least a different servlet will be required, and a 
constructor call instead of GWT.create.

-- 
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/12402d44-1c27-459f-9b11-4c8665f00b0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] GWT 2.8.2 release

[Colin Alworth]

Today we released the next version of GWT, version 2.8.2. A few quick 
highlights from this new release:

   - GWT can now run on Java 9 (though Java 9 features are not yet 
   supported, coming soon!)
   - Chrome 61 change in getAbsoluteTop/Left has been fixed
   - Errors on the page reported from window.onerror are now reported to 
   your uncaught exception handler
   - GWT now generates CSP compliant dom elements

The release notes can be found at 
http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_2. Get yours 
from Maven Central, or from the zip release .
Special thanks to Max Barkley of RedHat who helped lead the release effort 
this time, and to all of the fantastic testers who helped us ensure that 
this release was ready to go.

-- 
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/c22fab4d-87ee-4c75-a49a-460cdc6ac3a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

On Wed, Oct 11, 2017, at 02:01 PM, 'Goktug Gokdogan' via GWT Contributors 
wrote:> 
> PS: pls avoid the urge to discuss technical stuff in steering commitee
> and try to keep it in the contributor list ;)
If we could get the monthly (weekly?) contrib calls going again so we
have someone to pick their brains, that would help a lot. Emails work,
but a lot of this is far faster to solve and pass around in bursty low-
latency discussion.
Make them 15 minutes, officially, and of folks have time to stick around
longer, great?
Alternatively, gitter.im/gwtproject/gwt is extremely active, and only
missing representation from google. LIkewise could schedule some time to
quickly discuss things.
Otherwise it all ends up in private IMs and hangouts, opaque to the rest
of the world. Of course, a cynic might suggest that this has been the
M.O. of gwt development even since the tool was open sourced... Do
notice how light on details the original email in this thread was (and
incorrect, too, based on the work Thomas and I have done since).

-- 
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/1507749348.1785788.1135633168.03C3AE58%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Patch is accepted and merged into upstream HtmlUnit, see
https://sourceforge.net/p/htmlunit/bugs/1924/ for more detail.
Daniel, when you can take a look at Thomas's question, we can get this
change made to open source GWT as you requested.

-- 
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/1507651680.2148273.1134128816.6B394BE1%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Like we do for
com.google.gwt.junit.RunStyleHtmlUnit.HostedJavaScriptEngine so we can
hook in the "plugin". Looks like that idea might be a winner! Just make
sure to swap it in both cases, don't want to kill tests in old dev mode.

-- 
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/1507388064.2777465.1131047224.1BEFE507%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Exactly - I wasn't planning on adding the javaToJs(), but was going to 
unwrap the exception before calling onerror (or have ScriptException 
implement Scriptable). Have a short test that demonstrates the issue 
without gwt (but wow they have a lot of GWT in their source tree), and am 
was waiting for my svn->git sync to finish to confirm what you did by hand. 
Just in case we decide to rebase it along, or make other improvements down 
the road...

-- 
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/46ee5450-a14f-4a0f-a4c9-302d5a4c1709%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

It was not my intention to get this into 2.8.2, but to wait for 2.9. If
we think it is important enough, I can look into it, but I figure we
have to draw the line somewhere...

-- 
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/1507316699.1518390.1130428640.1A4FAD8C%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Okay, I'm about 80% sure that I understand and can remedy the problem 
within HtmlUnit itself. Will update once I finish syncing the apparently 
canonical SVN repo to git, so I can go over the history more carefully and 
ensure that this break isn't deliberate.

A question for my fellow GWT maintainers: should I patch the version of 
HtmlUnit that we presently use, so that we avoid breaking downstream 
expectations (plugins that specify specific browsers, use if IE8 or IE11 as 
a user agent to run the tests as)? Or should I see about getting this patch 
into the next version of HtmlUnit, and we wait on their release cycle, and 
leave this broken until then?

-- 
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/7647939e-7606-4697-84f7-da4f79f07aed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Good news is that getting past the failed to start shell issue isn't that 
bad, mostly transitive dependency changes (man there are times I love 
maven, mostly when I'm not using it...), but also losing the ability to run 
tests in IE8, IE11. Not sure that is a great loss.

Bad news is that it doesn't help - the same errors still happen, the same 
tests still fail.

Patch from current HEAD and logs of failures in 
GWTTestCaseSetupTearDownTest (the only one I ran as a representative 
example) are attached if anyone wants to eyeball it quick, see if I did 
anything too dumb.

With that out of the way, I'll try to understand the root issue, see if I 
can't figure out what has changed in HtmlUnit that causes this. Failing 
that, I'll roll back to the older jetty/htmlunit, and hopefully that will 
jog something loose in my head.

-- 
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/4bd5c079-c06a-46ae-8f92-fdb89161dccd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Testsuite: com.google.gwt.junit.client.GWTTestCaseSetupTearDownTest
Tests run: 7, Failures: 3, Errors: 2, Skipped: 0, Time elapsed: 28.256 sec
- Standard Output ---
Logging initialized @1669ms
jetty-9.2.z-SNAPSHOT
Started 
c.g.g.j.@358ee631{/,file:/Users/colin/workspace/gwt/build/out/user/test/web-htmlunit/www/,AVAILABLE}{/Users/colin/workspace/gwt/build/out/user/test/web-htmlunit/www}
Started ServerConnector@2448bc21{HTTP/1.1}{0.0.0.0:64644}
Started @2300ms
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: 
junit.framework.AssertionFailedError: testSetUpTearDownFailAsync (script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)#346) of class com.gargoylesoftware.htmlunit.ScriptException 
where it expected String, Number, Boolean or Scriptable instance. Please check 
your code for missing Context.javaToJS() call.] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[56] lineSource=[null] lineOffset=[0]
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: 
junit.framework.AssertionFailedError: testSetUpTearDownFailAsync (script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)#346) of class com.gargoylesoftware.htmlunit.ScriptException 
where it expected String, Number, Boolean or Scriptable instance. Please check 
your code for missing Context.javaToJS() call.] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[25] lineSource=[null] lineOffset=[0]
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: 
junit.framework.AssertionFailedError: testSetUpTearDownFailAsync (script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)#346) of class com.gargoylesoftware.htmlunit.ScriptException 
where it expected String, Number, Boolean or Scriptable instance. Please check 
your code for missing Context.javaToJS() call.] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[220] lineSource=[null] lineOffset=[0]
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: 
junit.framework.AssertionFailedError: testSetUpTearDownFailAsync (script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)#346) of class com.gargoylesoftware.htmlunit.ScriptException 
where it expected String, Number, Boolean or Scriptable instance. Please check 
your code for missing Context.javaToJS() call.] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[63] lineSource=[null] lineOffset=[0]
runtimeError: message=[Java class 
"com.gargoylesoftware.htmlunit.ScriptException" has no public instance field or 
method named "__java$exception".] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[159] lineSource=[null] lineOffset=[0]
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: