GWT 2.7 release plan

[Daniel Kurka]

Hi all,

we just settled on a GWT 2.7 release plan:

 - We code freeze on October 7th and branch for GWT 2.7.

 - As soon as we have the remaining patches submitted, we put out a beta1 build, this should be no later than October 7th.

 - Putting out a beta1 externally allows us to collect feedback on the new super dev mode integration externally as well.

 - We are going to flip incremental to default tomorrow and wait for 1-2 weeks for google internal feedback, if there is no serious issues we are going to put out RC1

 - GWT 2.7 will still be compatible with Java 6.

Patches / Fixes that need to go in:

 - Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/ (dankurka)

 - Sending the wrong permutation to the client in SDM, if no files have changed (dankurka).

 - Investigate why some people are seeing errors with incremental  not restricting to one permutation (dankurka).

 - Public directories are not copied o the war directory when using SDM (skybrian).

 - Restore Java 6 compatibility (skybrian).

 - Document limitations of JsonUtils.safeEval and discourage usage (goktug) (promote Json.parse)

Patches that are nice to have:

 - Improve exception logging in SDM (goktug).

If you have any outstanding patches that you thing need to go into GWT 2.7, please bring them to our attention, by replying to this thread or adding me as a reviewer on Gerrit and setting the topic to GWT2.7.

-Daniel

[Brian Slesinsky]

- Make sure sample apps work with DevMode -superdevmode

- I think we're waiting on a patch to CLDR 25 

--
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/CALLujirrw0BL1yfX7nxLbH-yVLEofbQM%2BBn-ZtgmriuW56SMNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Julien Dramaix]

Does that mean that GssResource will not be included in GWT 2.7 ?

I've planned to work on that Friday. Create patches in order to submit the code in the gwt core but GSS needs Java 7 and you seem to say that GWT 2.7 has to support Java 6.

What is your plan with GSS ?

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT8y2fE4WQqFeXiJCVwTwD6XbdWiKrR3fH28qzMLvk0Uvg%40mail.gmail.com.

[Manuel Carrasco Moñino]

On Wed, Oct 1, 2014 at 9:23 PM, 'Brian Slesinsky' via GWT Contributors <google-web-tool...@googlegroups.com> wrote:

- Make sure sample apps work with DevMode -superdevmode

I'm planing to do a exhaustive testing this week and verify that last changes are reliable enough.

 

- I think we're waiting on a patch to CLDR 25 

Patch is ready for review. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT8y2fE4WQqFeXiJCVwTwD6XbdWiKrR3fH28qzMLvk0Uvg%40mail.gmail.com.

[Daniel Kurka]

To summarize the discussion I had with Julien over hangouts:

We are not going to require Java 7 for GWT 2.7 since we can not make GSS default in GWT 2.7 (or we do have to postpone the release).

We will try to get GSS into GWT master and make it available as an experimental feature in GWT 2.7 which will require Java 7 (if you use it).

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D7a4S4F8hrxNhSfjKTCxLRx299cwMvxtKGVssAHpRowqA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Google Germany GmbH

Dienerstr. 12
80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

[Cristian Rinaldi]

- JsInterop Preview is part of the release?

[Brian Slesinsky]

It's experimental and hidden behind a flag, but it's there.

--
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/1d5a4369-e03d-47ba-b8dd-5031e5460751%40googlegroups.com.

[Manuel Carrasco Moñino]

Hi, 

There are a bunch of Elemental patches which fix some issues, some of them manifested when running its test suite which was not enabled, and the others to use elemental json as a replacement of the  controversial org.json.  I know elemental 2.0 would be redesigned or rewritten for 3.0, but I think we could leave a little bit better version of elemental 1.0 in 2.7.0.

Could anyone take a look to those patches? There is no official maintainer of it, so maybe Ray is the most suitable reviewer?

Thanks

- Manolo

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT-M5mAXmj5Ox8iQihjzFFinLM%2Bc57tmdD1JGwEMxKJHAw%40mail.gmail.com.

[Goktug Gokdogan]

On Thu, Oct 2, 2014 at 12:41 AM, Manuel Carrasco Moñino <man...@apache.org> wrote:

