Re: [gwt-contrib] Re: GWT 2.7 release plan
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 Le mercredi 8 octobre 2014 20:49:02 UTC+2, Goktug Gokdogan a écrit : There are a few things we need to do. I will talk with Andrei and see if we can make it. On Wed, Oct 8, 2014 at 7:54 AM, hyp...@donarproject.org javascript: wrote: 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 https://gwt-review.googlesource.com/#/c/3650/ Will it be possible to have it in the 2.7 realease ? Thanks Le mercredi 1 octobre 2014 21:15:26 UTC+2, Daniel Kurka a écrit : 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 -- 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 javascript:. 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 https://groups.google.com/d/msgid/google-web-toolkit-contributors/4e282093-c7f0-4b93-b802-d10002fe8af9%40googlegroups.com?utm_medium=emailutm_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/e5778288-aa66-4983-97a9-60c9f2b986da%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: GWT 2.7
Build GWT from source if you want to play around with it. You need to: 1.) mkdir gwt cd gwt 2.) git clone https://gwt.googlesource.com/gwt trunk 3.) svn checkout http://google-web-toolkit.googlecode.com/svn/tools tools 4.) cd trunk ant dist-dev This builds GWT without samples and you can then find it in trunk/build/dist/gwt-0.0.0.zip. Unzip it to a location of your choice and then add the GWT SDK to Eclipse in the Eclipse settings. Am Mittwoch, 8. Oktober 2014 18:49:30 UTC+2 schrieb Marcio Alves: Hi!, Is there a easy way to download the GWT 2.7 SDK to help with the tests? 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/e1d1ae39-69b2-4545-89ba-f2d920078607%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 release plan
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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 -- 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/82aff1f3-92ba-491c-ac10-20ab2fa3610f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 release plan
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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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:
Re: [gwt-contrib] Re: GWT 2.7 release plan
Any chance that Patch 9450 https://gwt-review.googlesource.com/#/c/9450/ for speeding up the intial start time of SDM will make it? On Thursday, 9 October 2014 15:04:21 UTC+1, Thomas Broyer 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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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
Re: [gwt-contrib] Re: GWT 2.7 release plan
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. On Thursday, 9 October 2014 16:25:37 UTC+3, 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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 -- 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/b8d11950-f32a-466a-b748-036622710c70%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 release plan
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? On Thu, Oct 9, 2014 at 8:57 AM, Leif Åstrand legi...@gmail.com wrote: 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. On Thursday, 9 October 2014 16:25:37 UTC+3, 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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 -- 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/b8d11950-f32a-466a-b748-036622710c70%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/b8d11950-f32a-466a-b748-036622710c70%40googlegroups.com?utm_medium=emailutm_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/CA%2B%2BRBT9X18-yHWp370JRRnfndkfuW1PRoPZyjJgSi-xgRis3Aw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 release plan
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 On Thu, Oct 9, 2014 at 6:57 PM, 'Brian Slesinsky' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: 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? On Thu, Oct 9, 2014 at 8:57 AM, Leif Åstrand legi...@gmail.com wrote: 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. On Thursday, 9 October 2014 16:25:37 UTC+3, 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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 -- 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/b8d11950-f32a-466a-b748-036622710c70%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/b8d11950-f32a-466a-b748-036622710c70%40googlegroups.com?utm_medium=emailutm_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/CA%2B%2BRBT9X18-yHWp370JRRnfndkfuW1PRoPZyjJgSi-xgRis3Aw%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT9X18-yHWp370JRRnfndkfuW1PRoPZyjJgSi-xgRis3Aw%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit
Re: [gwt-contrib] Re: GWT 2.7 release plan
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 On Thu, Oct 9, 2014 at 7:14 PM, 'Daniel Kurka' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: 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 On Thu, Oct 9, 2014 at 6:57 PM, 'Brian Slesinsky' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: 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? On Thu, Oct 9, 2014 at 8:57 AM, Leif Åstrand legi...@gmail.com wrote: 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. On Thursday, 9 October 2014 16:25:37 UTC+3, 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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 -- You received this message because you are subscribed to the Google Groups
Re: [gwt-contrib] Re: GWT 2.7 release plan
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) -- 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/e8edbfcc-9ba3-46b4-854a-ee9c66471c51%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 release plan
+1 for John's patch 9450 https://gwt-review.googlesource.com/#/c/9450/ ( sorry to devolve the thread into +1's ) On 9 October 2014 14:04, Thomas Broyer t.bro...@gmail.com wrote: 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) -- 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/e8edbfcc-9ba3-46b4-854a-ee9c66471c51%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/e8edbfcc-9ba3-46b4-854a-ee9c66471c51%40googlegroups.com?utm_medium=emailutm_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/CAHUxr6NceV%2BpqNcujp3L2h%2Be%2ByEq5%3D6kL3G67%3DkqzG4GENMAkg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 release plan
On Thu, Oct 9, 2014 at 7:04 AM, Thomas Broyer t.bro...@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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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. - - Issue 8613 https://code.google.com/p/google-web-toolkit/issues/detail?id=8613: Bug fix for ValuePicker - Issue 8619 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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 https://code.google.com/p/google-web-toolkit/issues/detail?id=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
Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
This is a giant change for us and we don't have a simple way to handle that even with the tooling that we have. Let's discuss this after the release cut. On Wed, Oct 8, 2014 at 9:46 PM, Colin Alworth niloc...@gmail.com wrote: On Wednesday, October 8, 2014 5:16:18 PM UTC-5, Thomas Broyer wrote: On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth nilo...@gmail.com wrote: Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass. Ha, didn't thought about subclassing w/ overriding. To pick a case at random (ahem, GXT), say you want to override UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't change that return type, since you can't override methods and return a superclass (or a subclass of the superclass). If we assume that no downstream code ever subclasses and overrides any method that returns user.client.Element, yes, we can cut over cleanly in the future, you are right. But GXT notwithstanding, the SimplePanel class is meant to be subclassed and have getContainerElement() return a different container for the child - I'd be very surprised if there is no downstream code that does this somewhere. Example: FooLib v1 is compatible with GWT 2.5, when user.client.Element was not deprecated. It has a SimplePanel subclass called HeaderPanel, which overrides getContainerElement() to return a specific child element. GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with both GWT 2.5 and 2.6. As it should be. To catch up, FooLib v2 would like to remove usages of user.client.Element, but since SimplePanel.getContainerElement() still requires that return type, it can't. The best they can do is find all cases of user.client.Element and cast up to dom.client.Element from the return value of methods like getElement() and getContainerElement(). Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are *incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 was writing the cleanest possible code (returning a deprecated type). Not ideal. Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but now has SimplePanel.getContainerElement return a supertype of user.client.Element, so subclasses are free to *further restrict* the return type (like v1/v2 is doing), or use the dom.client.Element. The v1 version will probably have issues if it uses the returned value from getContainerElement() as a user.client.Element, but v2 corrected that, so v2 now is compatible with GWT 2.6 and GWT 2.7. Win. Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, and since v2 didn't use it any more, in this regard v2 is also compatible with GWT 2.8/3.0. Of course, this won't happen, some other API detail will break, I promise (Splittable.removeReified, removed logger classes breaking .gwt.xml, required resource tags causing warnings, etc). That's basically what I said too, right? Remove all uses of user.client.Element but keep the class around (or –better IMO– move it to a gwt-user-compat.jar) for downstream libraries. Okay, call it mixed messages then. I'll update the patch to go further in this direction, so that user.client.Element exists, but is unused in 2.7, and we can kill it in the next version. Do we have a plan for a gwt-user-compat v2.7.0? Seems a bit silly to make one for a single class... On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote: On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote: Sorry for the thread necromancy, but aside from https://groups.google.com/d/topic/google-web-toolkit-contrib utors/90PSQ7wKHtI/discussion this was the only relevant existing conversation I could find on the topic. In GWT 2.6 user.client.Element was finally deprecated, though done in a way to avoid any backward compatibility breakage. For example, UiObject now has two setElement methods, one for user.client.Element and another for dom.client.Element. However, UiObject.getElement still returns user.client.Element, as do a few other methods, as of master when I write these words. I'm submitting a patch that first amends UiObject.getElement and SimplePanel. getContainerElement to return dom.client.Element. My thinking is that we need an API-breaking release which still holds user.client.Element, but doesn't actually use them, allowing downstream libraries or projects to be compatible with more than one release. The alternatives as I'm currently seeing them, after deprecating in an initial release a) force a big jump, removing all traces of user.client.Element at once, meaning a library that is compatible with 2.x may not be compatible with 2.x+1. Not ideal (as a downstream library author, who doesn't want to force users to only support a single version of GWT at a time, as bugs do happen, even in GWT), but certainly easier to maintain. b) do this
Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
On Wed, Oct 8, 2014 at 3:15 PM, Thomas Broyer t.bro...@gmail.com wrote: On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth niloc...@gmail.com wrote: Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass. Ha, didn't thought about subclassing w/ overriding. Yeah, that was the main issue I remember being concerned about. Thankfully covariant return types make it more manageable: as long as user code limits itself to: 1. Only use com.google.gwt.user.client.Element as a return type when needed for overloading a GWT-provided method, and 2. In those methods, only writes return statements in the form return DOM.asOld(...); then they'll be forwards compatible with the future GWT release that changes the return types everywhere to com.google.gwt.dom.client.Element (but keeps the user.client.Element subclass). Then finally once everyone's moved to that GWT release, user code can change user.client.Element - dom.client.Element and return DOM.asOld(...) - return ... to be forward compatible with the *next* future GWT release that removes those APIs completely. (Unfortunately like Goktug mentioned, updating Google's internal code base to meet those first two constraints is a major endeavor.) -- 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/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
I think the other (probably bigger) problem is method overloads that has Element as the parameter type instead of return type (as that is no such thing like co-variant parameter types). That means for whole story to work, every third-party library needs to do the same that we did in the SDK; provide two methods; one with the old type and another one with the new type. I am very skeptical that enough libraries had already did that which means all calls like thirdPartyLib.acceptsAnElement(widget.getElement()) will be broken if make the proposed change in this release. To summarize the current 'phased' plan; Everybody (GWT-SDK, third_party libs, end users) are basically required to follow this undocumented and not communicated giant plan where we are already about to move to the second phase with the proposed path. Everybody needs to update their code base twice (once to move the intermediate step and another one to get rid of existing code). And we are doing all of these, so that third-party libs will be able to have a version that is compatible with the intermediate state (which is probably already not feasible because they didn't provided second overloads as I explained above). Am I the only one who thinks this plan is infeasible so not worthwhile? On Thu, Oct 9, 2014 at 2:48 PM, 'Matthew Dempsky' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: On Wed, Oct 8, 2014 at 3:15 PM, Thomas Broyer t.bro...@gmail.com wrote: On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth niloc...@gmail.com wrote: Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass. Ha, didn't thought about subclassing w/ overriding. Yeah, that was the main issue I remember being concerned about. Thankfully covariant return types make it more manageable: as long as user code limits itself to: 1. Only use com.google.gwt.user.client.Element as a return type when needed for overloading a GWT-provided method, and 2. In those methods, only writes return statements in the form return DOM.asOld(...); then they'll be forwards compatible with the future GWT release that changes the return types everywhere to com.google.gwt.dom.client.Element (but keeps the user.client.Element subclass). Then finally once everyone's moved to that GWT release, user code can change user.client.Element - dom.client.Element and return DOM.asOld(...) - return ... to be forward compatible with the *next* future GWT release that removes those APIs completely. (Unfortunately like Goktug mentioned, updating Google's internal code base to meet those first two constraints is a major endeavor.) -- 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/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.com?utm_medium=emailutm_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/CAN%3DyUA18B6PddxH8G3R%2B9-9YQwHmhUyrVifDx5tLAXciKABXGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
commit d91ce52ae332a414a86016eb67147d732ecba95c
Author: Matthew Dempsky mdemp...@google.com
Date: Mon Sep 2 18:16:48 2013 -0700
Step towards eliminating com.google.gwt.user.client.Element
This commit changes all methods that used to take a user.Element to
instead take a dom.Element, while using Node.cast() to keep the return
values as user.Element and avoid breaking callers (who might try to
assign to a user.Element variable, for example).
During the *next release cycle*, it should be possible for users to
update their code the same way. *Then GWT can change its return values*
to dom.Element, users can again do the same, and finally GWT can
eliminate user.Element altogether.
Change-Id: Id793420cae4f62c39b13b6bd1b21fd3487dcd81a
diff --git a/user/src/com/google/gwt/user/client/Element.java
b/user/src/com/google/gwt/user/client/Element.java
index a8b8ca0..de9b439 100644
--- a/user/src/com/google/gwt/user/client/Element.java
+++ b/user/src/com/google/gwt/user/client/Element.java
@@ -23,7 +23,14 @@ package com.google.gwt.user.client;
* created from, and can be accessed in JavaScript code as expected. This
is
* typically done by calling methods in the
* {@link com.google.gwt.user.client.DOM} class.
+ *
+ * As of GWT 2.6, users should use {@link
com.google.gwt.dom.client.Element}
+ * instead. As an *exception*, some methods still return a
codeElement/code
+ * object for backwards compatibility (though this will change in a future
+ * release), so overriding them will require returning an
codeElement/code
+ * object too.
*/
+@Deprecated
public class Element extends com.google.gwt.dom.client.Element {
Emphasis mine, apologies to Matthew if it feels like I am twisting any
words.
On Thu, Oct 9, 2014 at 5:16 PM, 'Goktug Gokdogan' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
I think the other (probably bigger) problem is method overloads that has
Element as the parameter type instead of return type (as that is no such
thing like co-variant parameter types).
That means for whole story to work, every third-party library needs to do
the same that we did in the SDK; provide two methods; one with the old type
and another one with the new type.
I am very skeptical that enough libraries had already did that which means
all calls like thirdPartyLib.acceptsAnElement(widget.getElement()) will be
broken if make the proposed change in this release.
In theory, this has already been done after the GWT 2.6 release - since
user.client.Element was deprecated, it should be *expected* to be removed
in the next few releases, so excising it should be a priority. Given that
GWT minor releases already have a fair bit of API churn, it seems
*reasonable* to suggest that libraries will have other API breakage too,
and may not be able to span more than 2-4 minor GWT releases anyway. GXT
3.1 will work with GWT 2.6.0 until GWT 2.7.x, even with this change,
because we already cleaned all cases where user.client.Element is a
parameter, and are waiting to clean return types *after* GWT does so, but
*before* user.client.Element is actually removed. Until user.client.Element
is removed, GXT 3.1 is valid. The GXT version released after
user.client.Element return types are fixed in GWT can be valid from that
point onward.
The fact that Google hasn't kept up is the major hitch in the plan as far
as I can tell. As a downstream library, we work to keep current with latest
official release since we can't roll on using nightly builds (since our
*own* downstream users can't live with that).
To summarize the current 'phased' plan;
Everybody (GWT-SDK, third_party libs, end users) are basically required to
follow this undocumented and not communicated giant plan where we are
already about to move to the second phase with the proposed path. Everybody
needs to update their code base twice (once to move the intermediate step
and another one to get rid of existing code). And we are doing all of
these, so that third-party libs will be able to have a version that is
compatible with the intermediate state (which is probably already not
feasible because they didn't provided second overloads as I explained
above).
The alternative is that for any given API breaking change, version N works
before, and version N+1 works after, but never the twain shall meet.
Keeping in mind that this happens fairly frequently, GWT versions really
should each be major, for how much breakage happens. Stepping slowly at
least makes it *possible* to have a library span multiple versions of
compatibility, and means that it isn't required that every GWT lib affected
by a break be updated a week after a GWT release.
Am I the only one who thinks this plan is infeasible so not worthwhile?
If Google was well behaved about other API breakage, I'd have a lot more
sympathy, and to be fairer than I am being, GWT 2.7 is going to be pretty
breakage-free (just the possibility of