Hi, 

There are a bunch of Elemental patches which fix some issues, some of them manifested when running its test suite which was not enabled, and the others to use elemental json as a replacement of the  controversial org.json.  I know elemental 2.0 would be redesigned or rewritten for 3.0, but I think we could leave a little bit better version of elemental 1.0 in 2.7.0.

Could anyone take a look to those patches? There is no official maintainer of it, so maybe Ray is the most suitable reviewer?

Ray might not have the time. I'm proposing t.broyer to approve these changes.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAvDLRsQFsWV320q2%3Dpvw_oH46N47OvcpCp%3D07wkYbMhgw%40mail.gmail.com.

[confile]

How can  JsInterop be activated in GWT 2.7? What flag does it?

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[John Stalcup]

-XjsInteropMode JS

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/48e8f729-b645-4534-af9d-c5a9947dffd2%40googlegroups.com.

[confile]

I miss the following sources in the current GWT 2.7 SnapShot: 

com.google.gwt.user.client.impl.HistoryImpl

Why is this missing?

[confile]

What is the difference between -XjsInteropMode JS and -XjsInteropMode CLOSURE?

-XjsInteropMode JS

[confile]

Code size explodes when using GWT 2.7 with -XjsInteropMode JS 

I compiled the same code with GWT 2.6.1 and GWT 2.7 with argument strict

code size GWT 2.6.1 1.351 MB

code size  GWT 2.7  1.361 MB

Then I compiled the same code with -XjsInteropMode JS flag on GWT 2.7

code size  1.601 MB

Why does GWT 2.7 increases the code size in every case and with Interop even by 300 kb?

[Александр Новоселов]

Will you update to Jetty 9.2 (with JVM 8 support)?

Any link to branch version?

[Manuel Carrasco Moñino]

1.- History mechanism has changed in 2.7 to fulfil modern standards https://gwt-review.googlesource.com/#/c/5356/.  BTW: you should't use HistoryImpl and in general any Impl class, in general they are private API

2.- Use -XjsInteropMode  ONLY in the case that you have a need for exporting gwt classes to JS or wrapping JS classes in gwt. Otherwise you could have a increment of size and probably other issues. It is experimental, even in 2.7.0, so don't use it for production or be prepared to changes and breakages

3.- Code sizes in 2.6 and 2.7 should be very similar, but there are changes in many places, so little differences are acceptable. Update to a new version does not necessary bring a reduction on code size, but other improvements.

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/fc3a33e8-dc46-4c3f-a22b-9d3b96362a11%40googlegroups.com.

[confile]

Well, I need to override HistoryImpl to enable HTML5 pushstate api.

[Manuel Carrasco Moñino]

There is no plans to upgrade Jetty. It implies some changes in JettyLauncher and WebServer, I have already a patch for that but not committed yet because I have not tested enough. If someone else demands it we could consider to upgrade it.

Anyway I think it should be nice not to bundle jetty in the .jar deployed in maven repos, but set it as a dependency so as it's easier to experiment other versions.

On Fri, Oct 3, 2014 at 10:44 AM, Александр Новоселов <qui...@gmail.com> wrote:

Will you update to Jetty 9.2 (with JVM 8 support)?

Any link to branch 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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ad0b7807-4da7-4a83-844d-dae11c3c786f%40googlegroups.com.

[Manuel Carrasco Moñino]

On Fri, Oct 3, 2014 at 4:05 PM, confile <michael....@googlemail.com> wrote:

Well, I need to override HistoryImpl to enable HTML5 pushstate api.

HistoryImpl is now a private class inside History, maybe we could discuss whether to change its visibility. Maybe @Daniel could help here.

 

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/63f3473d-e73a-467d-adcb-64242f984202%40googlegroups.com.

[Thomas Broyer]

On Friday, October 3, 2014 4:09:33 PM UTC+2, Manuel Carrasco Moñino wrote:

On Fri, Oct 3, 2014 at 4:05 PM, confile <michael.gorski82@googlemail.com> wrote:

Well, I need to override HistoryImpl to enable HTML5 pushstate api.

HistoryImpl is now a private class inside History, maybe we could discuss whether to change its visibility. Maybe @Daniel could help here.

When Daniel proposed the change, we decided it was OK to break compatibility with, say, Johannes Barop's gwt-pushstate. The rationale was that History was explicitly about using the "hash" part of the URL and if you wanted something else, or a pluggable implementation, you should use another API (Places are pluggable, and you could easily build another API similar to History but that would operate differently, whether pluggable or not).

AFAICT the whole discussion is in the review you linked to (or possibly another one, as there had been several tries IIRC)

[confile]

Well if you do not use Places for example when you use GWTP you need the HistoryImpl to make GWT-pushstate working.

[Richard Wallis]

Hi Thomas,

Please can you link to the discussion where you decided it was ok to break compatibility with deferred binding implementations of the HistoryImpl.

--

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/d3babcef-5e2a-4a2e-a8a2-95a3dd88531f%40googlegroups.com.

[confile]

It would be great if you describe a workaround not having HistoryImpl and using gwt-pushstate when not using places.

Am Freitag, 3. Oktober 2014 17:25:10 UTC+2 schrieb Richard Wallis:

Hi Thomas,

Please can you link to the discussion where you decided it was ok to break compatibility with deferred binding implementations of the HistoryImpl.

On Fri, Oct 3, 2014 at 5:15 PM, confile <michael....@googlemail.com> wrote:

Well if you do not use Places for example when you use GWTP you need the HistoryImpl to make GWT-pushstate working.

Am Freitag, 3. Oktober 2014 17:11:35 UTC+2 schrieb Thomas Broyer:

On Friday, October 3, 2014 4:09:33 PM UTC+2, Manuel Carrasco Moñino wrote:

On Fri, Oct 3, 2014 at 4:05 PM, confile <michael....@googlemail.com> wrote:

Well, I need to override HistoryImpl to enable HTML5 pushstate api.

HistoryImpl is now a private class inside History, maybe we could discuss whether to change its visibility. Maybe @Daniel could help here.

When Daniel proposed the change, we decided it was OK to break compatibility with, say, Johannes Barop's gwt-pushstate. The rationale was that History was explicitly about using the "hash" part of the URL and if you wanted something else, or a pluggable implementation, you should use another API (Places are pluggable, and you could easily build another API similar to History but that would operate differently, whether pluggable or not).

AFAICT the whole discussion is in the review you linked to (or possibly another one, as there had been several tries IIRC)

--
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+unsubscribe@googlegroups.com.

[Jens]

Hi Thomas,

Please can you link to the discussion where you decided it was ok to break compatibility with deferred binding implementations of the HistoryImpl.

See comments in https://gwt-review.googlesource.com/#/c/6403/ 

-- J.

[Richard Wallis]

Ok so gwt 2.7 is going to provide pushstate functionality so we don't need the 3rd party libraries?

--

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/b2d70738-bb2d-4eed-a6ea-8b5da5f08a78%40googlegroups.com.

[Jens]

It would be great if you describe a workaround not having HistoryImpl and using gwt-pushstate when not using places.

There is no real workaround other than building a class on your own that either uses GWT History for hash fragments or pushState if available. With GWT Places that would be an implementation of Historian interface.

Alternative would be to change GWT to make gwt-pushstate library work again.

-- J.

[Jens]

Ok so gwt 2.7 is going to provide pushstate functionality so we don't need the 3rd party libraries?

 It only uses pushState internally and does not expose any API for it. So no, you would still need a library or JSNI to use pushState.

-- J.

[Richard Wallis]

Can you not define an interface for HistoryImpl so that we can replace it while you still keep your implementation private?

--

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/7e26d28b-15cf-497d-b8ae-1deaaf2d7c51%40googlegroups.com.

[confile]

I do support Richard's idea.

Am Freitag, 3. Oktober 2014 18:19:30 UTC+2 schrieb Richard Wallis:

Can you not define an interface for HistoryImpl so that we can replace it while you still keep your implementation private?

On Fri, Oct 3, 2014 at 5:52 PM, Jens <jens.ne...@gmail.com> wrote:

Ok so gwt 2.7 is going to provide pushstate functionality so we don't need the 3rd party libraries?

 It only uses pushState internally and does not expose any API for it. So no, you would still need a library or JSNI to use pushState.

-- 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+unsubscribe@googlegroups.com.

[Thomas Broyer]

On Friday, October 3, 2014 6:19:30 PM UTC+2, Richard Wallis wrote:

Can you not define an interface for HistoryImpl so that we can replace it while you still keep your implementation private?

No, because we specifically don't want to make it a "public API" where we have to maintain backwards compatibility.

[Thomas Broyer]

On Friday, October 3, 2014 5:15:51 PM UTC+2, confile wrote:

Well if you do not use Places for example when you use GWTP you need the HistoryImpl to make GWT-pushstate working.

As far as I can see form the code, GWTP's PlaceManager is pluggable (sort-of) and could probably replaced with a version that uses pushstate (in JSNI) without using the URL's #hash

 

[confile]

Okay I get your point. Could you please provide some kind of workaround?

Thank you

Michael

[Thomas Broyer]

On Friday, October 3, 2014 4:06:01 PM UTC+2, Manuel Carrasco Moñino wrote:

There is no plans to upgrade Jetty. It implies some changes in JettyLauncher and WebServer, I have already a patch for that but not committed yet because I have not tested enough. If someone else demands it we could consider to upgrade it.

AFAIK, we can't update Jetty to 9.x because HTMLUnit (used for JUnitShell/GWTTestCase) depends on Jetty 8.x APIs (WebSockets)

There's been a patch proposed already and it has been abandoned because of that.

 

Anyway I think it should be nice not to bundle jetty in the .jar deployed in maven repos, but set it as a dependency so as it's easier to experiment other versions.

It could possibly help with some setups but I doubt it'd be that useful.

If we had a modularized GWT then you could avoid depending on gwt-junit, gwt-devmode-jettylauncher and gwt-codeserver (e.g. when compiling) and live with Jetty 9.x dependencies in your classpath/buildpath, or we could possibly provide a gwt-codeserver and/or gwt-devmode-jettylauncher using using Jetty 9.x; so you'd use Jetty 8.x with gwt-junit to run your unittests, and you could use Jetty 9.x in DevMode/superDevMode (and benefit from Jetty 9.x perf improvements for gwt-codeserver?)

It's not possible with our current monolithic artifacts (and build) though.

[Richard Wallis]

Ok the Historian interface looks like it will solve our issues.  I'll rewrite GWTP's PlaceManagerImpl to use it and update my pushstate implementation.

--

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/d22e2d8b-0bf1-4f17-9805-9fdb944076f5%40googlegroups.com.

[Manuel Carrasco Moñino]

Thanks for the info Thomas, I din't  realise that patch.

On Fri, Oct 3, 2014 at 6:34 PM, Thomas Broyer <t.br...@gmail.com> wrote:

--

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/d22e2d8b-0bf1-4f17-9805-9fdb944076f5%40googlegroups.com.

[confile]

@Richard Wallis Could you please publish your updated pushstate implementation?

Thank you 

Michael

Am Freitag, 3. Oktober 2014 18:51:51 UTC+2 schrieb Richard Wallis:

Ok the Historian interface looks like it will solve our issues.  I'll rewrite GWTP's PlaceManagerImpl to use it and update my pushstate implementation.

On Fri, Oct 3, 2014 at 6:34 PM, Thomas Broyer <t.br...@gmail.com> wrote:

On Friday, October 3, 2014 4:06:01 PM UTC+2, Manuel Carrasco Moñino wrote:

There is no plans to upgrade Jetty. It implies some changes in JettyLauncher and WebServer, I have already a patch for that but not committed yet because I have not tested enough. If someone else demands it we could consider to upgrade it.

AFAIK, we can't update Jetty to 9.x because HTMLUnit (used for JUnitShell/GWTTestCase) depends on Jetty 8.x APIs (WebSockets)

There's been a patch proposed already and it has been abandoned because of that.

 

Anyway I think it should be nice not to bundle jetty in the .jar deployed in maven repos, but set it as a dependency so as it's easier to experiment other versions.

It could possibly help with some setups but I doubt it'd be that useful.

If we had a modularized GWT then you could avoid depending on gwt-junit, gwt-devmode-jettylauncher and gwt-codeserver (e.g. when compiling) and live with Jetty 9.x dependencies in your classpath/buildpath, or we could possibly provide a gwt-codeserver and/or gwt-devmode-jettylauncher using using Jetty 9.x; so you'd use Jetty 8.x with gwt-junit to run your unittests, and you could use Jetty 9.x in DevMode/superDevMode (and benefit from Jetty 9.x perf improvements for gwt-codeserver?)

It's not possible with our current monolithic artifacts (and build) though.

--
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+unsubscribe@googlegroups.com.

[Richard Wallis]

Ok, I'll be publishing it here: https://github.com/rdwallis/gwt-pushstate probably early next week.

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/2560e5b0-6f75-4580-b75b-435bd04296b1%40googlegroups.com.

[Colin Alworth]

https://code.google.com/p/google-web-toolkit/issues/detail?id=8716 is still open (and is a regression over GWT 2.6 and previous). Is this a reasonable item to get fixed?

On Wednesday, October 1, 2014 2:23:43 PM UTC-5, Brian Slesinsky wrote:

- Make sure sample apps work with DevMode -superdevmode

- I think we're waiting on a patch to CLDR 25 

[Thomas Broyer]

If you need an Historian implementation that uses pushstate, have a look at https://gist.github.com/tbroyer/1883821

Used in production for quite some time in a project at work (though limited to Firefox ESR clients; it's in an intranet/extranet context)

On Friday, October 3, 2014 6:51:51 PM UTC+2, Richard Wallis wrote:

Ok the Historian interface looks like it will solve our issues.  I'll rewrite GWTP's PlaceManagerImpl to use it and update my pushstate implementation.

On Fri, Oct 3, 2014 at 6:34 PM, Thomas Broyer <t.br...@gmail.com> wrote:

On Friday, October 3, 2014 4:06:01 PM UTC+2, Manuel Carrasco Moñino wrote:

There is no plans to upgrade Jetty. It implies some changes in JettyLauncher and WebServer, I have already a patch for that but not committed yet because I have not tested enough. If someone else demands it we could consider to upgrade it.

AFAIK, we can't update Jetty to 9.x because HTMLUnit (used for JUnitShell/GWTTestCase) depends on Jetty 8.x APIs (WebSockets)

There's been a patch proposed already and it has been abandoned because of that.

 

Anyway I think it should be nice not to bundle jetty in the .jar deployed in maven repos, but set it as a dependency so as it's easier to experiment other versions.

It could possibly help with some setups but I doubt it'd be that useful.

If we had a modularized GWT then you could avoid depending on gwt-junit, gwt-devmode-jettylauncher and gwt-codeserver (e.g. when compiling) and live with Jetty 9.x dependencies in your classpath/buildpath, or we could possibly provide a gwt-codeserver and/or gwt-devmode-jettylauncher using using Jetty 9.x; so you'd use Jetty 8.x with gwt-junit to run your unittests, and you could use Jetty 9.x in DevMode/superDevMode (and benefit from Jetty 9.x perf improvements for gwt-codeserver?)

It's not possible with our current monolithic artifacts (and build) though.

--
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+unsubscribe@googlegroups.com.

[confile]

I tested JSInterop a lot. According to the design document you could do something like: 

@JsType
interface MyJsInterface {
  void callMeLater(@Entry Callback x);
}

 

But, the @Entry annotation is not available.

[confile]

Hi Daniel,

this issue (https://code.google.com/p/google-web-toolkit/issues/detail?id=8938) should be included in GWT 2.7.

Best

Michael

[hyp...@donarproject.org]

Hi,

thank you all for your hard work. We have been using GWT and SDM with great success in a big financial software company :).

There is one major feature that is still not merged : NavigableMap

Will it be possible to have it in the 2.7 realease ? 

Thanks

[Goktug Gokdogan]

There are a few things we need to do. I will talk with Andrei and see if we can make 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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4e282093-c7f0-4b93-b802-d10002fe8af9%40googlegroups.com.

[hyp...@donarproject.org]

Hi,

we currently have a jenkins job that checks out the gwt code from github, applies the patch and build GWT.

FYI, we did not have any issue regarding this patch for more than a year.

It would be awesome to be using an official release of GWT.

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Daniel Kurka]

We are making steady progress towards GWT 2.7. At this point we are not accepting any new patches, but we still have a list of issues that we would like to include in the upcoming release. This is no guarantee that all of them are going to make it but we are trying our best. Also we are holding off committing any risky patches to master until we have cut the GWT 2.7 release branch. I'll ping back GWT contributors once we have done that. Please do not commit any patches that do not need to go in.

• Issue 8762: Migration to android.json from org.json not being complete (Current patch). Deploy a com.google.gwt.org.json version based of android that the GWT SDK can depend on and update the pom of the SDK to use it. Include a warning in the release notes about small the very small incompatibilities between the two.
  
• Issue 8613: Bug fix for ValuePicker
  
• Issue 8619: Super dev mode can fail to start on windows if previous dirs are still locked. SDM will skip deletion of dirs on windows if it fails and emit a warning. (skybrian)
  
• Issue 8716: Package names can collide with class names on case insensitive file system. John will come up with a fix for GWT 2.7 if it is not to hard to do (stalcup).
  
• Issue 8938: GWT RPC base url is not set correctly for all cases in SDM recompiles. dankurka will update the implementation to include a full computeScriptBase implementation.
  
• GWT RPC policy files should be written to -launcherDir so that the normal server can use them easily (skybrian)
  
• verify sample apps are actually compiling in SDM (since it is now default) (dankurka)
  
• remove generation of SDM targets in samples since it is now default (skybrian)
  
• John found two small issues in incremental. These need to be fixed for GWT 2.7 (stalcup & rluble)
  
• Exception links in the chrome dev tools are not clickable (goktug)
  
• Issue 4236: NavigatableMap: We would like to include this in GWT 2.7, but it needs more testing. Ask Andrei to copy all apache testcases and make them work, then we include it in GWT 2.7 (goktug)
  
• Removing IE6 references in the code base (niloc)

-Daniel

[Thomas Broyer]

On Thursday, October 9, 2014 3:25:37 PM UTC+2, Daniel Kurka wrote:

We are making steady progress towards GWT 2.7. At this point we are not accepting any new patches, but we still have a list of issues that we would like to include in the upcoming release. This is no guarantee that all of them are going to make it but we are trying our best. Also we are holding off committing any risky patches to master until we have cut the GWT 2.7 release branch. I'll ping back GWT contributors once we have done that. Please do not commit any patches that do not need to go in.

• Issue 8762: Migration to android.json from org.json not being complete (Current patch). Deploy a com.google.gwt.org.json version based of android that the GWT SDK can depend on and update the pom of the SDK to use it. Include a warning in the release notes about small the very small incompatibilities between the two.

The warning should also point out that this dependency will collide with org.json:json if the project depends on it, so one of the dependencies will have to be chosen and the appropriate exclusion added to the POM (or whatever your build tool uses: build.gradle, etc.)

 

• 
  
• Issue 8613: Bug fix for ValuePicker
  
• Issue 8619: Super dev mode can fail to start on windows if previous dirs are still locked. SDM will skip deletion of dirs on windows if it fails and emit a warning. (skybrian)
  
• Issue 8716: Package names can collide with class names on case insensitive file system. John will come up with a fix for GWT 2.7 if it is not to hard to do (stalcup).
  
• Issue 8938: GWT RPC base url is not set correctly for all cases in SDM recompiles. dankurka will update the implementation to include a full computeScriptBase implementation.
  
• GWT RPC policy files should be written to -launcherDir so that the normal server can use them easily (skybrian)
  
• verify sample apps are actually compiling in SDM (since it is now default) (dankurka)
  
• remove generation of SDM targets in samples since it is now default (skybrian)
  
• John found two small issues in incremental. These need to be fixed for GWT 2.7 (stalcup & rluble)
  
• Exception links in the chrome dev tools are not clickable (goktug)
  
• Issue 4236: NavigatableMap: We would like to include this in GWT 2.7, but it needs more testing. Ask Andrei to copy all apache testcases and make them work, then we include it in GWT 2.7 (goktug)
  
• Removing IE6 references in the code base (niloc)

Setting up Tracis CI for the gwt-maven-plugin today, I just noticed that we're no longer compatible with OpenJDK 6. I, for one, really don't care, but we'd decided that 2.7 would still be compatible with Java 6 IIRC (that was an issue with GSS which requires Java 7).

This is due to regexps, a change Roberto introduced a few days ago, and already tweaked to avoid stack overflow. Maybe the regexps are OK with Oracle JDK 6 (for those with extended support) or other JDKs (IBM?) though.

The error:

[INFO]    Invoking Linker Cross-Site-Iframe

[INFO]       [ERROR] Failed to link

[INFO] java.lang.ExceptionInInitializerError

[INFO]  at com.google.gwt.core.ext.linker.impl.SelectionScriptLinker.generatePrimaryFragmentString(SelectionScriptLinker.java:394)

[INFO]  at com.google.gwt.core.ext.linker.impl.SelectionScriptLinker.generatePrimaryFragment(SelectionScriptLinker.java:380)

[INFO]  at com.google.gwt.core.ext.linker.impl.SelectionScriptLinker.doEmitCompilation(SelectionScriptLinker.java:245)

[INFO]  at com.google.gwt.core.ext.linker.impl.SelectionScriptLinker.link(SelectionScriptLinker.java:196)

[INFO]  at com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:381)

[INFO]  at com.google.gwt.dev.Link.finishPermutation(Link.java:489)

[INFO]  at com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:450)

[INFO]  at com.google.gwt.dev.Link.link(Link.java:182)

[INFO]  at com.google.gwt.dev.Compiler.run(Compiler.java:244)

[INFO]  at com.google.gwt.dev.Compiler.run(Compiler.java:156)

[INFO]  at com.google.gwt.dev.Compiler$1.run(Compiler.java:118)

[INFO]  at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:55)

[INFO]  at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:50)

[INFO]  at com.google.gwt.dev.Compiler.main(Compiler.java:125)

[INFO] Caused by: java.util.regex.PatternSyntaxException: Look-behind group does not have an obvious maximum length near index 121

[INFO] (?>[^"/]|/[^/*]|(?>/\*(?>[^*]|\*[^/])*?\*/)|(?>"(?>[^"\\]|(?>\\.))*?")|(?>/(?>[^/\\]|\\.)+/))*?(?<trailing>(?<single>//.*?)|(?<block>/\*(?>[^*]|\*[^/])*?))

[INFO]                                                                                                                          ^

[INFO]  at java.util.regex.Pattern.error(Pattern.java:1730)

[INFO]  at java.util.regex.Pattern.group0(Pattern.java:2505)

[INFO]  at java.util.regex.Pattern.sequence(Pattern.java:1823)

[INFO]  at java.util.regex.Pattern.expr(Pattern.java:1769)

[INFO]  at java.util.regex.Pattern.group0(Pattern.java:2500)

[INFO]  at java.util.regex.Pattern.sequence(Pattern.java:1823)

[INFO]  at java.util.regex.Pattern.expr(Pattern.java:1769)

[INFO]  at java.util.regex.Pattern.compile(Pattern.java:1477)

[INFO]  at java.util.regex.Pattern.<init>(Pattern.java:1150)

[INFO]  at java.util.regex.Pattern.compile(Pattern.java:840)

[INFO]  at com.google.gwt.dev.js.JsSourceUtils.<clinit>(JsSourceUtils.java:66)

[INFO]  ... 14 more

[Seamus McMorrow]

Any chance that Patch 9450 for speeding up the intial start time of SDM will make it?

[Leif Åstrand]

Lots of Elemental patches have been merged in the last few days, but we do still have a short list that would be nice to get included. 

https://gwt-review.googlesource.com/#/c/9098/

https://gwt-review.googlesource.com/#/c/9099/

https://gwt-review.googlesource.com/#/c/9095/

The code appears to be in good shape, so it only remains for someone with appropriate authority to decide whether the changes are wanted.

[Brian Slesinsky]

I think this is okay as long as it doesn't cause tests to fail. Elemental is quite separate from everything else so it seems low risk. Daniel?

--

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/b8d11950-f32a-466a-b748-036622710c70%40googlegroups.com.

[Daniel Kurka]

I think this call is up to the elemental maintainers (manolo & thomas), if it breaks any tests I will roll it back since we need a green build to be able to branch.

-Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT9X18-yHWp370JRRnfndkfuW1PRoPZyjJgSi-xgRis3Aw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Google Germany GmbH

Dienerstr. 12
80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

[Manuel Carrasco Moñino]

Well, actually there is no official maintainer for elemental, so Ray would be the most suitable since he introduced elemental to GWT, but as Goktug said in this thread, he might not have enough time.

What I've tried to do in my patches is to make the existent elemental test suite run and pass. The suite was never included in our build scripts and in fact, lately it didn't compile.

Now we have the suite being run in each build and, even there is patch adding JRE tests for Json and Collections, because they were designed to run in either JVM and JS.

Thomas split elemental module in three, hence projects can inherit just Collections, or Json or the entire Elemental.  And Andrei fixed some tests and code as well.

The three patches Leif point to, are very useful to using elemental-json in the JVM as a replacement of the controversial org.json, and now with the test running is much safer to include them.

So if there are no objections, I vote to include those three patches and jre tests if Thomas agrees, who probably is the maintainer more familiar with Elemental.

- Manolo

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiqkmj48N_YK2VCJB9PaU4dzhwrDdjojK6F3ww%2B%3D4D6i2Q%40mail.gmail.com.

[Roberto Lublinerman]

I think we will better exclude the following three patches from the release 425e0bb 2b2d81c 920ba90

I will either revert them or fix them with a better alternative. Java RegExp implementation is really rough around the edges....

--
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/435b76a2-6232-47e4-9ab9-cc8f2488ee84%40googlegroups.com.

[Thomas Broyer]

On Thursday, October 9, 2014 10:43:38 PM UTC+2, Roberto Lublinerman wrote:

I think we will better exclude the following three patches from the release 425e0bb 2b2d81c 920ba90

I will either revert them or fix them with a better alternative. Java RegExp implementation is really rough around the edges....

If Daniel creates a branch for 2.7 maybe we could revert them on the branch only? (given that the next GWT version will probably require Java 7)

[James Horsley]

+1 for John's patch 9450 ( sorry to devolve the thread into +1's )

--

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/e8edbfcc-9ba3-46b4-854a-ee9c66471c51%40googlegroups.com.

[Goktug Gokdogan]

On Thu, Oct 9, 2014 at 7:04 AM, Thomas Broyer <t.br...@gmail.com> wrote:

On Thursday, October 9, 2014 3:25:37 PM UTC+2, Daniel Kurka wrote:

We are making steady progress towards GWT 2.7. At this point we are not accepting any new patches, but we still have a list of issues that we would like to include in the upcoming release. This is no guarantee that all of them are going to make it but we are trying our best. Also we are holding off committing any risky patches to master until we have cut the GWT 2.7 release branch. I'll ping back GWT contributors once we have done that. Please do not commit any patches that do not need to go in.

• Issue 8762: Migration to android.json from org.json not being complete (Current patch). Deploy a com.google.gwt.org.json version based of android that the GWT SDK can depend on and update the pom of the SDK to use it. Include a warning in the release notes about small the very small incompatibilities between the two.

The warning should also point out that this dependency will collide with org.json:json if the project depends on it, so one of the dependencies will have to be chosen and the appropriate exclusion added to the POM (or whatever your build tool uses: build.gradle, etc.)

I just talked with closure compiler team. We might just be able to get rid of the org.json dependency. They are looking at 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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/435b76a2-6232-47e4-9ab9-cc8f2488ee84%40googlegroups.com.