Re: [gwt-contrib] Elemental2 and JsInterop base beta releases available.

[James Horsley]

Wonderful news. Thanks!

On Thu, Apr 6, 2017 at 2:47 AM David Yu  wrote:

> On Thu, Apr 6, 2017 at 5:42 AM, 'Julien Dramaix' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>
> The beta version of Elemental2 using the JsInterop specification has been
> released on Sonatype today and is available on Maven central.
>
> Better late than never I guess :-)
>
>
> This release introduces the concept of union types (which are heavily used
> in JavaScript) and many more improvements. More information about union
> types can be found in this document
> 
> .
>
>
> We also split Elemental into smaller jar files:
>
>
> Jar file
>
> artifact-id
>
> GWT module
>
> elemental2-core.jar
> 
>
> elemental2-core
>
> elemental2.core.Core
>
> elemental2-promise.jar
> 
>
> elemental2-promise
>
> elemental2.promise.Promise
>
> elemental2-dom.jar
> 
>
> elemental2-dom
>
> elemental2.dom.Dom
>
> elemental2-svg.jar
> 
>
> elemental2-svg
>
> elemental2.svg.Svg
>
> elemental2-webgl.jar
> 
>
> elemental2-webgl
>
> elemental2.webgl.WebGl
>
> elemental2-media.jar
> 
>
> elemental2-media
>
> elemental2.media.Media
>
> elemental2-indexeddb.jar
> 
>
> elemental2-indexeddb
>
> elemental2.indexeddb.IndexedDb
>
> elemental2-webstorage.jar
> 
>
> elemental2-webstorage
>
> elemental2.webstorage.WebStorage
>
>
>
> You can try them by downloading the jar files or adding Maven dependencies:
>
>
> 
>
>  com.google.elemental2
>
>  ${artifact-id}
>
>  1.0.0-beta-1
>
> 
>
>
> Then inherit the right gwt module in your gwt.xml file.
>
>
> This beta version works only with the latest HEAD_SNAPSHOT release of GWT
> 
> .
>
>
> We’ve also released a beta version of JsInterop.base. This library
> contains base classes and utilities that provide access to JavaScript
> language constructs that are not available in pure Java.
>
>
> You can try it by downloading the jar file
> 
> or use the following Maven dependency:
>
>
> 
>
>  com.google.jsinterop
>
>  base
>
>  1.0.0-beta-1
>
> 
>
>
> Don’t hesitate to report any bugs, issues, concerns you have on this
> mailing list.
>
>
> Important note: They are beta releases and future updates (up until the
> final release) may break code!
>
>
> -Julien
>
>
> --
>
> Julien Dramaix |  Software Engineer |  dram...@google.com |  650-750-6053
> <(650)%20750-6053>
>
> --
> 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/CABXeq2QsTarhDKbYmz0y1SOrjpuFNdoNmAnvAYKacO1f4rLcLg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> When the cat is away, the mouse is alone.
> - David Yu
>
> --
> 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/CAOkdovKQn1wo%2BR2jrZ3iGrh4ko199_bt6%3DUC-Xd_HYUc%2B65-Yw%40mail.gmail.com
> 

Re: Emulating CompletableFuture with Promise

[James Horsley]

This is brilliant. I would *love *to see this in GWT proper. Maybe even a
separate library temporarily since it won't make the 2.8.0 release train?

On Fri, Sep 9, 2016 at 2:41 PM Andrei Korzhevskii 
wrote:

> In this case I wanted 'new Promise', not 'Promise.resolve'. Thanks for
> spotting that out! I've updated my branch.
>
>
> On Tuesday, September 6, 2016 at 10:09:28 PM UTC+3, Ian Preston wrote:
>
>> For another hint, I think you don't want the "new" before
>> "Promise.resolve" on line 88 of impl/JsPromise :-)
>> What the best way for me to report bugs to you? A PR?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with 2.8.0 rc1 SDM

[James Horsley]

Updating gson to 2.6.x fixed it for me

On Thursday, August 11, 2016 at 10:04:44 PM UTC+1, Alberto Mancini wrote:
>
> Hello,
> in the attempt of porting an internal project from beta1 to rc1 we faced 
> an issue i do not understand how to debug. 
>
> The project uses errai but my feeling is that the problem is not related 
> to it because similar projects with errai work without problems. 
>
> Essentially SDM fails during the first compilation and the problem seems 
> in the generation of the source maps. 
>
> The relevant error log follows.
>
> [INFO] GET /recompile/it.e.u.Application
> [INFO]Job it.e.u.Application_1_0
> [INFO]   starting job: it.e.u.Application_1_0
> [INFO]   binding: user.agent=safari
> [INFO]   Compiling module it.e.u.Application
> ...
>
> [INFO]  Unification traversed 54946 fields and methods and 5256 
> types. 5210 are considered part of the current module and 5210 had all of 
> their fields and methods traversed.
> [INFO]  Compiling 1 permutation
> [INFO] Compiling permutation 0...
> [INFO] Linking per-type JS with 5190 new/changed types.
> [INFO] Source Maps Enabled
> [INFO]  Compile of permutations succeeded
> [INFO]  Compilation succeeded -- 35.850s
> [INFO]   Linking into 
> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/war/it.e.u.Application;
>  Writing extras to 
> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/extras/it.e.u.Application*[INFO]
>   [WARN] Can't write source map 
> CCA06A04193EDF5B35BDE836DF1FABBE_sourceMap0.json
> [INFO] java.lang.NullPointerException*
> [INFO]at 
> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:101)
> [INFO]at 
> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:88)
> [INFO]at 
> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:78)
> [INFO]at 
> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapGeneratorV3.mergeMapSection(SourceMapGeneratorV3.java:311)
> [INFO]at 
> com.google.gwt.core.linker.SymbolMapsLinker.link(SymbolMapsLinker.java:316)
> [INFO]at 
> com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:384)
> [INFO]at com.google.gwt.dev.Link.finishPermutation(Link.java:483)
> [INFO]at 
> com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:445)
> [INFO]at com.google.gwt.dev.Link.link(Link.java:178)
> [INFO]at com.google.gwt.dev.Compiler.compile(Compiler.java:244)
> [INFO]at 
> com.google.gwt.dev.codeserver.Recompiler.doCompile(Recompiler.java:362)
> [INFO]at 
> com.google.gwt.dev.codeserver.Recompiler.compile(Recompiler.java:175)
> [INFO]at 
> com.google.gwt.dev.codeserver.Recompiler.recompile(Recompiler.java:134)
> [INFO]at 
> com.google.gwt.dev.codeserver.Outbox.recompile(Outbox.java:135)
> [INFO]at 
> com.google.gwt.dev.codeserver.JobRunner.recompile(JobRunner.java:113)
> [INFO]at 
> com.google.gwt.dev.codeserver.JobRunner.access$000(JobRunner.java:37)
> [INFO]at 
> com.google.gwt.dev.codeserver.JobRunner$2.run(JobRunner.java:90)
> [INFO]at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [INFO]at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [INFO]at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [INFO]at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [INFO]at java.lang.Thread.run(Thread.java:745)
> [INFO]  Invoking Linker Export CompilationResult symbol maps
> [INFO] [ERROR] Failed to link
> [INFO] java.lang.NullPointerException
> [INFO]at java.util.TreeMap.put(TreeMap.java:563)
> [INFO]at java.util.TreeSet.add(TreeSet.java:255)
> [INFO]at 
> com.google.gwt.thirdparty.guava.common.collect.ForwardingCollection.add(ForwardingCollection.java:84)
> [INFO]at 
> com.google.gwt.core.ext.linker.TypeIndexedSet.add(TypeIndexedSet.java:101)
> [INFO]at 
> com.google.gwt.core.ext.linker.ArtifactSet.add(ArtifactSet.java:42)
> [INFO]at 
> com.google.gwt.core.linker.SymbolMapsLinker.link(SymbolMapsLinker.java:330)
> [INFO]at 
> com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:384)
> [INFO]at com.google.gwt.dev.Link.finishPermutation(Link.java:483)
> [INFO]at 
> com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:445)
> [INFO]at com.google.gwt.dev.Link.link(Link.java:178)
> [INFO]at com.google.gwt.dev.Compiler.compile(Compiler.java:244)
> [INFO] 

Re: Problem with 2.8.0 rc1 SDM

[James Horsley]

Ah, just realized this was discussed in more detail 
at https://groups.google.com/forum/#!topic/google-web-toolkit/-c4RR6oLr2o 
I'll check my gson dep and report back

On Thursday, August 25, 2016 at 11:28:58 PM UTC+1, James Horsley wrote:
>
> Meant to say that I'm seeing the same error after switching from beta-2 to 
> rc2
>
> On Thu, Aug 25, 2016 at 11:15 PM James Horsley <james.hors...@gmail.com> 
> wrote:
>
>> Doesn't the CodeServer need the gwt-dev.jar though?
>>
>>
>> On Tuesday, August 23, 2016 at 3:45:03 PM UTC+1, viviana zimbone wrote:
>>>
>>> If you have a maven dependency for gwt-dev, removing it shoudl fix the 
>>> issue :)
>>>
>>> Il giorno martedì 16 agosto 2016 11:03:03 UTC+2, Alberto Mancini ha 
>>> scritto:
>>>>
>>>> Unfortunately removing the temporary files does not helps. 
>>>> Today we try to investigate further and eventually we will open an 
>>>> issue. 
>>>>
>>>> Thanks,
>>>>A. 
>>>>
>>>> On Sun, Aug 14, 2016 at 12:52 AM Andrei Korzhevskii <
>>>> a.korz...@gmail.com> wrote:
>>>>
>>>>> Reading the stacktrace, I think the problem is in 
>>>>> https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/core/linker/SymbolMapsLinker.java#L282
>>>>> ,
>>>>> looks like disk cache returns null there.
>>>>>
>>>>> Did you try to remove folder /var/folders/63/qxvnlkdn7yq2n689wbryx_
>>>>> vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp
>>>>> and run compile again?
>>>>>
>>>>>
>>>>> On Friday, August 12, 2016 at 12:04:44 AM UTC+3, Alberto Mancini wrote:
>>>>>>
>>>>>> Hello,
>>>>>> in the attempt of porting an internal project from beta1 to rc1 we faced 
>>>>>> an issue i do not understand how to debug. 
>>>>>>
>>>>>> The project uses errai but my feeling is that the problem is not 
>>>>>> related to it because similar projects with errai work without problems. 
>>>>>>
>>>>>> Essentially SDM fails during the first compilation and the problem 
>>>>>> seems in the generation of the source maps. 
>>>>>>
>>>>>> The relevant error log follows.
>>>>>>
>>>>>> [INFO] GET /recompile/it.e.u.Application
>>>>>> [INFO]Job it.e.u.Application_1_0
>>>>>> [INFO]   starting job: it.e.u.Application_1_0
>>>>>> [INFO]   binding: user.agent=safari
>>>>>> [INFO]   Compiling module it.e.u.Application
>>>>>> ...
>>>>>>
>>>>>> [INFO]  Unification traversed 54946 fields and methods and 5256 
>>>>>> types. 5210 are considered part of the current module and 5210 had all 
>>>>>> of their fields and methods traversed.
>>>>>> [INFO]  Compiling 1 permutation
>>>>>> [INFO] Compiling permutation 0...
>>>>>> [INFO] Linking per-type JS with 5190 new/changed types.
>>>>>> [INFO] Source Maps Enabled
>>>>>> [INFO]  Compile of permutations succeeded
>>>>>> [INFO]  Compilation succeeded -- 35.850s
>>>>>> [INFO]   Linking into 
>>>>>> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/war/it.e.u.Application;
>>>>>>  Writing extras to 
>>>>>> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/extras/it.e.u.Application*[INFO]
>>>>>>   [WARN] Can't write source map 
>>>>>> CCA06A04193EDF5B35BDE836DF1FABBE_sourceMap0.json
>>>>>> [INFO] java.lang.NullPointerException*
>>>>>> [INFO]   at 
>>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:101)
>>>>>> [INFO]   at 
>>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:88)
>>>>>> [INFO]   at 
>>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:78)
>>>>>> [INFO]   at 
>>>>>> com.google.gwt.thirdparty.debugging.sourcem

Re: Problem with 2.8.0 rc1 SDM

[James Horsley]

Meant to say that I'm seeing the same error after switching from beta-2 to
rc2

On Thu, Aug 25, 2016 at 11:15 PM James Horsley <james.hors...@gmail.com>
wrote:

> Doesn't the CodeServer need the gwt-dev.jar though?
>
>
> On Tuesday, August 23, 2016 at 3:45:03 PM UTC+1, viviana zimbone wrote:
>>
>> If you have a maven dependency for gwt-dev, removing it shoudl fix the
>> issue :)
>>
>> Il giorno martedì 16 agosto 2016 11:03:03 UTC+2, Alberto Mancini ha
>> scritto:
>>>
>>> Unfortunately removing the temporary files does not helps.
>>> Today we try to investigate further and eventually we will open an
>>> issue.
>>>
>>> Thanks,
>>>A.
>>>
>>> On Sun, Aug 14, 2016 at 12:52 AM Andrei Korzhevskii <a.korz...@gmail.com>
>>> wrote:
>>>
>>>> Reading the stacktrace, I think the problem is in
>>>> https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/core/linker/SymbolMapsLinker.java#L282
>>>> ,
>>>> looks like disk cache returns null there.
>>>>
>>>> Did you try to remove folder /var/folders/63/qxvnlkdn7yq2n689wbryx_
>>>> vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp
>>>> and run compile again?
>>>>
>>>>
>>>> On Friday, August 12, 2016 at 12:04:44 AM UTC+3, Alberto Mancini wrote:
>>>>>
>>>>> Hello,
>>>>> in the attempt of porting an internal project from beta1 to rc1 we faced
>>>>> an issue i do not understand how to debug.
>>>>>
>>>>> The project uses errai but my feeling is that the problem is not
>>>>> related to it because similar projects with errai work without problems.
>>>>>
>>>>> Essentially SDM fails during the first compilation and the problem
>>>>> seems in the generation of the source maps.
>>>>>
>>>>> The relevant error log follows.
>>>>>
>>>>> [INFO] GET /recompile/it.e.u.Application
>>>>> [INFO]Job it.e.u.Application_1_0
>>>>> [INFO]   starting job: it.e.u.Application_1_0
>>>>> [INFO]   binding: user.agent=safari
>>>>> [INFO]   Compiling module it.e.u.Application
>>>>> ...
>>>>>
>>>>> [INFO]  Unification traversed 54946 fields and methods and 5256 
>>>>> types. 5210 are considered part of the current module and 5210 had all of 
>>>>> their fields and methods traversed.
>>>>> [INFO]  Compiling 1 permutation
>>>>> [INFO] Compiling permutation 0...
>>>>> [INFO] Linking per-type JS with 5190 new/changed types.
>>>>> [INFO] Source Maps Enabled
>>>>> [INFO]  Compile of permutations succeeded
>>>>> [INFO]  Compilation succeeded -- 35.850s
>>>>> [INFO]   Linking into 
>>>>> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/war/it.e.u.Application;
>>>>>  Writing extras to 
>>>>> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/extras/it.e.u.Application*[INFO]
>>>>>   [WARN] Can't write source map 
>>>>> CCA06A04193EDF5B35BDE836DF1FABBE_sourceMap0.json
>>>>> [INFO] java.lang.NullPointerException*
>>>>> [INFO]at 
>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:101)
>>>>> [INFO]at 
>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:88)
>>>>> [INFO]at 
>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:78)
>>>>> [INFO]at 
>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapGeneratorV3.mergeMapSection(SourceMapGeneratorV3.java:311)
>>>>> [INFO]at 
>>>>> com.google.gwt.core.linker.SymbolMapsLinker.link(SymbolMapsLinker.java:316)
>>>>> [INFO]at 
>>>>> com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:384)
>>>>> [INFO]at com.google.gwt.dev.Link.finishPermutation(Link.java:483)
>>>>> [INFO]at 
>>>>> com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:

Re: Problem with 2.8.0 rc1 SDM

[James Horsley]

Doesn't the CodeServer need the gwt-dev.jar though?

On Tuesday, August 23, 2016 at 3:45:03 PM UTC+1, viviana zimbone wrote:
>
> If you have a maven dependency for gwt-dev, removing it shoudl fix the 
> issue :)
>
> Il giorno martedì 16 agosto 2016 11:03:03 UTC+2, Alberto Mancini ha 
> scritto:
>>
>> Unfortunately removing the temporary files does not helps. 
>> Today we try to investigate further and eventually we will open an issue. 
>>
>> Thanks,
>>A. 
>>
>> On Sun, Aug 14, 2016 at 12:52 AM Andrei Korzhevskii  
>> wrote:
>>
>>> Reading the stacktrace, I think the problem is in 
>>> https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/core/linker/SymbolMapsLinker.java#L282
>>> ,
>>> looks like disk cache returns null there.
>>>
>>> Did you try to remove folder /var/folders/63/qxvnlkdn7yq2n689wbryx_
>>> vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp
>>> and run compile again?
>>>
>>>
>>> On Friday, August 12, 2016 at 12:04:44 AM UTC+3, Alberto Mancini wrote:

 Hello,
 in the attempt of porting an internal project from beta1 to rc1 we faced 
 an issue i do not understand how to debug. 

 The project uses errai but my feeling is that the problem is not 
 related to it because similar projects with errai work without problems. 

 Essentially SDM fails during the first compilation and the problem 
 seems in the generation of the source maps. 

 The relevant error log follows.

 [INFO] GET /recompile/it.e.u.Application
 [INFO]Job it.e.u.Application_1_0
 [INFO]   starting job: it.e.u.Application_1_0
 [INFO]   binding: user.agent=safari
 [INFO]   Compiling module it.e.u.Application
 ...

 [INFO]  Unification traversed 54946 fields and methods and 5256 
 types. 5210 are considered part of the current module and 5210 had all of 
 their fields and methods traversed.
 [INFO]  Compiling 1 permutation
 [INFO] Compiling permutation 0...
 [INFO] Linking per-type JS with 5190 new/changed types.
 [INFO] Source Maps Enabled
 [INFO]  Compile of permutations succeeded
 [INFO]  Compilation succeeded -- 35.850s
 [INFO]   Linking into 
 /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/war/it.e.u.Application;
  Writing extras to 
 /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/extras/it.e.u.Application*[INFO]
   [WARN] Can't write source map 
 CCA06A04193EDF5B35BDE836DF1FABBE_sourceMap0.json
 [INFO] java.lang.NullPointerException*
 [INFO] at 
 com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:101)
 [INFO] at 
 com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:88)
 [INFO] at 
 com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:78)
 [INFO] at 
 com.google.gwt.thirdparty.debugging.sourcemap.SourceMapGeneratorV3.mergeMapSection(SourceMapGeneratorV3.java:311)
 [INFO] at 
 com.google.gwt.core.linker.SymbolMapsLinker.link(SymbolMapsLinker.java:316)
 [INFO] at 
 com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:384)
 [INFO] at com.google.gwt.dev.Link.finishPermutation(Link.java:483)
 [INFO] at 
 com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:445)
 [INFO] at com.google.gwt.dev.Link.link(Link.java:178)
 [INFO] at com.google.gwt.dev.Compiler.compile(Compiler.java:244)
 [INFO] at 
 com.google.gwt.dev.codeserver.Recompiler.doCompile(Recompiler.java:362)
 [INFO] at 
 com.google.gwt.dev.codeserver.Recompiler.compile(Recompiler.java:175)
 [INFO] at 
 com.google.gwt.dev.codeserver.Recompiler.recompile(Recompiler.java:134)
 [INFO] at 
 com.google.gwt.dev.codeserver.Outbox.recompile(Outbox.java:135)
 [INFO] at 
 com.google.gwt.dev.codeserver.JobRunner.recompile(JobRunner.java:113)
 [INFO] at 
 com.google.gwt.dev.codeserver.JobRunner.access$000(JobRunner.java:37)
 [INFO] at 
 com.google.gwt.dev.codeserver.JobRunner$2.run(JobRunner.java:90)
 [INFO] at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 [INFO] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 [INFO] at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 [INFO] at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 [INFO] at java.lang.Thread.run(Thread.java:745)
 [INFO]  Invoking Linker Export 

Re: GWT 2.8.0 RC2 is here!

[James Horsley]

I saw there were some commits to master after RC2 was cut. Are there plans
to cut an RC3 or just roll those commits into the GA?

On Fri, Aug 19, 2016 at 5:31 PM Alexander Polunochev 
wrote:

> Hi Daniel,
>
> Link to download SDK on the official page still points to RC1.
> http://www.gwtproject.org/download.html
>
>
>
> On Thursday, August 11, 2016 at 6:25:18 PM UTC-7, Daniel Kurka wrote:
>>
>> Hi all,
>>
>> I just build the GWT 2.8.0 RC2 and pushed it to maven central. The
>> complete SDK is also available from here .
>>
>> Please start testing and let us know if you run into any trouble and file
>> bugs .
>>
>> We are planing to release this as GWT 2.8.0 if we do not here about any
>> serious issues within the next two weeks. The release notes for RC
>> 2
>>  will
>> be made available shortly after this notice, in the mean time you can take
>> a look at the github repository
>> 
>> .
>>
>> Daniel,
>> on behalf of the GWT team
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[James Horsley]

Sounds great. Thanks!

On Fri, Aug 19, 2016 at 4:27 PM Julien Dramaix <julien.dram...@gmail.com>
wrote:

> elemental2 is generated from closure extern files.
>
> The open source version of the generator should have a support for
> converting d.ts file to java. We don't know yet when the generator will be
> open sourced.
>
> On Fri, Aug 19, 2016 at 4:12 PM James Horsley <james.hors...@gmail.com>
> wrote:
>
>> I remember hearing that elemental2 was being generated from TypeScript
>> definitions. If that's true, is there any chance we could get a look at the
>> generator code too?
>>
>>
>> On Thursday, June 30, 2016 at 1:23:51 AM UTC+1, Julien Dramaix wrote:
>>>
>>> A new experimental version of Elemental2 using the new JsInterop
>>> specification has been pushed on Sonatype today.
>>>
>>> You can try it by downloading the jar file
>>> <https://oss.sonatype.org/service/local/repositories/google-releases/content/com/google/gwt/elemental2-experimental/16-06-30/elemental2-experimental-16-06-30.jar>
>>> or adding this following maven dependency:
>>>
>>> 
>>>
>>>  com.google.gwt
>>>
>>>  elemental2-experimental
>>>
>>>  16-06-30
>>>
>>> 
>>>
>>> Then, inherits the elemental2 module:
>>>
>>> 
>>>
>>> This experimental version works only with the last 2.8-snapshot release
>>> of GWT.
>>>
>>> The goal of this release is to get feedback so don’t hesitate to report
>>> any bugs, issues, concerns you have on this mailing list.
>>>
>>>
>>> Important note: This is an experimental release and without doubt the
>>> future updates until the final release are going to break code!
>>>
>>> - Julien
>>>
>>> --
>> 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/cd662014-000e-4823-8eab-0acb469c574c%40googlegroups.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/cd662014-000e-4823-8eab-0acb469c574c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6y-xP%3DUU-LzPBXj68KPycBT6hdep%3DFehbh8QbPvb_vJQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6y-xP%3DUU-LzPBXj68KPycBT6hdep%3DFehbh8QbPvb_vJQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAHUxr6PHZWmBfW3n73d2qadVRBWdWBTRiUv557ucvQA-KooOCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Experimental release of Elemental2

[James Horsley]

I remember hearing that elemental2 was being generated from TypeScript 
definitions. If that's true, is there any chance we could get a look at the 
generator code too?

On Thursday, June 30, 2016 at 1:23:51 AM UTC+1, Julien Dramaix wrote:
>
> A new experimental version of Elemental2 using the new JsInterop 
> specification has been pushed on Sonatype today.
>
> You can try it by downloading the jar file 
> 
>  
> or adding this following maven dependency:
>
> 
>
>  com.google.gwt
>
>  elemental2-experimental
>
>  16-06-30
>
> 
>
> Then, inherits the elemental2 module:
>
> 
>
> This experimental version works only with the last 2.8-snapshot release of 
> GWT.
>
> The goal of this release is to get feedback so don’t hesitate to report 
> any bugs, issues, concerns you have on this mailing list.
>
>
> Important note: This is an experimental release and without doubt the 
> future updates until the final release are going to break code!  
>
> - Julien
>
>

-- 
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/cd662014-000e-4823-8eab-0acb469c574c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ui Binder Alternatives

[James Horsley]

Something like Elemento + Elemental 2 seems like a great lightweight choice
in the future.

FWIW I agree with Paul that UiBinder plus some top layer of the widget API
(UIObject, Widget, etc.) will get ported over to work with GWT 3.0 by the
community. There's no reason it can't work with Java APT + JsInterop, just
needs the tech investment. I think this will be a huge help for many teams
doing a gradual upgrade.

On Tue, Jul 26, 2016 at 7:43 AM zakaria amine 
wrote:

> Elemento project sounds like an intersting alternative:
> https://github.com/hal/elemento
>
>
> Le dimanche 24 juillet 2016 03:40:02 UTC+2, N Troncoso a écrit :
>>
>> With GWT 3.0, Widgets and UI Binder is losing support. Even besides that,
>> I'm not a huge fan of UI Binder. I'd really just prefer to use vanilla
>> HTML. With that said, I've been searching for other options and I've only
>> found that alternatives are very limited. Even more so, examples of how to
>> integrate alternatives into GWT are basically non-existent. So, my question
>> is, what can I use instead of Widgets and UI Binder and where can I find
>> examples/tutorials/documentation on how to use them in GWT.
>>
>> I found Errai  as one option. But, this
>> seems to be an entire framework, rather than just a template system.
>>
>> Any insight would be greatly appreciated. Thanks
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Experimental release of Elemental2

[James Horsley]

This is brilliant. Thanks for sharing the experimental version!!!

On Thu, Jun 30, 2016 at 1:23 AM 'Julien Dramaix' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> A new experimental version of Elemental2 using the new JsInterop
> specification has been pushed on Sonatype today.
>
> You can try it by downloading the jar file
> 
> or adding this following maven dependency:
>
> 
>
>  com.google.gwt
>
>  elemental2-experimental
>
>  16-06-30
>
> 
>
> Then, inherits the elemental2 module:
>
> 
>
> This experimental version works only with the last 2.8-snapshot release of
> GWT.
>
> The goal of this release is to get feedback so don’t hesitate to report
> any bugs, issues, concerns you have on this mailing list.
>
>
> Important note: This is an experimental release and without doubt the
> future updates until the final release are going to break code!
>
> - Julien
>
> --
> 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/CABXeq2Q%3DuH8beWj4tiG28tycASsJxK8mnxxNPZnEykUeTcMWXw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAHUxr6N%3DJXOqePECVsoua8gOr72%3DUSg-1FFHhXcTuY23UOHYQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GWT React

[James Horsley]

Great work Paul. Thanks for sharing.

On Thu, Apr 14, 2016 at 1:57 PM Paul Stockley  wrote:

> I plan on doing this. I have a couple of things I need to prove out then I
> will start working on setting up the Github projects. I will post a preview
> to my google drive in a couple of weeks so you can take a look while I work
> on setting up the projects on Github.
>
>
> On Thursday, April 14, 2016 at 1:35:06 AM UTC-4, Debasish Padhy wrote:
>>
>> Hi Paul,
>>
>> Is there a possibility of you sharing the codebase over github and put a
>> license to it ? I have been working extensively with JsInterOp / TypeScript
>> cross usage and find your  POC interesting and would love to contribute if
>> its with an open license.
>>
>> thanks,
>> Debasish
>>
>> On Thursday, April 7, 2016 at 6:48:27 PM UTC+5:30, Paul Stockley wrote:
>>>
>>> Sorry,
>>>   I was just updating it to include samples for Redux that I just got
>>> working. The new link is
>>> https://drive.google.com/folderview?id=0Bxp8vLBG2ol3ZERCc3lHUEhKU2M=sharing
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Is anybody of you guys using GWT with Lombok?

[James Horsley]

I haven't used Lombok due to similar reasons as Jens described but have had
really great success with annotation processing libraries like Immutables (
http://immutables.github.io/), AutoValue, etc. I've even started writing my
own annotation processors to help reduce boilerplate.

On Wed, Mar 16, 2016 at 12:37 PM Jens  wrote:

> If its just for value classes and factories you better use Google's
> AutoValue / AutoFactory projects which are based on annotation processing
> instead of hacking the Java compiler as Lombok does.
>
> Personally I would never use Lombok. As it adds code during compilation,
> that code is invisible to tools that work on Java source. IMHO Lombok is
> fragile and can break easily with any JDK update, you can also see this in
> the changelog as it contains quite some "Bugfix: X breaks starting with JDK
> Y". The reason is that Lombok relies on the com.sun.tools.javac package
> which is considered a private API.
>
> So I would generally advice using annotation processors instead.
>
> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Trying to use JsInterop to work with React

[James Horsley]

Paul, brilliant news. Look forward to hopefully taking a look at your code
if you're able to share.

On Fri, Mar 18, 2016 at 4:15 PM Paul Stockley  wrote:

> Success! With some javascript hacking I have managed to get it working. I
> can access state and props and set state as a result of an onClick event. I
> think it might be possible to get react fully working. Below is my somewhat
> contrived solution
>
>
> --
> 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/2af4ca30-e14c-477f-aad4-b3d4b2d7a27b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAHUxr6MpTpHxFEwaNACjZKa-2E5kEB2CKOVb-7cLjwXE3nd3Lg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Trying to use JsInterop to work with React

[James Horsley]

Paul, any chance you're thinking of releasing your code on github or
something? I think an open sourced ReactJs-GWT jsinterop wrapper would be
something a number of people might be interested in using and contributing
to.

On Sun, Mar 13, 2016 at 9:45 PM Paul Stockley  wrote:

> I did think about the ES6 class approach. However, The createElement
> method would need to take the class as a parameter (not an instance). How
> would I do that?
>
>
>
> On Sunday, March 13, 2016 at 5:32:19 PM UTC-4, Goktug Gokdogan wrote:
>
>> See examples on how ES6 classes work with React. Those examples should
>> apply to @JsTypes as well.
>>
> On Sun, Mar 13, 2016 at 2:12 PM, Colin Alworth  wrote:
>>
> Yikes, that's rather opinionated. I don't personally work with React, but
>>> I guess I'm surprised that it can't handle actual inheritance (or even
>>> defining a prototype and attaching it to a constructor).
>>>
>>> Based on what you have there and the details described at
>>> https://facebook.github.io/react/docs/top-level-api.html, I'd suspect
>>> that they actually want the equivalent of the class object itself, not an
>>> instance of it (the line between them is blury in JS already).
>>>
>>> > One thing that makes components different than standard prototypal
>>> classes is that you don't need to call new on them. They are convenience
>>> wrappers that construct backing instances (via new) for you.
>>>
>>> This seems to imply that you can't be guaranteed that your constructors
>>> will actually be called, but also reinforces the idea that they don't want
>>> you to pass in a class instance, just the methods that should be called on
>>> the eventually-created instances. More details from
>>> https://facebook.github.io/react/docs/component-specs.html seem to say
>>> that you are actually expected to pass in just a bag of properties, one of
>>> which will be that `render` function, which can trust that a `this` will be
>>> specified to provide `props` and `state`.
>>>
>>> If there is a hook that lets you define your own constructor or factory
>>> method, that would be good to have to correctly do the GWT object wiring
>>> (perhaps some jsinterop expert can pipe up here as to what will be lost
>>> without that being called). Otherwise, some jsni or JsObject-building code
>>> that copies references to functions over to the a map-like object would be
>>> ideal. A JsProperty-annotated field may be enough to convince the compiler
>>> to generate correct code inside your function to access those properties,
>>> but I would be less sure about non-static helper methods still being around
>>> in the generated component.
>>>
>>
>>> On Sun, Mar 13, 2016 at 3:35 PM Paul Stockley 
>>> wrote:
>>>
 We have started using React (using ES6 and FlowTypes) which is quite
 nice. However, we have a large GWT application that we want to start
 embedding React within. This makes perfect sense for migrating away from
 Widgets to a more modern approach. So I decided I would try and define a
 Java Api for React. After a couple of hours I got a really hacky prototype
 basically working. The code looks like

 private ClassicComponentClass customComponent;


 public void onModuleLoad() {

 customComponent = React.createClass(new CustomComponent());

 HTMLProps props = Props.newHTML();
 props.setDefaultValue("Test");

 DOMElement div =
 React.createElement("div", props,
 React.createElement("div", null),
 React.createElement(customComponent, null),
 React.createElement("div", null, "An example")
 );

 ReactDOM.render(div, Document.get().getElementById("mainCont"));
 }


 @JsType(namespace = JsPackage.GLOBAL, name="CustomComponent")
 public class CustomComponent {

 @JsMethod
 public ReactElement render() {
 return React.createElement("div", null, "It works");
 }
 }



 This works fine for intrinsic React components. The problem is defining 
 custom components. The React.createClass function needs to take a plain 
 javascript object with certain methods defined (render, lifecyle methods 
 etc). If I pass a Java object marked as JsType, this doesn't work because 
 the render method needs to be defined on the top level object. The code 
 puts it on a different prototype which doesn't work because React does the 
 following:



   for (var name in spec) {
 if (!spec.hasOwnProperty(name)) {  --Isn't true for render
   continue;
 }


 Is there some way to achieve what I want with JsInterop?  I tried 
 extending another base class marked with isNative=true. However, this 
 results in a runtime error when trying to construct an object of that type.

Re: [gwt-contrib] Re: Elemental 2?

[James Horsley]

When both Elemental2 and JsInterop are released I think that the community
will start to innovate on this front and new libraries will pop up on
github to address these needs; "if you build it, they will come" and all
that.

I know I'm very much looking forward to Elemental2 + Jsinterop as a
platform to build on.

On Sun, Nov 22, 2015 at 6:45 AM 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> There could be a separate Json library build with JsInterop. Some of the
> decisions I made in the design of the original Elemental JSON were made
> specifically because of DevMode support and GWT optimization internals.
> Given the unboxing of Double and Boolean, and the elimination of DevMode,
> the library can be much simpler now and still have a JVM implementation to
> be portable.
>
> On Sat, Nov 21, 2015 at 10:28 PM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> Elemental2 will be just an auto-generated thin wrapper around the browser
>> APIs. Unlike Elemental1, it will not provide a cross platform JSON
>> implementation.
>>
>> I don't think you need to report compatibility bugs for Elemental1 unless
>> a maintainer steps up and shows interest.
>>
>> On Sat, Nov 21, 2015 at 1:42 PM, Erik Kuefler  wrote:
>>
>>> What's the current thinking regarding JSON in Elemental 2? That part has
>>> always been a bit different from the DOM libraries, and I know there was
>>> talk a long time back about splitting it out. I've been using Elemental
>>> JSON extensively in my projects just to have a JSON library that works in
>>> GWT and in JVM, but I've found it to be extremely buggy (mostly in terms of
>>> behavior differences between jvm, optimized gwt, and draft mode gwt). Are
>>> these bugs worth reporting? Is it all being reworked for Elemental 2?
>>>
>>> On Friday, November 20, 2015 at 12:36:22 PM UTC-8, Ray Cromwell wrote:

 Another thing to consider is that J2CL was developed as a 'bake off',
 in which multiple prototypes and designs were discussed/looked at (compile
 from Java with JDT, compile from bytecode, compile using Javac APIs,
 writing parser by hand, etc) It would have been a bit premature to release
 any of them as they were all known ahead of time to be throwaways.

 I have a hacky Elemental2 prototype (which is not the official one that
 Julien is working on), if you want to take it and play around.



 On Fri, Nov 20, 2015 at 10:30 AM, 'Goktug Gokdogan' via GWT
 Contributors  wrote:

> No worries :)
>
> On Fri, Nov 20, 2015 at 10:27 AM, Stephen Haberman <
> stephen@gmail.com> wrote:
>
>> Hi Goktug,
>>
>> That's all true, thanks for providing a counter data point. You're
>> right, the JsInterop design docs/etc. were all out in the open from day 
>> 1,
>> which I thought was pretty exiting.
>>
>> I definitely can't take any credit for providing useful feedback, but
>> I enjoyed seeing the thoughts and process from the community.
>>
>> So, apologies for the sweeping statement.
>>
>> - Stephen
>>
>>
>>
>> On Fri, Nov 20, 2015 at 11:58 AM, 'Goktug Gokdogan' via GWT
>> Contributors 
>> wrote:
>>
>>> Singular is not a Google project and not being developed internally.
>>> It is Daniel's personal project and as fas as I know it is already in 
>>> the
>>> open source.
>>>
>>> We don't have anything to share for Elemental yet. We are talking
>>> with other teams, thinking about alternatives etc. Also when we 
>>> release, it
>>> will not be part of GWT-SDK so there is going be extra work to move the
>>> development outside; which doesn't make sense at this stage.
>>>
>>> The big things we recently developed for GWT, JsInterop and
>>> SuperDevMode and they were all open source from day one.
>>>
>>> On Fri, Nov 20, 2015 at 5:34 AM, Stephen Haberman <
>>> stephen@gmail.com> wrote:
>>>
 > Meanwhile I will revive my own generator project.

 I'll take the opportunity to hop on a soapbox, but the "closed
 source/eventually open source" model is a curious trend that I think 
 I've
 only seen in the GWT community (are their other examples?)...

 Musing, it probably stems from Google setting the example with GWT
 itself, where historically a lot happened internally before being 
 mirrored
 externally, but it happens a bit for non-Google-GWT projects as well, 
 like
 the repackaging of GPE, which was closed during initial development
 (although the result is great, and I really appreciate it), Singular, 
 which
 is still closed during initial 

[gwt-contrib] Re: Steering Committee Meeting Notes (8/19)

[James Horsley]

Thanks!

On 21 August 2015 at 17:48, 'Bhaskar Janakiraman' via GWT Steering 
gwt-steer...@googlegroups.com wrote:

 See:

 https://docs.google.com/document/d/14HaNSGd8-_1VOAQIKWGd4lKmcRQLciL2ISPhE18yOQ4/edit?usp=sharing

 Bhaskar

 --
 You received this message because you are subscribed to the Google Groups
 GWT Steering group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to gwt-steering+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAHUxr6M-oA1y9S%2Bw1nbHFTvqyjqddtNc6-UqhrSe7TOrrFJSEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GWT release prioritization

[James Horsley]

Any chance someone from the steering committee could comment on this?

On 3 August 2015 at 09:37, maticpetek maticpe...@gmail.com wrote:

 1+


 On Friday, July 31, 2015 at 11:39:00 AM UTC+2, James Horsley wrote:

 Firstly, I am very much looking forward to the next generation j2cl
 compiler for GWT and think the new compiler vision is great. That said, I
 think the community would benefit greatly with the steering committee
 placing a higher priority on closing out on the 2.8 release. I know that
 the current 2.8 is considered usable for production but 2.8 isn't feature
 complete and organizations can be very hesitant to use non-GA versions of
 libraries. In particular it would be a big win to have a done version of
 JsInterop v1 and clear guidance on using the current version of elemental.

 I, and I'm sure the rest of the GWT community, would greatly appreciate a
 clearer view on current release expectations and prioritization; is there
 anything you guys can share on that front?

 Again, really appreciate the recent work and love the plans for GWT 3.0.

 Cheers,
 James

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT release prioritization

[James Horsley]

Firstly, I am very much looking forward to the next generation j2cl
compiler for GWT and think the new compiler vision is great. That said, I
think the community would benefit greatly with the steering committee
placing a higher priority on closing out on the 2.8 release. I know that
the current 2.8 is considered usable for production but 2.8 isn't feature
complete and organizations can be very hesitant to use non-GA versions of
libraries. In particular it would be a big win to have a done version of
JsInterop v1 and clear guidance on using the current version of elemental.

I, and I'm sure the rest of the GWT community, would greatly appreciate a
clearer view on current release expectations and prioritization; is there
anything you guys can share on that front?

Again, really appreciate the recent work and love the plans for GWT 3.0.

Cheers,
James

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Research on Elemental

[James Horsley]

Is it recommended to use the current elemental API even though it's not
based on JsInterop yet? For example, if I use the current elemental API,
can I expect that Elemental 2.0 should be a fairly easy transition?

On Sun, Jun 21, 2015 at 5:14 PM Lukas Glowania lukas.glowa...@gmail.com
wrote:

 Great resource! Thanks a lot.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Important videos from GWT Meet-up 2015

[James Horsley]

Thanks Thomas.

Good point on getting started experimenting before the compiler is made
available. I've been building a few of libraries using APT for code
generation recently, making use of the wonderful google  square libraries
like auto and javapoet. I think it'd be pretty straightforward to build an
annotation processor for a few existing libraries e.g. i18n. However, I'm
really hoping to make use of GWT compiler level solutions to overcome some
current APT challenges; in particular, invoking the processor when non-java
files are changed such as ui.xml files. Daniel mentioned in his talk that
there might be a general solution for this which would be pretty awesome to
use.

I was probably too specific in asking for early access to the compiler.
Early access to elemental 2.0 and jsinterop 2.0 would be really helpful to
try and figure out how to port JSNI/JSO code over to jsinterop.

In general my experience with GWT + APT for my own libraries has been
really good, so I'm quite positive about the plans for GWT 3.0. Hopefully,
with a clear migration story, the community will be able to smooth any
rough edges that the core GWT team can't take on.



On Sun, Jun 21, 2015 at 11:18 AM Thomas Broyer t.bro...@gmail.com wrote:



 On Sunday, June 21, 2015 at 11:17:50 AM UTC+2, James Horsley wrote:

 Also worth noting that, outside of GWT-RPC, I think that many of the
 current major GWT features (widgets, uibinder, etc.) could be ported by the
 community such that only minor code changes are necessary. I would even
 hazard a guess that companies like Vaadin might be interested in supporting
 or at least contributing to a 3.0 based port things like the widget library.


 I'd rather bet on Sencha for widgets.
 (note: I have absolutely no information about whether this will happen and
 who would make it happen)


 As I've said in other emails though, I think the migration/transition
 story from 2.8 - 3.0 needs work and open communication. Based on what's in
 the videos from the meetup, I don't think it has to be as radical of a
 change as is feared. To make it smoother, hopefully there will be early
 access to the compiler API such that the community can start thinking about
 building 3.0 versions of libraries we want available.


 You don't need access to the new compiler for that, you can start
 experimenting right now: given that the idea is that the GWT.create() magic
 will be removed and things would have to be generated upfront using JavaC
 and annotation processors, that means the generated code has no GWT magic
 (besides possibly JSNI, which would have to eventually change to JsInterop
 or JSNI 2.0) and can still be compiled using the current compiler (or
 2.8.0-SNAPSHOT if you need System.getProperty(user.agent)).
 Disclaimer: I haven't yet tried it though.
 Note that if you'd like to start experimenting with annotation processors,
 I highly suggest you use auto-common's BasicAnnotationProcessor and other
 utilities: https://github.com/google/auto/tree/master/common

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Important videos from GWT Meet-up 2015

[James Horsley]

Also worth noting that, outside of GWT-RPC, I think that many of the
current major GWT features (widgets, uibinder, etc.) could be ported by the
community such that only minor code changes are necessary. I would even
hazard a guess that companies like Vaadin might be interested in supporting
or at least contributing to a 3.0 based port things like the widget library.

As I've said in other emails though, I think the migration/transition story
from 2.8 - 3.0 needs work and open communication. Based on what's in the
videos from the meetup, I don't think it has to be as radical of a change
as is feared. To make it smoother, hopefully there will be early access to
the compiler API such that the community can start thinking about building
3.0 versions of libraries we want available.

On Sun, Jun 21, 2015 at 3:19 AM David jim.p...@gmail.com wrote:

 When is GWT 3 available?


 On Sunday, June 21, 2015 at 6:38:50 AM UTC+8, Paul Robinson wrote:

 I suspect most people here just haven't quite realised the magnitude of
 what's planned. The plans are quite reasonable for anybody that can start
 from scratch (which doesn't include me). Anybody invested in GWT will have
 a problem. That includes Google, although there are no obvious plans for a
 migration path.

 It might mean GWT forks, although I can't see anybody new to GWT adopting
 GWT 2.8 once 3.0 is out, and the current plans will put people off adopting
 GWT now.

 Paul

  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Stop calling it GWT 3.0

[James Horsley]

Thanks Daniel.

It's great that the steering committee are discussing the topic this early 
in the process; in particular, in the context of how GWT dev's can help 
themselves to be future proof (e.g. your Modernizing GWT talk).

I completely understand how certain GWT generator based libraries that 
require global knowledge don't fit with APT (e.g. GWT-RPC maybe needing the 
transportable types explicitly listed). But, at a glance, it seems like 
other high adoption libraries like UiBinder and the widget library (maybe 
even just some top level pieces?) can be retrofitted and released as 
separate projects to work with the transpiler. 

Hopefully we can leverage the opinions and contributions of the GWT 
community to determine what are essential libraries to carry forward and 
implement plans to make this happen. A few big helping points here would be:

1) Clearly documented ways to future proof new development. What to use, 
what to avoid, examples, etc.
2) Early access to the transpiler when you have a basic API settled, so 
that we can start working on converting our favourite libraries that the 
steering committee don't have time for.
3) Access to Singular. This gives people a future proof view layer to work 
with and I think it will boost confidence/morale for those concerned about 
the 3.0 transition.

Cheers,
James

On Sunday, June 14, 2015 at 8:02:11 PM UTC+1, Daniel Kurka wrote:

 Hi all,

 thanks for sharing your views in this discussion.

 Let me add a little background:

 Currently we the GWT team have decided to work on a new fast transpiler 
 from Java to Closure (our internal enhanced version of JavaScript). This 
 makes sense for a lot of reasons that I won't go into detail on, but here 
 are a few:

 - Our cross platform applications really want a faster and better 
 integration with closure.
 - GWT and closure share a lot of work (optimizations) and this is a good 
 way to not reinvent the wheel constantly

 So at some point we will open source this new compiler which will have 
 some compatibility with the old compiler, but it will not support 
 everything that GWT used to support.
 It is not up to Google to decide if this should be GWT 3.0, but it is up 
 to the steering committee to decide (this is what the steering committee is 
 for).
 However this new compiler works out, Google has tons of GWT applications 
 that would need to move from GWT 2.8 to whatever this new effort is, so 
 coming up with a common feature set and a migration plan is on our work 
 list, but we will focus on that once we actually have a new compiler.

 However we already know that applications that only use a certain feature 
 set (which might grow, as people put in more work), should be fine on both 
 compilers (we should discuss this after the 2.8 release). We only talked 
 about this so early in the process to give the community the ability to 
 provide feedback on our efforts, but don't panic, nothing is set in stone 
 and we (the steering committee) need your input on this.

 -Daniel



 On Sun, Jun 14, 2015 at 4:51 PM Alain Ekambi jazzma...@gmail.com 
 javascript: wrote:

 Also think of people who use GWT for non web based project. 
 We use GWT  for example to create native mobile apps with Titanium. And 
 our customers love the  UI Binder support.

 Dropping UI Binder means we wont be able to support new version of GWT. 

 Such a bad move.

 On 14 June 2015 at 16:22, Travis Schmidt travis@gmail.com 
 javascript: wrote:

 I have the same concerns as the last comment.  We are a java shop and 
 use enterprise java for our back-end.  We have been using GWT for the last 
 9 years to write thin front ends for our applications.  Basically GWT RPC 
 and UiBinder are 99% of the code we deploy.  If I need to replace those 
 with Polymer, Angular and some JSON XHR, then I don't see much need to use 
 GWT going forward.  Am I mistaken or just misunderstanding something?

 On Sun, Jun 14, 2015 at 4:31 AM David david...@gmail.com javascript: 
 wrote:

 I'm excited that you guys are planning a radical change (really). I 
 hope it becomes more clear on what we should be using to future proof our 
 apps. 
 I hope we will get some usable preview of Singular (if that is really 
 going to be a replacement).

 Somehow I am not totally concerned that we will need some major 
 rewrites, it will be hard sell to management and it might mean that we 
 need 
 to look to different directions as well.

 But I am afraid that if GWT is no longer offering a complete solution 
 like it does now (including a UI library, RPC support, i18n, UI binding, 
 ... etc) that a lot of the advantage will be lost for me.

 As for naming, well it seems that non of the three letters still apply 
 to the direction GWT is about to take.
 1) no longer in Google hands (or so they clame)
 2) Web not the main concern since the cross compiler is more to share 
 code between web/android/ios apps.
 3) Toolkit ... it sounds more like a transpiler to me. 

Re: [gwt-contrib] Re: Stop calling it GWT 3.0

[James Horsley]

I think that there's enough branding/momentum/etc. behind the GWT name that
to be taken seriously it should stick with the GWT name, even if possibly
adjusted slightly like Jens's suggestions.

I'm fully behind the direction the compiler is taking and I believe that
the vision put forward in the videos from the GWT meetup is a great one
that will resonate well with developers. My big concern is that the
migration story and timing isn't great right now.

New projects that are starting with GWT 2.8 are somewhat in limbo right
now. I think that things are okay for the business logic and presenter side
of things, but deciding what to do for the view layer is tricky.

JsInterop doesn't feel complete enough to easily use with libraries like
React for the view layer. I've played around with doing this but it seems
very painful without some of the JsInterop 2.0 features (per
https://goo.gl/sKsBGX) in particular the functionality from the Js class to
easily call JS and create JS collections. As such, the best choice seems to
be UiBinder with HTML+CSS and my own minimal JsInterop interfaces for DOM
types. But even that's not future proof under the current plans to not
support UiBinder. If Singular was available it would probably bridge the
gap, but it's not available so we're left picking from choices that aren't
planned to be in GWT 3.0.

An official JsInterop version of elemental would also be a big help to
prevent everyone from creating their own version and having to migrate
later.

I would recommend a doc/page/etc. be started which clearly lists things
that are definitely going to be in GWT 3.0, those that are under
consideration, and those that definitely won't. Also, give trivial examples
future proof setups that dev's can follow to make the 3.0 transition easier.

Cheers,
James

On 13 June 2015 at 14:44, Jens jens.nehlme...@gmail.com wrote:

 I kind of agree not calling it GWT 3.0. I would not name it completely
 different, maybe something along the lines of GWT X1, GWT RST (abbr. of
 reset) or GWT Next. I am pretty sure we could come up with something more
 distinct to indicate that this release is a lot different and a reboot of
 GWT.

 I also think that without drop-in replacements for widget code, UiBinder
 and GWT-RPC a lot of apps will not migrate to the new GWT because it is
 simply not cost effective. The GWT surveys shows that the majority of apps
 depend on these features. Maybe with the help of Singular it is possible to
 incrementally rewrite your UI until its compatible with GWT 3.0 but you
 still need to rewrite a lot.

 I think at the end it boils down to if you want to use the new compiler or
 if you are fine with the current SDM development speed of the 2.8 release.
 Because all the rest of GWT 3.0 can also be used with GWT 2.8.

 -- J.


  --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/76cb0c63-a981-4b54-95bf-ebbd8f773311%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/76cb0c63-a981-4b54-95bf-ebbd8f773311%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/CAHUxr6NjMi-U_HERJVbPfkVx_3tkspTVbfr3NZ0j179ZhyJ6aA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Important videos from GWT Meet-up 2015

[James Horsley]

Someone in the video commented that there needs to be a very clear
messaging around how to best protect/future proof yourself. The
Modernizing GWT video was obviously a step in that direction but I'd love
to see something more concrete e.g. if UiBinder won't be supported, what
should we be using?

I had a specific question regarding the recommendation to use Elemental. My
understanding was that Elemental 2.0 was going to be released with GWT 3.0.
Is it safe to use Elemental in it's current state or will there be
significant enough changes that we should wait?

On 12 June 2015 at 15:29, jchimene jchim...@gmail.com wrote:

 Thanks for the link .

 To those who've generously uploaded the videos: any possibility of also
 uploading the slides? The technical presentations are pretty much useless
 w/o the slides.

 TIA,
 jec


 On Friday, June 12, 2015 at 2:21:49 AM UTC-7, Phineas Gage wrote:

 I thought I'd share this link to a series of important videos from the
 recent GWT Meet-up 2015, which was posted on G+ and in the GWT Contributors
 group:

 https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE

 *Summary:*

 For anyone who wasn't already aware, there are seismic changes coming for
 GWT. Basically, gwt-user and everything in it will be gradually mothballed,
 so widgets, GWT-RPC, UiBinder, CssResource, etc. While we're at it, the GWT
 compiler will probably go too. If the plan stays as presented, everything
 is going, sooner or later. It looks as though a much simpler and faster
 Java to JS transpiler is proposed, maybe under a different project name,
 with optimizations handled by Closure. I welcome corrections if I've got
 something wrong here.

 *Editorial:*

 Having used GWT for a number of years, I think this is a massive but
 needed change. It looks like a great direction, that maybe could have been
 taken even sooner. But personally, I now can't see using GWT for new
 projects until it appears in its new form. We're in a kind of purgatory now
 where anything you write in GWT may not be easy to maintain, but the new
 vision is currently just a hope for the future.

 As for myself, since I've got a project in its early stages, I'll
 probably be porting everything I have to JavaScript, until I can count on a
 stable Java to JS transpiler. At that point, I can decide to move some of
 the code back to Java, if it's not too painful and the benefits to doing so
 are clear. At the same time, even with years of Java experience, I have to
 ask myself, why Java? If it's a better language that compiles to JavaScript
 that we want, there are many: Dart is coming along, and there are more
 options than there were before. It's speculation to say what an open source
 Swift will mean, but the external forces affecting these options can play
 themselves out while JavaScript will likely continue to be stable for years
 to come.

 So rather than drag it out, I'd like to see these changes happen ASAP. As
 it's sometimes said, if you find yourself in a hole, stop digging. I
 believe that if a stable and fast Java to JS transpiler were released, the
 community would chip in to help complete JRE emulation or other needed
 projects, and I'm glad to hear that much of the GWT team is being diverted
 to compiler work.

 Thanks to the GWT team for sharing these plans with the community!

  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Default/Defender Method Support in JsInterop

[James Horsley]

Is support for defender/default methods planned to be support for JsInterop
in GWT 2.8? The change to add general GWT support (
https://gwt-review.googlesource.com/#/c/10330/) called out that JsInterop
support would follow in a subsequent patch but I wasn't sure if it's
targeted for 2.8 or not.

Cheers,
James

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Issues with sourceLevel in latest 2.8.0-snapshot

[James Horsley]

Thanks. I had been trying various combinations of value and line
without success. Digging further it turned out that the snapshot jars were
working but the ones that weren't working were ones I'd built from source.
I eventually got the latest source working, but, unfortunately I didn't do
a good job isolating the changes so am not 100% which fixed it and have
spent enough time on it that I'm just going to roll forward :) Things I
changed included how I passed in sourceLevel using arg value and arg
line, also to switch from building GWT/master using buildonly to dist-dev.

If I go back to isolate the change that's making it work I'll report back
to this thread.

Thanks for your help.

Cheers,
James

On Tue, Apr 7, 2015 at 8:51 PM Jens jens.nehlme...@gmail.com wrote:


 Thanks. I'm using ant with some custom build targets and passing in
 sourceLevel using arg line=-sourceLevel 1.8 /.


 I think you must use arg value=-sourceLevel 1.8 /

 When using line it means you have two parameters -sourceLevel and
 1.8.

 -- J.


 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Issues with sourceLevel in latest 2.8.0-snapshot

[James Horsley]

I was using an older version of the 2.8.0-snapshot jars just fine, but
after pulling in the latest versions from sonatype I've started getting the
error Lambda expressions are allowed only at source level 1.8 or above.
Adding -sourceLevel 1.8 doesn't appear to fix this. I'm having the same
issue whether I'm running DevMode, CodeServer, or Compiler.

I only have JDK 8 installed on my laptop but confirmed that JDK 8 is being
used just in case there.

Anyone else seeing this?

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Issues with sourceLevel in latest 2.8.0-snapshot

[James Horsley]

Thanks. I'm using ant with some custom build targets and passing in
sourceLevel using arg line=-sourceLevel 1.8 /.

I've looked into it a bit already but I'm still thinking the issue is most
likely something wonky in my build.xml but wanted to check here in case
others were having the same problem

I'll do some additional verification and report back.

Cheers,
James

On Tue, Apr 7, 2015 at 8:01 PM Jens jens.nehlme...@gmail.com wrote:

 I have a custom build from 3rd April which only adds some Java 8 API
 emulation patches and it works without issues when using -sourceLevel 1.8 .

 Maybe you are not passing the parameter correctly? How do you launch
 DevMode/CodeServer/Compiler?

 -- J.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.7 release plan

[James Horsley]

+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: master/3.0.0 js interop ready to play with?

[James Horsley]

I'm also interested in Cristian's second question about using callback 
functions. Is this supposed to just work with the current master or is 
Cristian's EventListenerFactory workaround the best bet for now?

Cheers,
James

On Monday, August 11, 2014 7:17:32 PM UTC+1, Cristian Rinaldi wrote:

 I was playing with JsInterop and perform several examples 
DataTables Plugin of JQuery (import) 
Polymer (Path Observer, Object Observer), etc...

 Here my exmaples:
https://github.com/csrinaldi/samples-of-gwt/tree/master/gwt-playground

 But I 2 question about JsInterop:

 The first question with JsInterop is about the import methodology, when I 
 define a interface that maps with a JS core Element, by example: Object or 
 JSON, I not sure the best form for maps the static method of the Object, by 
 example Object.observe(...), or JSON.stringify().

 My understanding of JsInterop is that one defines an interface, which is 
 implemented by the compiler. 
 And the allocation for now is through a factory in JSNI, talking to 
 correlate Object for example, for Polymer ObjectObserver:

 public static native T extends JsObject ObjectObserverT 
 createObjectObserver(T obj)/*-{
  return new $wnd.ObjectObserver(obj);
 }-*/;


 But the asignations is a instance of Object, and the observe() method is a 
 static method.

 How to is the best form of map this case?

 The second question is about function callback passed to the Javascript 
 method

 button.addEventListener(click, function(event){
 console.log(event);
 });

 The way I found to the compiler to generate things correctly was:

 button.addEventListener(click, EventListenerFactory.createEventListener(
 new EventListenerJsObject() {
  @Override
  public void onEvent(JsObject event) {
//TODO
  }
 }));

 where:

 public class EventListenerFactory {
 public static native gwt_sample.EventListener createEventListener(
 EventListener listener)/*-{
  return function(evt){
  listener.onEvent(evt);
  }
  }-*/;
 }

 and:

 @JsType
 public interface EventListenerE extends JsObject {
 void onEvent(E event);
 }

 Thanks!!


 El lunes, 11 de agosto de 2014 09:03:00 UTC-3, salk31 escribió:

 Thanks. I have great hopes for this stuff ;)




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.7.0 Release Date

[James Horsley]

Is there any word as to whether Java 8 language/syntax support will be
included in 2.7?


On 28 May 2014 18:51, confile michael.gorsk...@googlemail.com wrote:

 Great thank you!


 Am Mittwoch, 28. Mai 2014 19:17:22 UTC+2 schrieb Jens:

 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.

 Release is targeted around Google IO 2014 which is at the end of June.
 But personally I would expect it to be released mid/end July.

 -- J.

  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: who discusses the next features and adopts feature requests?

[James Horsley]

Are there any best practices for open source projects to make integrating
back into main GWT easier in the future e.g. license, code style, etc.? If
so, it may be worth documenting them somewhere so that projects which are
set up with the hope to integrate into GWT if successful can follow those
guidelines.


On 21 May 2014 22:00, John A. Tamplin j...@jaet.org wrote:

 A more general answer is that in any community project, whoever cares
 about a feature the most is the one that designs it, convinces others it is
 worth including, and implements it.  Just because something has a lot of
 votes doesn't automatically mean it will get built -- someone has to be
 interested enough to make it happen.  This was the case even when it was a
 Google project, but is especially true now that it is fully owned by the
 community.

 --
 John A. Tamplin

 --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
  To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-MhbBfYZG7nHHWhG%3DOPhBBU3Cc6FaBV5q374vjV9f0Vg%40mail.gmail.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-MhbBfYZG7nHHWhG%3DOPhBBU3Cc6FaBV5q374vjV9f0Vg%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/CAHUxr6PcsgxxqEPJ%2B1wrqPeg640edZF%3DJ5t1efLSd5-O%3DCnH3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: March 12 minutes

[James Horsley]

(Replied to google-web-toolkit@googlegroups.com)

Thanks Colin. Out of interest, would it be likely for java 8 syntax to be
supported in a 2.7 release with the Google I/O target date? FWIW I'd
personally be delighted to have a 2.7 release for June with incremental
compilation as the big ticket item but I am of course looking forward to
using java 8 syntax ASAP :)


On 14 May 2014 17:36, Colin Alworth niloc...@gmail.com wrote:

 Sorry for the delay in sending this out, it was approved by the members
 who were present, but I forgot to mail it out here:


 GWT Steering Committee call March 12, 2014

 Present

 Artur Signell

 Christian Goudreau

 Christian Sadilek

 Daniel Kurka

 Bhaskar Janakiraman

 Thomas Broyer

 Colin Alworth (taking notes)

 New Maintainers

 Manuel Carrasco Moñino nominated for RequestFactory, AutoBeans, I18n, and
 helping with Jenkins builds, approved

 John Tamplin nominated for I18n, approved

 GWT 2.6.1 release

 Thomas, Daniel, Bhaskar brought up various issues that have been fixed and
 should be shipped: e.g. super dev mode fixes for windows, jetty/classloader
 issues for dev mode, ie11 history encoding issues. Others that still need
 to be merged will go into a release checklist, which should also help us
 avoid release issues as in 2.6.0.

 Super Dev Mode Improvements

 Next GWT version will be 2.7, released around I/O, adding modular
 compilation (to improve Super Dev Mode performance). Other features may
 also be included, or may wait for a later GWT 3 release. Moving up this
 target date and making it a smaller release will get better Super Dev Mode
 out to users right away, rather than delaying until other new features are
 ready to go. IE6 and 7 support, disabled in GWT 2.6, will be removed in
 this release.

 --
 You received this message because you are subscribed to the Google Groups
 GWT Steering group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to gwt-steering+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Chrome Canary 36 not showing sourcemaps

[James Horsley]

FWIW I have the same problem with Firefox hanging while using 100% CPU with
SDM


On 16 April 2014 05:41, Stefano Ciccarelli sciccare...@gmail.com wrote:

 Chrome 35 too. I ha dato switch back to chrome 34.
 On Firefox suorce maps are showing, but our project is so big that Firefox
 became unusable.


 Il mercoledì 16 aprile 2014, Thad Humphries thad.humphr...@gmail.com ha
 scritto:

 I'm trying to use the device emulator in Chrome Canary (v. 36.0.1941.0)
 to test various mobile devices. I'd like to debug my mobile code with SDM's
 sourcemaps, but they are not there, unlike on Chrome 34 where sourcemaps are
 at localhost:9876/sourcemaps/mymodule. Is there a flag I need to add to get
 sourcemaps, the way I must add --touch-events to test touch events?

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.



 --
 Nel mondo esistono 10 categorie di persone, quelle che capiscono il
 binario e quelle che non lo capiscono.

  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on GWT 3.0 re: Java 8 and IE 8/9

[James Horsley]

Ray, sounds fantastic and can happily say that something along those lines
would tackle many of the issues with GWT I noted in the current GWT survey.
Will be eagerly awaiting the design docs and proposals.


On 26 October 2013 00:06, Ed post2edb...@gmail.com wrote:

 We're thinking about introducing a way of developing UI that is more like
 traditional HTML design, you create HTML, CSS, and then attach behavior via
 Java. UiBinder is sort of like this, but it is not


 Can't wait ... Would love seeing this...
 I feel the pain: a company abroad makes the html/css and then I put the
 logic behind it with gwt... But still find it far from optimal, used
 UIBinder a lot in the past, but not flex enough (not-change and test
 friendly).
 The develop process gap is simple too big which reduces productivity.

 I am sure that a higher and efficient/low cost productivity, realized with
 GWT, will surely attract more people using it (something I put this in the
 vaadin survey).

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GWT 2.6 Release Note

[James Horsley]

GWT 2.6 Release Plan:
https://docs.google.com/document/d/1ZdMwcTjc4rkWg6nntCY1BDB1xI2PHPwaCnTYw-9uAKE/edit#



On 21 October 2013 10:31, Davide Cerbo davidece...@gmail.com wrote:

 Hi all,

 somebody have news about GWT 2.6 release date, or information about new
 feature?

 Now we are in QA 2013 and the release date should be near.

 Should we have all feature specified in the slides below?


 https://docs.google.com/presentation/d/1PfXXegni0gcZQYpX09t0gs2Z9dqST5MmiHc_NoPSluo/edit#slide=id.p18

 Any news will be appreciated :)

 bye,
 Davide

 --
 --
 Davide Cerbo
 ---
 www.linkedin.com/in/davidecerbo
 + 39 329 70 81 927
 ---

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: GWT-Contributors Hangout on Air Event

[James Horsley]

Completely agree with Jens. Love that these are available to join/watch but
did have difficulty understanding some parts of what was said in the
meeting room.

Thanks for setting it up.


On 28 August 2013 20:25, Jens jens.nehlme...@gmail.com wrote:

 Just watched it and I think these hangouts are a great idea.

 Is there a way to improve the audio quality especially for the meeting
 room? Sometimes it was a bit difficult to understand what have been said.

 -- J.

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Email notifications for gerrit code reviews?

[James Horsley]

There don't seem to be emails going out to gwt-contrib when I make changes
to my code review (https://gwt-review.googlesource.com/#/c/2421/) is this
the expected behaviour or have I missed a setting?

Also, how do I trigger a presubmit build?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Email notifications for gerrit code reviews?

[James Horsley]

Ahhh ok. I've signed up for the mailing list and see the entries in the
link you sent. I had still been getting some code review emails even though
I wasn't signed up for that group so hadn't realized.

Thanks for the info on the mailing list and presubmit build requiring the
commiter +1 to trigger.

Cheers,
James


On 13 August 2013 15:51, Daniel Kurka danku...@google.com wrote:

 Matthew changed gerrit to email to a separate list
 gwt-revi...@gwtproject.orghttps://groups.google.com/a/gwtproject.org/forum/#!forum/gwt-reviews
 .
 You can not trigger a presubmit build (for security reasons), one of the
 commiters has to give at least a +1. This triggers a build.

 - Daniel


 On Tue, Aug 13, 2013 at 4:38 PM, James Horsley james.hors...@gmail.comwrote:

 There don't seem to be emails going out to gwt-contrib when I make
 changes to my code review (https://gwt-review.googlesource.com/#/c/2421/)
 is this the expected behaviour or have I missed a setting?

 Also, how do I trigger a presubmit build?

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.






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

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[James Horsley]

I ported the CR to gerrit a couple of months back
https://gwt-review.googlesource.com/#/c/3186/

Last update I got was that it's pending further review by Thomas Broyer
who's currently tied up with modularization and mavenization. I'm seeing
other RF changes going on though so hopefully it won't require too much
reworking of my original commit.

rant
I totally understand there are limited resources for reviewing this stuff
but it would be quite frustrating if many changes were necessary to my
patch due to underlying changes. I submitted the patch over a year ago and
it's the 6th highest starred issue on the issue tracker from what I can
tell.
/rant


On 29 July 2013 16:27, mfet...@tchepa.com wrote:

 On 2012/10/30 08:28:07, james.horsley wrote:

 On 2012/06/08 17:20:06, rdayal wrote:
  Yep, you're on the CLA list.
 
  On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley
 mailto:james.horsley@gmail.**com james.hors...@gmail.com
  wrote:
 
   Just to check, was everything okay with the CLA I signed?
  
   On 7 June 2012 16:56, James Horsley

 mailto:james.horsley@gmail.**com james.hors...@gmail.com wrote:

  
   Thanks Rajeev. Let me know if there's anything else you need with

 it.

  
  
   On 7 June 2012 16:18, Rajeev Dayal mailto:rda...@google.com

 wrote:

  
   Thomas, thanks for jumping in.
  
   James, as Thomas said, we'll defer this to 2.5.1, but we'd

 definitely like

   to get it in there, as it's an important patch. We just didn't

 want to

   force this patch in 2.5.0, which is what we would have to do with

 the

   current workload.
  
   Thanks so much for working on this.
  
  
   On Thu Jun 07 06:23:58 GMT-400 2012,

 mailto:james.horsley@gmail.**com james.hors...@gmail.com wrote:

  
   Totally agree on this needing another round. Also, hearing about

 the

   plans for a 2.5.1 release which this could potentially be a

 candidate

   for is great.
  
   Thanks again.
  
   On 2012/06/07 09:56:52, t.broyer wrote:
On 2012/06/07 09:22:24, james.horsley wrote:
 Thanks for all your help with the patch Thomas. Sad to hear it

 won't

   make it
 into GWT 2.5 as we were really looking to use RF with Maps

 without

   having to
use
 a patched version of GWT built from source internally.
  
We're planning a 2.5.1 soon after 2.5.
There are also several issues with Map support in AutoBeans

 (reported

   only
recently) which I'd like to get fixed at the same time (some of

 them

   are related
to how maps are encoded/decoded, so I'd like to have it the same

 in

   both
AutoBeans and RF; see
   

 http://code.google.com/p/**google-web-toolkit/issues/**detail?id=7395http://code.google.com/p/google-web-toolkit/issues/detail?id=7395for

   instance,
which you seem to have avoided by using a slightly different
   serialization path
for keys, where String keys are encoded as \foo\, vs. foo

 in

   AutoBean's
serialization).
Finally, to be honest, I think we need at least one more round

 here: I

   need some
more time to wrap my head around it.
  
  
  
  
 


 http://codereview.appspot.com/**6132056/%253Chttps://www.**
 google.com/url?sa=Dq=http://**codereview.appspot.com/**6132056/http://codereview.appspot.com/6132056/%253Chttps://www.google.com/url?sa=Dq=http://codereview.appspot.com/6132056/
 

  
  
  
  


  I'm possibly being a bit eager given 2.5 GA only just went out but

 thought I'd

 just ping on this with regards to the 2.5.1 release that had been

 mentioned.

 Anything new on this?

 https://codereview.appspot.**com/6132056/https://codereview.appspot.com/6132056/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: RequestFactory module - queue, retry and non atomic batching..

[James Horsley]

I'm also quite interested but haven't had time to look.


On 18 July 2013 10:00, salk31 sal...@gmail.com wrote:

 Ho k... I'll be very interested to hear your thoughts... If you think it
 is fixable maybe GAE demo with some UI may be next step for me?


 On Thursday, July 18, 2013 9:49:47 AM UTC+1, Thomas Broyer wrote:

 FYI, I still haven't found the time to look at it…

 On Thursday, July 18, 2013 9:26:35 AM UTC+2, salk31 wrote:

 H. Guess not a lot of demand then. Will hold off doing any more work
 on this.

 Cheers

 Sam

 On Wednesday, July 17, 2013 9:04:53 AM UTC+1, salk31 wrote:

 https://github.com/salk31/gwt-**rf-queuehttps://github.com/salk31/gwt-rf-queue

 I've been allowed to open source this and given two hours a week to
 work on it...

 I thought it was worth sharing now that it compiles and there is a
 working demo. I've grafted it onto the dynatablerf sample and added some
 controls to fake auth and network failure.

 So, any thoughts on if this is worth pushing on with? A real generic
 need? I've missed an existing solution?

 Cheers

 Sam

  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: GWT Meet-up 2013 Videos Slides

[James Horsley]

Thanks for releasing these!


On 15 July 2013 17:38, Jim Douglas jdou...@basis.com wrote:

 The folder isn't public (You need permission to access this item.).

 On Monday, July 15, 2013 3:38:42 PM UTC-7, Bhaskar Janakiraman wrote:

 Hi Folks,
 The videos and slides from the GWT Meet-up conference at Google are
 finally up. I've uploaded them to a newly created GWT Youtube channel:
 http://www.youtube.com/**channel/**UC5tATYhfu8iits6FpVAJv5ghttp://www.youtube.com/channel/UC5tATYhfu8iits6FpVAJv5g

 Slides are available in the shared folder: https://drive.google.**
 com/folderview?id=0B13ku8M7g_**aCU1o1bUZRRUtzOTAusp=sharinghttps://drive.google.com/folderview?id=0B13ku8M7g_aCU1o1bUZRRUtzOTAusp=sharing
 (Not all slides are here yet, but I expect speakers to upload them).

 Thanks to all the speakers for their talks, and all attendees for making
 this a successful event.
 Bhaskar

  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Code splittingmysteries

[James Horsley]

FYI I updated
http://code.google.com/p/google-web-toolkit/issues/detail?id=7874 with some
of my findings. I haven't found a workaround other than reverting to GWT
2.5.0 and am not sure I can dedicate any more time to this right now so
will just revert I guess :(


On 12 June 2013 19:34, Ed post2edb...@gmail.com wrote:

 Ed, out of interest, are you using Gin?

 No, but probably would use it if I would start blank.
 When I started with GWT (about 7 years ago), there was no GIN, so I had to
 make my own thinks like factories, which I use nowadays .  This all
 resulted in having build my own rich gwt framework/lib, which I am happy
 about thought, works well..
 But in general I am careful using external gwt lib's there are many out
 there being not maintained anymore, which can result in gwt upgrade
 problems..
 I started out with mygwt, contributed some things... but then It became
 gxt and became half commercial :(

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Code splittingmysteries

[James Horsley]

Ed, did you ever get this sorted? As I commented on the linked issue I'm 
running into what seems to be a similar problem.

On Wednesday, April 10, 2013 8:13:07 AM UTC+1, Ed wrote:

 I just downgraded to GWT 2.4 and my left over fragment disappeared :(... 
 (initial load was almost the same)
 Strange - or 2.4. had a code splitting involved bug or 2.5. has one...



 On Mon, Mar 25, 2013 at 4:03 PM, Ed Bras post2...@gmail.com javascript:
  wrote:

 BTW: a corresponding issue in the issue tracker: 
 https://code.google.com/p/google-web-toolkit/issues/detail?id=7874
 Let's hope more people are experiencing the same problem (and vote the 
 issue) such that the dev team put it on their priority list.


 On Wed, Mar 20, 2013 at 3:22 PM, Ashton Thomas 
 ash...@acrinta.comjavascript:
  wrote:

 I would also be interested in any updates to this as I am currently 
 working on the async aspect or my app. (I wouldn't even know how to 
 identify anomalies due to a lack of experience here)

 I also remembrer having the same questions with soyc

 -at 


 On Wednesday, March 20, 2013 7:53:11 AM UTC-4, Ed wrote:

 After upgrading from 2.5.0 to 2.5.1 all of a sudden my code splitting 
 result is different:
 + Code fragments are bundles together which weren't before.
 + I have a left over fragment, which was 0 (see attachment).

 What changed concerning code splitting? Can't find any in the release 
 notes.

 A few observations:
 1) All my components have a singleton facade that contains a method to 
 create the package protected  controller implementation that is called 
 through split point (GWT.runAsync()).
 In this way I have a LoginControllerDefault that is present in the left 
 over, but this package protected controller ONLY appears in the 
 LoginFacade.
 In the same way I have SubscribeControllerControllerD**efault that 
 appears only in SubscribeControllerFacade...
 What suprised me is that they appear both in the same code split, 
 namely #30 (see screenshot attachment).

 No idea why.
 I moved the creation of  LoginControllerDefault  from the Facade 
 directly (see below for code snippets) in to the runAsync, but that had 
 no effect.
 I also removed the LoginControllerDefault completely which had little 
 effect on the left-over

 When I read the soyc report (automatically build during maven nightly 
 build), It doesn't really help me. This page is hard to understand, like 
 this page:
soycReport/compile-report/**leftoverStatus-0.html

 Even worse,  from this page you can go deeper  to see why a class is 
 in a certain split point but that results in a page not found (404).
 That is, the following page isn't present. BTW: the page also resulted 
 in a 404 in previous GWT releases.
  soycReport/compile-report/**
 methodDependencies-total-0.**html
 Why?

 I played with the nr of fragmentCount, but that has little effect, 
 see the attached screenshots:
 + fragmentCount = 6: screenshot with 4 splits points.
 + fragmentCount = 8: screenshot with 6 splits points.
 + fragmentCount = 10: screenshot with 7 splits points.

 Below a code snippet that shows how I create the controllers in split 
 point #30 (see screenshot). It concerns the creation of the 
 LoginControllerDefault and SubscribeInfoControllerDefault**.
 Note: I don't find it the most elegant code solution, but before I 
 passed in a Creator interface that was used in GWT.runAsync(), but that 
 didn't work (big left over). I posted that in the forum and it was 
 mentioned that it could be that it is because the code removal is run 
 after 
 the split point code, and that is probably why it doesn't work and that 
 Ray 
 still have a look in to code split code that need to be optimized.

 How to solve/analyze these issues?
 What are your experiences?
 Any suggestions are more then welcome as I am out of ideas and find it 
 hard to solve this, but it frustrates me ;)


 Loading and creating the the Login and SubscribeInfo controller:
 -
 The code snippet that is called by the LoginControllerBuilder to load 
 the Login controller:
  public void create(final AsyncCallbackLoginController callback) {
 getLazyLoader().**createInCodeSplitGeneral30(**LoginController.class, 
 callback);
  }


 The controller loading code (in other class):
 public T void createInCodeSplitGeneral30(**final ClassT type, 
 final AsyncCallbackT callback, final SimpleMediator mediator) {
  GWT.runAsync(new RunAsyncCallback() {
 public void onSuccess() {
 callback.onSuccess(**createCodeSplitGeneral30(type, mediator));
  }

 public void onFailure(final Throwable reason) {
 callback.onFailure(reason);
  }
 });
 }

 @SuppressWarnings(unchecked)
  private T T createCodeSplitGeneral30(final ClassT type, final 
 SimpleMediator mediator) {
 if (isType(type, LoginController.class)) {
  return (T) LoginFacade.getInstance().**createController();
 }
 else if (isType(type, SubscribeController.class)) {
  return (T) SubscribeFacade.getInstance().**createController();

Re: Code splittingmysteries

[James Horsley]

Yeah. I've tried reproducing the issue with a sample app but thus far
haven't been able to; not sure that the sample webapp captures enough of
the complexity of the actual webapp we're having the problem with. As I
mentioned before can confirm that changing none of the webapp code but
switching between 2.5 and 2.5.1 causes everything to end up in the
leftover. From the compiler report it's not at all obvious why these
classes are in the leftover fragment as they look isolated from what I can
tell.


On 12 June 2013 13:13, Ed post2edb...@gmail.com wrote:

  Ed, did you ever get this sorted? As I commented on the linked issue I'm
 running into what seems to be a similar problem.

 No. It's hard to track the exact cause. It tried, but had to give up (a
 lot of time, and not knowing exactly what happens.
 But it's good to see that more people are experiencing the same kind of
 problems such that I am not alone ;)
 Ray seem to be the code splitting guru. Let's hope he has has some time to
 look at this ;)

 If you can isolate the problem in a small program that reproduces this
 behavior, please do upload it in the issue. I tried, but failed :(
 This will help the gwt dev team a lot to solve the problem (and the issue
 will get a higher priority and solved sooner).

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Code splittingmysteries

[James Horsley]

Quite frustrating as I don't feel like I'm making much progress and am just
going to have to go back to 2.5.0 but don't really want to lose out on the
bugfixes from 2.5.1 :(


On 12 June 2013 15:45, James Horsley james.hors...@gmail.com wrote:

 Yeah. I've tried reproducing the issue with a sample app but thus far
 haven't been able to; not sure that the sample webapp captures enough of
 the complexity of the actual webapp we're having the problem with. As I
 mentioned before can confirm that changing none of the webapp code but
 switching between 2.5 and 2.5.1 causes everything to end up in the
 leftover. From the compiler report it's not at all obvious why these
 classes are in the leftover fragment as they look isolated from what I can
 tell.


 On 12 June 2013 13:13, Ed post2edb...@gmail.com wrote:

  Ed, did you ever get this sorted? As I commented on the linked issue I'm
 running into what seems to be a similar problem.

 No. It's hard to track the exact cause. It tried, but had to give up (a
 lot of time, and not knowing exactly what happens.
 But it's good to see that more people are experiencing the same kind of
 problems such that I am not alone ;)
 Ray seem to be the code splitting guru. Let's hope he has has some time
 to look at this ;)

 If you can isolate the problem in a small program that reproduces this
 behavior, please do upload it in the issue. I tried, but failed :(
 This will help the gwt dev team a lot to solve the problem (and the issue
 will get a higher priority and solved sooner).

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Code splittingmysteries

[James Horsley]

Yeah. the SOYC report in this case hasn't helped me much either because I'm
not reading it right or it's just not surfacing the right info. The only
404 I get is regarding the compiler metrics link.


On 12 June 2013 16:18, Ed Bras post2edb...@gmail.com wrote:

 Yep, tried to go back to 2.5, but then I see some other bugs that are
 solved in 2.5.1 ;)... So for me this was no option...


 On Wed, Jun 12, 2013 at 5:17 PM, Ed Bras post2edb...@gmail.com wrote:

 Yes, I understand what you mean, I experienced the same...
 It's hard to hand over a test case that fails, to the dev team, such
 that they can use that to work on :(

 Yes it would be nice to have better  facilities such that we can try to
 track done the cause our self. Currently the SOYC report isn't helping a
 lot.
 To my experience the SOYC report is buggy, as some pages result in a 404
 :(.. (I experienced that several times the last years with a correctly
 created soyc, it's also in some issue if I remember correctly).



 On Wed, Jun 12, 2013 at 4:45 PM, James Horsley 
 james.hors...@gmail.comwrote:

 Yeah. I've tried reproducing the issue with a sample app but thus far
 haven't been able to; not sure that the sample webapp captures enough of
 the complexity of the actual webapp we're having the problem with. As I
 mentioned before can confirm that changing none of the webapp code but
 switching between 2.5 and 2.5.1 causes everything to end up in the
 leftover. From the compiler report it's not at all obvious why these
 classes are in the leftover fragment as they look isolated from what I can
 tell.


 On 12 June 2013 13:13, Ed post2edb...@gmail.com wrote:

  Ed, did you ever get this sorted? As I commented on the linked issue
 I'm running into what seems to be a similar problem.

 No. It's hard to track the exact cause. It tried, but had to give up (a
 lot of time, and not knowing exactly what happens.
 But it's good to see that more people are experiencing the same kind of
 problems such that I am not alone ;)
 Ray seem to be the code splitting guru. Let's hope he has has some time
 to look at this ;)

 If you can isolate the problem in a small program that reproduces this
 behavior, please do upload it in the issue. I tried, but failed :(
 This will help the gwt dev team a lot to solve the problem (and the
 issue will get a higher priority and solved sooner).

 --
 You received this message because you are subscribed to the Google
 Groups Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to
 google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




  --
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit/_8CdVbBb488/unsubscribe?hl=en
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com
 .
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.





  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Code splittingmysteries

[James Horsley]

Ed, out of interest, are you using Gin?


On 12 June 2013 16:29, James Horsley james.hors...@gmail.com wrote:

 Yeah. the SOYC report in this case hasn't helped me much either because
 I'm not reading it right or it's just not surfacing the right info. The
 only 404 I get is regarding the compiler metrics link.


 On 12 June 2013 16:18, Ed Bras post2edb...@gmail.com wrote:

 Yep, tried to go back to 2.5, but then I see some other bugs that are
 solved in 2.5.1 ;)... So for me this was no option...


 On Wed, Jun 12, 2013 at 5:17 PM, Ed Bras post2edb...@gmail.com wrote:

 Yes, I understand what you mean, I experienced the same...
 It's hard to hand over a test case that fails, to the dev team, such
 that they can use that to work on :(

 Yes it would be nice to have better  facilities such that we can try to
 track done the cause our self. Currently the SOYC report isn't helping a
 lot.
 To my experience the SOYC report is buggy, as some pages result in a 404
 :(.. (I experienced that several times the last years with a correctly
 created soyc, it's also in some issue if I remember correctly).



 On Wed, Jun 12, 2013 at 4:45 PM, James Horsley 
 james.hors...@gmail.comwrote:

 Yeah. I've tried reproducing the issue with a sample app but thus far
 haven't been able to; not sure that the sample webapp captures enough of
 the complexity of the actual webapp we're having the problem with. As I
 mentioned before can confirm that changing none of the webapp code but
 switching between 2.5 and 2.5.1 causes everything to end up in the
 leftover. From the compiler report it's not at all obvious why these
 classes are in the leftover fragment as they look isolated from what I can
 tell.


 On 12 June 2013 13:13, Ed post2edb...@gmail.com wrote:

  Ed, did you ever get this sorted? As I commented on the linked issue
 I'm running into what seems to be a similar problem.

 No. It's hard to track the exact cause. It tried, but had to give up
 (a lot of time, and not knowing exactly what happens.
 But it's good to see that more people are experiencing the same kind
 of problems such that I am not alone ;)
 Ray seem to be the code splitting guru. Let's hope he has has some
 time to look at this ;)

 If you can isolate the problem in a small program that reproduces this
 behavior, please do upload it in the issue. I tried, but failed :(
 This will help the gwt dev team a lot to solve the problem (and the
 issue will get a higher priority and solved sooner).

 --
 You received this message because you are subscribed to the Google
 Groups Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to
 google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




  --
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit/_8CdVbBb488/unsubscribe?hl=en
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to
 google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.





  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Work to do for bug 3042

[James Horsley]

Adolfo,

To get the source checked out and compiling follow:
http://www.gwtproject.org/makinggwtbetter.html#workingoncode

To submit the patch use:
http://www.gwtproject.org/makinggwtbetter.html#submittingpatches

I recently had to move an old svn patch into gerrit and the following gave
a very simple way to apply it
http://stackoverflow.com/questions/659467/how-to-apply-svn-diff-to-git just
remember to clean up any leftover .orij and .rej files.

Cheers,
James


On 10 June 2013 10:01, Adolfo Panizo adolfo.pan...@gmail.com wrote:

 Hi,

 as I wrote in the 
 issuehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=3042,
 I am able to do the necessary work for solving it.  So, can you guide me
 about the steps that I need to follow in order to create a patch properly?

 Would you like to reuse some code of the old 
 patchhttp://gwt-code-reviews.appspot.com/1388802/
 ?

 I am going to contact the creator of it because maybe he continues
 interested on fixing the issue and rebase the patch with the last code.

 Of course if there are other issues related to RichTextArea I can solve as
 well.

 Thanks in advance,

 Adolfo.


  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Redoing existing svn patch https://codereview.appspot.com/61...

[James Horsley]

James Horsley has uploaded a new change for review.

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


Change subject: Redoing existing svn patch  
https://codereview.appspot.com/6132056/ on new git repo to work with gerrit.

..

Redoing existing svn patch https://codereview.appspot.com/6132056/ on new  
git

repo to work with gerrit.

This patch adds Map support to RequestFactory (see
https://code.google.com/p/google-web-toolkit/issues/detail?id=5524)

There's a lot of existing discussion on the patch at
https://codereview.appspot.com/6132056/. From looking back over that  
discussion
the main user facing design decision to call out which isn't just what  
someone
might expect from Map support is that referencing child complex types in  
keys

and values is done using .with(someMap.keys.property,
someMap.values.property )

Change-Id: I89d87d39e38b8f1df045494cbe655a44849a650b
---
M  
user/src/com/google/web/bindery/requestfactory/apt/ClientToDomainMapper.java
M  
user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java

M user/src/com/google/web/bindery/requestfactory/server/Resolver.java
A user/src/com/google/web/bindery/requestfactory/server/Resolver.java.orig
M  
user/src/com/google/web/bindery/requestfactory/server/ResolverServiceLayer.java
A  
user/src/com/google/web/bindery/requestfactory/server/ResolverServiceLayer.java.orig
M  
user/src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java
A  
user/src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java.orig
M  
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
A  
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java.orig
A  
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java.rej
M  
user/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java
M  
user/src/com/google/web/bindery/requestfactory/shared/impl/ProxySerializerImpl.java
M  
user/test/com/google/web/bindery/requestfactory/gwt/client/FindServiceTest.java
M  
user/test/com/google/web/bindery/requestfactory/gwt/client/RequestFactoryTest.java
A  
user/test/com/google/web/bindery/requestfactory/gwt/client/RequestFactoryTest.java.orig
A  
user/test/com/google/web/bindery/requestfactory/gwt/client/RequestFactoryTest.java.rej

A user/test/com/google/web/bindery/requestfactory/server/MapKey.java
A user/test/com/google/web/bindery/requestfactory/server/MapValue.java
M user/test/com/google/web/bindery/requestfactory/server/SimpleFoo.java
A user/test/com/google/web/bindery/requestfactory/server/SimpleFoo.java.orig
M user/test/com/google/web/bindery/requestfactory/shared/BaseFooProxy.java
A user/test/com/google/web/bindery/requestfactory/shared/MapKeyProxy.java
A user/test/com/google/web/bindery/requestfactory/shared/MapKeyRequest.java
A user/test/com/google/web/bindery/requestfactory/shared/MapValueProxy.java
A  
user/test/com/google/web/bindery/requestfactory/shared/MapValueRequest.java

M user/test/com/google/web/bindery/requestfactory/shared/SimpleBarProxy.java
M  
user/test/com/google/web/bindery/requestfactory/shared/SimpleRequestFactory.java

28 files changed, 7,973 insertions(+), 46 deletions(-)




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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I89d87d39e38b8f1df045494cbe655a44849a650b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Horsley james.hors...@gmail.com

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Redoing existing svn patch https://codereview.appspot.com/61...

[James Horsley]

James Horsley has posted comments on this change.

Change subject: Redoing existing svn patch  
https://codereview.appspot.com/6132056/ on new git repo to work with gerrit.

..


Patch Set 1:

Ick sorry. Will submit a new patch. Should just discard this one or update  
it?


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

Gerrit-MessageType: comment
Gerrit-Change-Id: I89d87d39e38b8f1df045494cbe655a44849a650b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Horsley james.hors...@gmail.com
Gerrit-Reviewer: James Horsley james.hors...@gmail.com
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Adds Map support to RequestFactory (see https://code.google....

[James Horsley]

James Horsley has uploaded a new change for review.

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


Change subject: Adds Map support to RequestFactory (see  
https://code.google.com/p/google-web-toolkit/issues/detail?id=5524)

..

Adds Map support to RequestFactory (see
https://code.google.com/p/google-web-toolkit/issues/detail?id=5524)

This is a port of an existing svn patch  
https://codereview.appspot.com/6132056/

onto the new git repo to work with gerrit.

There's a lot of existing discussion on the patch at
https://codereview.appspot.com/6132056/. From looking back over that  
discussion
the main user facing design decision to call out which isn't just what  
someone
might expect from Map support is that referencing child complex types in  
keys

and values is done using .with(someMap.keys.property,
someMap.values.property )

Change-Id: I6dd3c8a9862473954a72ccee96212c20d9198b22
---
M  
user/src/com/google/web/bindery/requestfactory/apt/ClientToDomainMapper.java
M  
user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java

M user/src/com/google/web/bindery/requestfactory/server/Resolver.java
M  
user/src/com/google/web/bindery/requestfactory/server/ResolverServiceLayer.java
M  
user/src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java
M  
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
M  
user/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java
M  
user/src/com/google/web/bindery/requestfactory/shared/impl/ProxySerializerImpl.java
M  
user/test/com/google/web/bindery/requestfactory/gwt/client/FindServiceTest.java
M  
user/test/com/google/web/bindery/requestfactory/gwt/client/RequestFactoryTest.java

A user/test/com/google/web/bindery/requestfactory/server/MapKey.java
A user/test/com/google/web/bindery/requestfactory/server/MapValue.java
M user/test/com/google/web/bindery/requestfactory/server/SimpleFoo.java
M user/test/com/google/web/bindery/requestfactory/shared/BaseFooProxy.java
A user/test/com/google/web/bindery/requestfactory/shared/MapKeyProxy.java
A user/test/com/google/web/bindery/requestfactory/shared/MapKeyRequest.java
A user/test/com/google/web/bindery/requestfactory/shared/MapValueProxy.java
A  
user/test/com/google/web/bindery/requestfactory/shared/MapValueRequest.java

M user/test/com/google/web/bindery/requestfactory/shared/SimpleBarProxy.java
M  
user/test/com/google/web/bindery/requestfactory/shared/SimpleRequestFactory.java

20 files changed, 897 insertions(+), 46 deletions(-)



diff --git  
a/user/src/com/google/web/bindery/requestfactory/apt/ClientToDomainMapper.java  
b/user/src/com/google/web/bindery/requestfactory/apt/ClientToDomainMapper.java

index dd1f28c..2eac320 100644
---  
a/user/src/com/google/web/bindery/requestfactory/apt/ClientToDomainMapper.java
+++  
b/user/src/com/google/web/bindery/requestfactory/apt/ClientToDomainMapper.java

@@ -17,6 +17,7 @@

 import java.util.Collection;
 import java.util.List;
+import java.util.Map;
 import java.util.Set;

 import javax.lang.model.element.ElementKind;
@@ -99,6 +100,12 @@
   TypeMirror param = convertSingleParamType(x,  
state.findType(Collection.class), 0, state);
   return state.types.getDeclaredType((TypeElement)  
state.types.asElement(x), param);

 }
+if (state.types.isAssignable(x, state.findType(Map.class))) {
+  // Convert MapString,FooProxy to MapString,FooDomain
+  TypeMirror keyParam = convertSingleParamType(x,  
state.findType(Map.class), 0, state);
+  TypeMirror valueParam = convertSingleParamType(x,  
state.findType(Map.class), 1, state);
+  return state.types.getDeclaredType((TypeElement)  
state.types.asElement(x), keyParam, valueParam);

+}
 return defaultAction(x, state);
   }

diff --git  
a/user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java  
b/user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java

index 9d47dd1..8663ad5 100644
---  
a/user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java
+++  
b/user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java

@@ -17,6 +17,7 @@

 import java.util.Collection;
 import java.util.List;
+import java.util.Map;
 import java.util.Set;

 import javax.lang.model.element.ElementKind;
@@ -77,6 +78,19 @@
   }
   return t.getTypeArguments().get(0).accept(this, state);
 }
+if (state.types.isAssignable(t, state.findType(Map.class))) {
+  if (!allowNestedParameterization) {
+return false;
+  }
+  allowNestedParameterization = false;
+  DeclaredType asMap =
+  (DeclaredType) State.viewAs(state.findType(Map.class), t, state);
+  if (asMap.getTypeArguments().isEmpty()) {
+return false;
+  }
+  return t.getTypeArguments().get(0).accept(this, state)
+   t.getTypeArguments().get(1).accept

[gwt-contrib] Change in gwt[master]: Redoing existing svn patch https://codereview.appspot.com/61...

[James Horsley]

James Horsley has abandoned this change.

Change subject: Redoing existing svn patch  
https://codereview.appspot.com/6132056/ on new git repo to work with gerrit.

..


Abandoned

Contains unintended .orig and .rej files. Resubmitted with  
https://gwt-review.googlesource.com/#/c/3186/


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

Gerrit-MessageType: abandon
Gerrit-Change-Id: I89d87d39e38b8f1df045494cbe655a44849a650b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Horsley james.hors...@gmail.com
Gerrit-Reviewer: James Horsley james.hors...@gmail.com
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Redoing existing svn patch https://codereview.appspot.com/61...

[James Horsley]

James Horsley has posted comments on this change.

Change subject: Redoing existing svn patch  
https://codereview.appspot.com/6132056/ on new git repo to work with gerrit.

..


Patch Set 1:

Will remember for next time. Thanks!

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

Gerrit-MessageType: comment
Gerrit-Change-Id: I89d87d39e38b8f1df045494cbe655a44849a650b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Horsley james.hors...@gmail.com
Gerrit-Reviewer: James Horsley james.hors...@gmail.com
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: RequestFactory Feature Request: @Immutable EntityProxy, reduced payload size, Map support.

[James Horsley]

Thanks for the udpate and good luck with the modularization work, I saw one
of the dependency graphs you'd shared on g+ and it looked pretty gnarly =/


On 17 April 2013 23:12, Thomas Broyer t.bro...@gmail.com wrote:



 On Wednesday, April 17, 2013 12:17:25 PM UTC+2, James Horsley wrote:

 Hey Thomas,

 Totally understand that modularization and mavenization are top
 priorities but does that mean my Map support patch need to wait until after
 GWT 2.6?


 I'm afraid it'll have to; or put differently I can't guarantee it'll be in
 2.6, and I wouldn't want to delay 2.6 for that patch (sorry). Time will
 tell.

 --
 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: RequestFactory Feature Request: @Immutable EntityProxy, reduced payload size, Map support.

[James Horsley]

Hey Thomas,

Totally understand that modularization and mavenization are top priorities
but does that mean my Map support patch need to wait until after GWT 2.6? I
know things have been in a transitional period but I submitted the patch
almost a year ago now and would love to get the support in; let me know if
there's anything I can do to help get the patch in a better position to go
out.

Hopefully not coming across too negatively as things seem to be picking up
pace in a great way for GWT in the last few months, just would love to get
Map support integrated.

Cheers,
James


On 16 April 2013 23:56, Thomas Broyer t.bro...@gmail.com wrote:


 On Tuesday, April 16, 2013 7:43:12 PM UTC+2, Stefan Ollinger wrote:

 Hi,

 when editing large object graphs on the client-side, there are currently
 two problems regarding performance:

 1) Entity proxies could not be modified when firing a RequestContext. A
 diff will be done nevertheless, which costs CPU time. There could be an
 annotation which marks entity proxies as immutable on the client-side and
 forces RF to always send the EntityProxyId.

 2) All reachable value proxies on the edited data will be sent, even if
 the owner entity proxies did not change. This increases the payload size
 and could be avoided by sending only those values proxies which are
 reachable through actually edited entity proxies (or request arguments).
 There is already a todo in https://code.google.com/p/**
 google-web-toolkit/source/**browse/trunk/user/src/com/**
 google/web/bindery/**requestfactory/shared/impl/**
 AbstractRequestContext.java#**1211https://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java#1211

 Are you aware of those problems, and are they relevant enough to be taken
 into account in one of the next releases?

 Also is there a plan to add support for Maps (https://codereview.appspot.
 **com/6132056/ https://codereview.appspot.com/6132056/.)?


 Hi Stefan. I'm the one responsible for RF, and my priorities for now are
 on modularization and mavenization.
 Once that's done I'll be back to working on RF. That'll likely be after
 GWT 2.6 lands though.
 Apart from bug fixes and other enhancements (the TODO you're talking
 about), there are a bunch of things I'd like to add/change (e.g. more
 code-gen to use reflection less)
 The @Immutable annotation you're proposing is probably not needed; we
 could base our decision on whether there are setters or only getters.

 --
 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: I/O 2013 - GWT Sessions?

[James Horsley]

+1 for a separate GWT convention


On 7 March 2013 06:06, Steve strat...@gmail.com wrote:

 Now that GWT is more community run, I think it would be better if we just
 had our own convention...

 I went to the second I/O, and GWT was all over the place. Then each year
 after there were fewer and fewer session, more free swag, and an android
 push. On top of that, there is such a media hype about the event nowadays
 that it's become less and less about developers and more and more about
 Oh, look what we did! And here's some free stuff! Not a developer? No
 problem! See the show! Here's some more free stuff!.

 It's a shame. I don't even think all of the GWT session videos made it up
 on youtube. They had some great pointers...



 On Wednesday, March 6, 2013 5:56:52 PM UTC-5, James wrote:

 I know it's earlybut is anyone familiar with the planned Google Web
 Toolkit sessions for Google I/O 2013?  It was a bit disappointing last year
 when there was only one real GWT session...after there had been many in all
 the previous years.  GWT Team...any comments?

  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: RequestFactory issue with overloaded setters in domain type

[James Horsley]

I'll take a stab at writing a ServiceLayerDecorator as that should get me
unblocked without writing DTO's and if the correct setter is called the
NPE's won't be an issue. Thanks to you both for the suggestions!

Thomas, is this issue likely to end up as PatchesWelcome or WontFix? If the
former then I'll look at getting a patch together.



On 28 February 2013 11:19, Thomas Broyer t.bro...@gmail.com wrote:



 On Thursday, February 28, 2013 11:18:22 AM UTC+1, Ignacio Baca
 Moreno-Torres wrote:

 If you don't want to have a delegator DTO, you may try AOP. For example,
 with guice you can match the classes you have the NPE problem, and return
 null before de NPE.


 or in this specific case, use a ServiceLayerDecorator whose getSetter
 returns the appropriate setter for the given known class and property name
 (or possibly do the right thing in setProperty, without the need to go down
 to the java.lang.reflect level)

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: RequestFactory issue with overloaded setters in domain type

[James Horsley]

Makes sense. Thanks!


On 28 February 2013 13:27, Thomas Broyer t.bro...@gmail.com wrote:



 On Thursday, February 28, 2013 1:50:03 PM UTC+1, James Horsley wrote:

 I'll take a stab at writing a ServiceLayerDecorator as that should get me
 unblocked without writing DTO's and if the correct setter is called the
 NPE's won't be an issue. Thanks to you both for the suggestions!

 Thomas, is this issue likely to end up as PatchesWelcome or WontFix? If
 the former then I'll look at getting a patch together.


 I you send a patch, I'll look at it; the outcome will depend on what
 changes the patch has to make.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: RequestFactory issue with overloaded setters in domain type

[James Horsley]

 FYI writing my own ServiceLayerDecorator with the following worked like a
charm so extra thanks for the suggestion

private static Method getBeanMethod( BeanMethod methodType, Class?
domainType, String property, Class? propertyType ) {
for ( Method m : domainType.getMethods() ) {
if ( methodType.matches( m )  property.equals(
methodType.inferName( m ) )
 m.getParameterTypes()[0].isAssignableFrom(
propertyType ) ) {
m.setAccessible( true );
return m;
}
}
return null;
}

@Override
public Method getSetter( Class? domainType, String property ) {
Class? propertyType = getTop().getGetter( domainType, property
).getReturnType();
Method setter = getBeanMethod( BeanMethod.SET, domainType,
property, propertyType );
if ( setter == null ) {
setter = getBeanMethod( BeanMethod.SET_BUILDER, domainType,
property, propertyType );
}
return setter;
}


On 28 February 2013 13:44, James Horsley james.hors...@gmail.com wrote:

 Makes sense. Thanks!


 On 28 February 2013 13:27, Thomas Broyer t.bro...@gmail.com wrote:



 On Thursday, February 28, 2013 1:50:03 PM UTC+1, James Horsley wrote:

 I'll take a stab at writing a ServiceLayerDecorator as that should get
 me unblocked without writing DTO's and if the correct setter is called the
 NPE's won't be an issue. Thanks to you both for the suggestions!

 Thomas, is this issue likely to end up as PatchesWelcome or WontFix? If
 the former then I'll look at getting a patch together.


 I you send a patch, I'll look at it; the outcome will depend on what
 changes the patch has to make.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

RequestFactory issue with overloaded setters in domain type

[James Horsley]

I'm running into an issue where RequestFactory isn't calling the correct
setter on the domain object in DevMode and I've not tried it compiled yet.
Looking at the code it appears that ReflectiveServiceLayer.getBeanMethod is
just picking the first setter it finds based on SET/SET_BUILDER, are only
verifying that the method is a setter, and the method name.

I was going to submit an issue for it and see about getting a patch
together but thought I'd ask here first to see if I'm missing something.

A more concrete example that I'm running into is that the domain class has
something like the following:

DomainClass.java
void setUnit(String unit) { this.unit = unit; }
void setUnit(SomeUnitEnum unit) { this.unit = unit.toString(); }

ProxyInterface.java
void setUnit(String unit);
String getUnit();

when unit is null, the server side RF code is calling the enum version
which is causing an NPE.

Anything I'm missing or should just file the issue?

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: RequestFactory issue with overloaded setters in domain type

[James Horsley]

Thanks for the quick and detailed reply.

Given a big win using RequestFactory is having it work well with existing
server side data models it'd seem like something we'd want to fix, relative
to other priorities of course. In this specifc case I don't own the domain
class as it's from a 3rd party and it's been fantastic with RF to just use
a proxy interface to pass the data across without another DTO. I can extend
it in this specific case to override the behaviour of setUnit(SomeUnitEnum)
but that's not always possible and I'm still at the mercy of the order the
methods are iterated in as to what type I have to use in my Proxy
interface, this throws it into the want to fix case for me (not surprising
perhaps given I'm the one asking the question).

I'll file an issue for it and am fully behind the fact that if I think it's
important that I should get a patch out for it so will try to do that. The
geTop().getGetter(domainClass, property) suggestion you made sounds like a
quick and mildly dirty way through; although I may look at the first
fallback based solution you mentioned.

Cheers,
James




On 27 February 2013 16:05, Thomas Broyer t.bro...@gmail.com wrote:



 On Wednesday, February 27, 2013 4:05:30 PM UTC+1, James Horsley wrote:

 I'm running into an issue where RequestFactory isn't calling the correct
 setter on the domain object in DevMode and I've not tried it compiled yet.
 Looking at the code it appears that ReflectiveServiceLayer.**getBeanMethod
 is just picking the first setter it finds based on SET/SET_BUILDER, are
 only verifying that the method is a setter, and the method name.

 I was going to submit an issue for it and see about getting a patch
 together but thought I'd ask here first to see if I'm missing something.

 A more concrete example that I'm running into is that the domain class
 has something like the following:

 DomainClass.java
 void setUnit(String unit) { this.unit = unit; }
 void setUnit(SomeUnitEnum unit) { this.unit = unit.toString(); }

 ProxyInterface.java
 void setUnit(String unit);
 String getUnit();

 when unit is null, the server side RF code is calling the enum version
 which is causing an NPE.

 Anything I'm missing or should just file the issue?


 Fixing this would require breaking changes in ServiceLayerDecorator though
 (getSetter would need a new expectedType parameter, similar to setProperty)
 so I wonder how best we could provide backwards compatibility (ideally,
 getSetter(Class,String,Class) would fallback to getSetter(Class,String) (to
 ensure backwards compatibility with custom ServiceLayerDecorators) but we'd
 then like ReflectiveServiceLayer#getSetter(Class,String) to answer based on
 the Class originally passed to getSetter(Class,String,Class).
 Alternatively, ReflectiveServiceLayer#getSetter could call
 getTop().getGetter(domainClass, property) and then use the getter's return
 type to disambiguate overloaded setters. That would then make it impossible
 to have proxies with setter-only properties (see
 https://code.google.com/p/google-web-toolkit/issues/detail?id=5760,
 there's much to be done before this can be supported, so the server-side
 implementation might be revisited at that point, i.e. not a showstopper)

 The question is: is this something we really *want* to fix? And honestly,
 I don't have a problem rejecting overloaded setters (see also the comment
 on https://code.google.com/p/google-web-toolkit/issues/detail?id=6587: if
 it weren't for protobuf where the idiom is common, having overloaded
 hasXxx and getXxx getters would have been declared illegal).

 Feel free to file an issue, but be warned that I'll categorize it as
 PatchesWelcome.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: RequestFactory issue with overloaded setters in domain type

[James Horsley]

Issue filed
https://code.google.com/p/google-web-toolkit/issues/detail?id=8039


On 27 February 2013 17:04, James Horsley james.hors...@gmail.com wrote:

 Thanks for the quick and detailed reply.

 Given a big win using RequestFactory is having it work well with existing
 server side data models it'd seem like something we'd want to fix, relative
 to other priorities of course. In this specifc case I don't own the domain
 class as it's from a 3rd party and it's been fantastic with RF to just use
 a proxy interface to pass the data across without another DTO. I can extend
 it in this specific case to override the behaviour of setUnit(SomeUnitEnum)
 but that's not always possible and I'm still at the mercy of the order the
 methods are iterated in as to what type I have to use in my Proxy
 interface, this throws it into the want to fix case for me (not surprising
 perhaps given I'm the one asking the question).

 I'll file an issue for it and am fully behind the fact that if I think
 it's important that I should get a patch out for it so will try to do that.
 The geTop().getGetter(domainClass, property) suggestion you made sounds
 like a quick and mildly dirty way through; although I may look at the first
 fallback based solution you mentioned.

 Cheers,
 James




 On 27 February 2013 16:05, Thomas Broyer t.bro...@gmail.com wrote:



 On Wednesday, February 27, 2013 4:05:30 PM UTC+1, James Horsley wrote:

 I'm running into an issue where RequestFactory isn't calling the correct
 setter on the domain object in DevMode and I've not tried it compiled yet.
 Looking at the code it appears that ReflectiveServiceLayer.**getBeanMethod
 is just picking the first setter it finds based on SET/SET_BUILDER, are
 only verifying that the method is a setter, and the method name.

 I was going to submit an issue for it and see about getting a patch
 together but thought I'd ask here first to see if I'm missing something.

 A more concrete example that I'm running into is that the domain class
 has something like the following:

 DomainClass.java
 void setUnit(String unit) { this.unit = unit; }
 void setUnit(SomeUnitEnum unit) { this.unit = unit.toString(); }

 ProxyInterface.java
 void setUnit(String unit);
 String getUnit();

 when unit is null, the server side RF code is calling the enum version
 which is causing an NPE.

 Anything I'm missing or should just file the issue?


 Fixing this would require breaking changes in ServiceLayerDecorator
 though (getSetter would need a new expectedType parameter, similar to
 setProperty) so I wonder how best we could provide backwards compatibility
 (ideally, getSetter(Class,String,Class) would fallback to
 getSetter(Class,String) (to ensure backwards compatibility with custom
 ServiceLayerDecorators) but we'd then like
 ReflectiveServiceLayer#getSetter(Class,String) to answer based on the Class
 originally passed to getSetter(Class,String,Class). Alternatively,
 ReflectiveServiceLayer#getSetter could call getTop().getGetter(domainClass,
 property) and then use the getter's return type to disambiguate overloaded
 setters. That would then make it impossible to have proxies with
 setter-only properties (see
 https://code.google.com/p/google-web-toolkit/issues/detail?id=5760,
 there's much to be done before this can be supported, so the server-side
 implementation might be revisited at that point, i.e. not a showstopper)

 The question is: is this something we really *want* to fix? And honestly,
 I don't have a problem rejecting overloaded setters (see also the comment
 on https://code.google.com/p/google-web-toolkit/issues/detail?id=6587:
 if it weren't for protobuf where the idiom is common, having overloaded
 hasXxx and getXxx getters would have been declared illegal).

 Feel free to file an issue, but be warned that I'll categorize it as
 PatchesWelcome.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Fix problem where hidden scrollbars prevent clicks through to the scrollable content area on Chr... (issue1886803)

[james . horsley]

On 2013/01/25 19:44:41, Andrew Bachmann wrote:

I was going to submit the exact same patch, so can give a +1 for it
working fine on chrome and FF on win 7.

http://gwt-code-reviews.appspot.com/1886803/

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT 2.5.1 release - Call for help

[James Horsley]

Thanks Thomas. I'm happy to make any necessary changes to the patch so let
me know when you get more time to look it over again as I know you'd said
it was a big enough change to warrant a long look.


On 15 January 2013 12:24, Thomas Broyer t.bro...@gmail.com wrote:



 On Tuesday, January 15, 2013 12:02:54 PM UTC+1, James Horsley wrote:

 Anything I can do with 
 https://codereview.appspot.**com/6132056/https://codereview.appspot.com/6132056/to
  help get it ready to go out with whatever release is deemed appropriate?


 Won't make it to 2.5.1 sorry. For the next release after 2.5.1, my first
 task is to finish modularizing and mavenizing GWT, and only then I'll get
 back to fully work on fixing issues.

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT 2.5.1 release - Call for help

[James Horsley]

Anything I can do with https://codereview.appspot.com/6132056/ to help get
it ready to go out with whatever release is deemed appropriate?


On 13 January 2013 18:24, Patrick Tucker tucker...@gmail.com wrote:

 Any chance these can get committed?

 http://gwt-code-reviews.appspot.com/1876803/
 http://gwt-code-reviews.appspot.com/1762803/
 http://gwt-code-reviews.appspot.com/1833803/
 http://gwt-code-reviews.appspot.com/1785803/
 http://gwt-code-reviews.appspot.com/1736804/

 On Saturday, January 12, 2013 11:02:41 AM UTC-5, Daniel Kurka wrote:

 Repost from gwt-steering:

 Hi Everyone,

 a quick status update. In the last week a lot of patches have been
 contributed and some have already been submitted.

 At the beginning of next week I want to close of for any new patches, so
 that we can finish the work we are started.
 We are aiming for a code freeze at the 24th of Januar and a release a
 short time after that.

 So once again, if you feel strongly that you need to have something
 included in GWT 2.5.1 now is the time to act.
 We also have a couple of open issues that we would like to see in GWT
 2.5.1, but might not make it (see: https://docs.google.com/**
 spreadsheet/ccc?key=**0AuK8EZ6jAAQrdDk1ME1lcmtWOWt3M**ngxOUlTMGJSVEEhttps://docs.google.com/spreadsheet/ccc?key=0AuK8EZ6jAAQrdDk1ME1lcmtWOWt3MngxOUlTMGJSVEE
 ).
 Feel free to to contribute patches and do code reviews on the issues
 listed in the document.

 -Daniel

 On Saturday, January 12, 2013 4:17:29 PM UTC+1, Thomas Broyer wrote:



 On Saturday, January 12, 2013 3:40:42 PM UTC+1, Julien Dramaix wrote:

 It would be nice to adapt the following paragraph [1]  to explain the
 procedure for submitting code in gerrit. This paragraph is
 still mentioning svn


 [1] : https://developers.google.com/**web-toolkit/makinggwtbetter?#**
 submittingpatcheshttps://developers.google.com/web-toolkit/makinggwtbetter?#submittingpatches


 I think the idea was to wait until the move to Git is complete. For now
 the Git repo is still a mirror of the SVN repo (git-svn) which is a mirror
 of Google's internal Perforce.
 To complete the move, we'll rewrite the history to remove all big files
 (prebuilt plugins and api-checker reference jars) so all contributors will
 have to re-sync their Git repo.
 So in the mean time, SVN and Rietveld is still OK, though deprecated.

   --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT 2.5.1 release - Call for help

[James Horsley]

Any chance of
http://code.google.com/p/google-web-toolkit/issues/detail?id=5524 making it
into the release since it already has a patch out, or is that too big of a
change for this point release?


On 9 January 2013 13:26, Daniel Kurka kurka.dan...@gmail.com wrote:

 Hello everyone,

 we are gearing up for the GWT 2.5.1 release.

 We already made a list of issues that are considered for the GWT 2.5.1
 release: https://docs.google.**com/spreadsheet/ccc?key=**
 0AuK8EZ6jAAQrdDk1ME1lcmtWOWt3M**ngxOUlTMGJSVEEhttps://docs.google.com/spreadsheet/ccc?key=0AuK8EZ6jAAQrdDk1ME1lcmtWOWt3MngxOUlTMGJSVEE
 We are looking for help on some of the issues, so if you would like to see
 a specific issue resolved now is a good time to contribute.

 If you feel strongly for any other issues please let us know.

 -Daniel

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

On 2012/06/08 17:20:06, rdayal wrote:

Yep, you're on the CLA list.



On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley

mailto:james.hors...@gmail.com

wrote:



 Just to check, was everything okay with the CLA I signed?

 On 7 June 2012 16:56, James Horsley mailto:james.hors...@gmail.com

wrote:


 Thanks Rajeev. Let me know if there's anything else you need with

it.



 On 7 June 2012 16:18, Rajeev Dayal mailto:rda...@google.com wrote:

 Thomas, thanks for jumping in.

 James, as Thomas said, we'll defer this to 2.5.1, but we'd

definitely like

 to get it in there, as it's an important patch. We just didn't want

to

 force this patch in 2.5.0, which is what we would have to do with

the

 current workload.

 Thanks so much for working on this.


 On Thu Jun 07 06:23:58 GMT-400 2012,

mailto:james.hors...@gmail.com wrote:


 Totally agree on this needing another round. Also, hearing about the
 plans for a 2.5.1 release which this could potentially be a

candidate

 for is great.

 Thanks again.

 On 2012/06/07 09:56:52, t.broyer wrote:
  On 2012/06/07 09:22:24, james.horsley wrote:
   Thanks for all your help with the patch Thomas. Sad to hear it

won't

 make it
   into GWT 2.5 as we were really looking to use RF with Maps

without

 having to
  use
   a patched version of GWT built from source internally.

  We're planning a 2.5.1 soon after 2.5.
  There are also several issues with Map support in AutoBeans

(reported

 only
  recently) which I'd like to get fixed at the same time (some of

them

 are related
  to how maps are encoded/decoded, so I'd like to have it the same

in

 both
  AutoBeans and RF; see
  http://code.google.com/p/google-web-toolkit/issues/detail?id=7395

for

 instance,
  which you seem to have avoided by using a slightly different
 serialization path
  for keys, where String keys are encoded as \foo\, vs. foo in
 AutoBean's
  serialization).
  Finally, to be honest, I think we need at least one more round

here: I

 need some
  more time to wrap my head around it.






http://codereview.appspot.com/6132056/%3Chttps://www.google.com/url?sa=Dq=http://codereview.appspot.com/6132056/







I'm possibly being a bit eager given 2.5 GA only just went out but
thought I'd just ping on this with regards to the 2.5.1 release that had
been mentioned.

http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: How to obfuscate RequestFactory type name, not only the operations ( GWT 2.4 )

[James Horsley]

I'll see if I can get some time to getting a patch together for this.

On 6 September 2012 17:32, Thomas Broyer t.bro...@gmail.com wrote:


 On Thursday, September 6, 2012 4:58:31 PM UTC+2, Chris Lercher wrote:

 On Thursday, September 6, 2012 3:58:34 PM UTC+2, Thomas Broyer wrote:

 Would you mind filing an issue in the tracker (if no one already did it)
 ?


 I did a few years ago: http://code.google.com/p/**
 google-web-toolkit/issues/**detail?id=5729http://code.google.com/p/google-web-toolkit/issues/detail?id=5729
 It was closed as a duplicate of http://code.google.com/p/**
 google-web-toolkit/issues/**detail?id=5394http://code.google.com/p/google-web-toolkit/issues/detail?id=5394,
 which is fixed and released in 2.4... but it doesn't really fix 5729.


 Well, it obfuscates all type and method names, *but* the RequestFactory
 name (as it's needed to load the DeobfuscatorBuilder class)

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/2yp-mCXMgfMJ.

 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: How to obfuscate RequestFactory type name, not only the operations ( GWT 2.4 )

[James Horsley]

I'm also very interested in this; I'd looked briefly going back but didn't
find anything either.

On 5 September 2012 11:01, zz zhi.z...@gmail.com wrote:

 Hi,

 I've searched all over the web, but didn't quite get my question answered.

 How to obfuscate the type name of my request factory interface that
 extends RequestFactory? I can only see operations on service are obfuscated.

 For gwt-rpc, it's enabled by adding below to module file.
 inherit 
 name='com.google.gwt.user.**RemoteServiceObfuscateTypeName**shttp://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/RemoteServiceObfuscateTypeNames.gwt.xml?r=9519'
 /

 Is there anything similar required to enable obfuscation for
 RequestFactory?

 Regards,
 zz

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/ggMXO4wGPiEJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: GWT future

[James Horsley]

Google I/O 2012 - The History and Future of Google Web Toolkit (
http://www.youtube.com/watch?v=VOf27ez_Hvg )

On 23 July 2012 08:14, AG arvind.gudip...@gmail.com wrote:

 I'm an Architect and we have been looking to port our legacy HTML w/ Java
 Script based web app  (with java backend) to a next generation web
 application. We are a java shop so GWT is very popular with our developers
 and I have been so called GWT fan-boy all along.

 However, lately I'm strongly considering moving away from GWT. Following
 are my observations that are scaring me to start looking for GWT
 alternatives:

 1. Larry Page has been killing no-so-happening (or revenue generating)
 projects from google. I was reading that 30+ projects have already been
 killed/shelved ever since Larry became CEO.
   -- I understand the need for this and I also understand that GWT
 currently enjoys a healthy developer community.

 2. DART - Looks like its the next big thing within google to develop web
 applications. As a google outsider, at least this is what it seems like.
 Google IO 2012 has no sessions for GWT while DART had several and there is
 even a session to convert GWT apps to DART.

 3. The latest update to Google Developer portal (
 http://developers.google.com) has no direct links to GWT. The web
 development section goes to chrome.

 I think the GWT team can address some of my concerns but it would be great
 if Google's management can stand behind GWT as a platform of choice for web
 development - similar to how Microsoft stands behind theirs development
 platforms.

 AG


  --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/PzISxYR26CIJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

[gwt-contrib] Re: Re: Add Map support to RequestFactory (issue 6132056)

[James Horsley]

Just to check, was everything okay with the CLA I signed?

On 7 June 2012 16:56, James Horsley james.hors...@gmail.com wrote:

 Thanks Rajeev. Let me know if there's anything else you need with it.


 On 7 June 2012 16:18, Rajeev Dayal rda...@google.com wrote:

 Thomas, thanks for jumping in.

 James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely
 like to get it in there, as it's an important patch. We just didn't want to
 force this patch in 2.5.0, which is what we would have to do with the
 current workload.

 Thanks so much for working on this.


 On Thu Jun 07 06:23:58 GMT-400 2012, james.hors...@gmail.com wrote:

 Totally agree on this needing another round. Also, hearing about the
 plans for a 2.5.1 release which this could potentially be a candidate
 for is great.

 Thanks again.

 On 2012/06/07 09:56:52, t.broyer wrote:
  On 2012/06/07 09:22:24, james.horsley wrote:
   Thanks for all your help with the patch Thomas. Sad to hear it won't
 make it
   into GWT 2.5 as we were really looking to use RF with Maps without
 having to
  use
   a patched version of GWT built from source internally.

  We're planning a 2.5.1 soon after 2.5.
  There are also several issues with Map support in AutoBeans (reported
 only
  recently) which I'd like to get fixed at the same time (some of them
 are related
  to how maps are encoded/decoded, so I'd like to have it the same in
 both
  AutoBeans and RF; see
  http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
 instance,
  which you seem to have avoided by using a slightly different
 serialization path
  for keys, where String keys are encoded as \foo\, vs. foo in
 AutoBean's
  serialization).
  Finally, to be honest, I think we need at least one more round here: I
 need some
  more time to wrap my head around it.



 http://codereview.appspot.com/6132056/https://www.google.com/url?sa=Dq=http://codereview.appspot.com/6132056/




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: Real time informations Draw in Gchart

[James Horsley]

I've been using  http://code.google.com/p/gflot/ and have been very happy
with it, in particular its latest 2.4 release. I think GFlot and GChart
(haven't looked at OFCGwt) have pretty extensive examples inc. source on
their sites?

On 7 June 2012 09:33, alaa aadil aadila...@gmail.com wrote:

 Hello,

 i want to display some real time informations an a Gchart or
 OFCGwt  ,  please i need an exemple for that


 thanks
 best regards

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

Rajeev, get a chance to look at this yet?

On 2012/06/05 10:50:18, james.horsley wrote:

Based on the email thread with Alexis and Thomas I've fixed the

handling of

nested entities along with adding the appropriate tests to verify the

behaviour.

To retrieve nested entities in a Map using .with() the syntax is
theMap.keys.nestedProp and theMap.values.nestedProp.




http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

Thanks for all your help with the patch Thomas. Sad to hear it won't
make it into GWT 2.5 as we were really looking to use RF with Maps
without having to use a patched version of GWT built from source
internally.

Certainly can switch to the patch being at the trunk/ level and post it
at the url you gave though.

Also, I signed the CLA via the online form a while back but never heard
anything back from it. Was I supposed to get a confirmation?

On 2012/06/07 09:04:23, t.broyer wrote:

On 2012/06/07 08:20:34, james.horsley wrote:
 Rajeev, get a chance to look at this yet?



We're cutting out GWT 2.5 soon; we decided to postpone this change to

the next

version.



BTW, sorry for being picky, could you please:
  - make your patch at the trunk/ level (rather than trunk/user/)
  - post it at http://gwt-code-reviews.appspot.com



Also, have you signed a CLA?
See

https://developers.google.com/web-toolkit/makinggwtbetter#contributingcode


 On 2012/06/05 10:50:18, james.horsley wrote:
  Based on the email thread with Alexis and Thomas I've fixed the

handling of

  nested entities along with adding the appropriate tests to verify

the

 behaviour.
  To retrieve nested entities in a Map using .with() the syntax is
  theMap.keys.nestedProp and theMap.values.nestedProp.




http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[James Horsley]

Thomas, I've created http://gwt-code-reviews.appspot.com/1735803/ as you
requested. Everything look okay with how I set the code review up?

On 7 June 2012 10:22, james.hors...@gmail.com wrote:

 Thanks for all your help with the patch Thomas. Sad to hear it won't
 make it into GWT 2.5 as we were really looking to use RF with Maps
 without having to use a patched version of GWT built from source
 internally.

 Certainly can switch to the patch being at the trunk/ level and post it
 at the url you gave though.

 Also, I signed the CLA via the online form a while back but never heard
 anything back from it. Was I supposed to get a confirmation?


 On 2012/06/07 09:04:23, t.broyer wrote:

 On 2012/06/07 08:20:34, james.horsley wrote:
  Rajeev, get a chance to look at this yet?


  We're cutting out GWT 2.5 soon; we decided to postpone this change to

 the next

 version.


  BTW, sorry for being picky, could you please:
  - make your patch at the trunk/ level (rather than trunk/user/)
  - post it at 
 http://gwt-code-reviews.**appspot.comhttp://gwt-code-reviews.appspot.com


  Also, have you signed a CLA?
 See

 https://developers.google.com/**web-toolkit/makinggwtbetter#**
 contributingcodehttps://developers.google.com/web-toolkit/makinggwtbetter#contributingcode

 
  On 2012/06/05 10:50:18, james.horsley wrote:
   Based on the email thread with Alexis and Thomas I've fixed the

 handling of

   nested entities along with adding the appropriate tests to verify

 the

  behaviour.
   To retrieve nested entities in a Map using .with() the syntax is
   theMap.keys.nestedProp and theMap.values.nestedProp.




 http://codereview.appspot.com/**6132056/http://codereview.appspot.com/6132056/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

Totally agree on this needing another round. Also, hearing about the
plans for a 2.5.1 release which this could potentially be a candidate
for is great.

Thanks again.

On 2012/06/07 09:56:52, t.broyer wrote:

On 2012/06/07 09:22:24, james.horsley wrote:
 Thanks for all your help with the patch Thomas. Sad to hear it won't

make it

 into GWT 2.5 as we were really looking to use RF with Maps without

having to

use
 a patched version of GWT built from source internally.



We're planning a 2.5.1 soon after 2.5.
There are also several issues with Map support in AutoBeans (reported

only

recently) which I'd like to get fixed at the same time (some of them

are related

to how maps are encoded/decoded, so I'd like to have it the same in

both

AutoBeans and RF; see
http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for

instance,

which you seem to have avoided by using a slightly different

serialization path

for keys, where String keys are encoded as \foo\, vs. foo in

AutoBean's

serialization).
Finally, to be honest, I think we need at least one more round here: I

need some

more time to wrap my head around it.




http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Add Map support to RequestFactory (issue 6132056)

[James Horsley]

Thanks Rajeev. Let me know if there's anything else you need with it.

On 7 June 2012 16:18, Rajeev Dayal rda...@google.com wrote:

 Thomas, thanks for jumping in.

 James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely like
 to get it in there, as it's an important patch. We just didn't want to
 force this patch in 2.5.0, which is what we would have to do with the
 current workload.

 Thanks so much for working on this.


 On Thu Jun 07 06:23:58 GMT-400 2012, james.hors...@gmail.com wrote:

 Totally agree on this needing another round. Also, hearing about the
 plans for a 2.5.1 release which this could potentially be a candidate
 for is great.

 Thanks again.

 On 2012/06/07 09:56:52, t.broyer wrote:
  On 2012/06/07 09:22:24, james.horsley wrote:
   Thanks for all your help with the patch Thomas. Sad to hear it won't
 make it
   into GWT 2.5 as we were really looking to use RF with Maps without
 having to
  use
   a patched version of GWT built from source internally.

  We're planning a 2.5.1 soon after 2.5.
  There are also several issues with Map support in AutoBeans (reported
 only
  recently) which I'd like to get fixed at the same time (some of them
 are related
  to how maps are encoded/decoded, so I'd like to have it the same in
 both
  AutoBeans and RF; see
  http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
 instance,
  which you seem to have avoided by using a slightly different
 serialization path
  for keys, where String keys are encoded as \foo\, vs. foo in
 AutoBean's
  serialization).
  Finally, to be honest, I think we need at least one more round here: I
 need some
  more time to wrap my head around it.



 http://codereview.appspot.com/6132056/https://www.google.com/url?sa=Dq=http://codereview.appspot.com/6132056/



-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

Based on the email thread with Alexis and Thomas I've fixed the handling
of nested entities along with adding the appropriate tests to verify the
behaviour. To retrieve nested entities in a Map using .with() the syntax
is theMap.keys.nestedProp and theMap.values.nestedProp.

http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[James Horsley]

I finally managed to get time to look at this. I added tests to answer to
Alexis's original question and my current patch out for review would not
work with his supplied case. Luckily, it was a fairly easy change to
addPathsToResolution to have it add the child resolutions without handling
the edge case Thomas pointed out.

I really Thomas's .keys. and .values. suggestion for disambiguation of
a common property name between the key and value types so, unless anyone
prefers theMap.e pulling in both the key's E's and values's E's,
I'll take a stab at that change.

Let me know if there're any other suggestions.

Cheers,
James

On 25 May 2012 22:06, Thomas Broyer t.bro...@gmail.com wrote:

 AutoBean has no equivalent to these partial loading; just like a POJO
 has no notion of lazy loading, compared to JPA entities.
 Le 25 mai 2012 21:06, James Horsley james.hors...@gmail.com a écrit :

 I read Alexis's email too hastily and hadn't noted he was asking about
 nested complex types. I'll add some tests to see how it behaves. I'll be
 interested to dig into what AutoBean's behaviour is here as that's what I
 based on, mimicked, and leveraged for this patch.

 On 25 May 2012 19:38, t.bro...@gmail.com wrote:

 On 2012/05/25 17:09:32, james.horsley wrote:

 I added tests for complex keys and complex values which're passing so

 it

 should do yes.


 I don't see any change to addPathsToResolution...
 Also, how would it work? Say I have a MapA,B, A has a reference c to
 a proxy C, and B has a reference d to a proxy D. What should I pass to
 Request#with() to get the Ds of B without the Cs of A? with(theMap.d)
 ? Now what if A and B both have a property e referencing a proxy E, I
 want B's Es but not A's Es, with(theMap.e) wouldn't work here.
 I think maybe there should be special subproperties keys and values,
 so one can say: with(myMap.keys.c, myMap.values.d, myMap.values.e)
 to get A's Cs, and B's Ds and Es (without A's Es!)



 http://codereview.appspot.com/**6132056/http://codereview.appspot.com/6132056/




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[James Horsley]

Adding the .keys. and .values. disambiguation was much much simpler
than I'd thought thanks to the prefix variable being passed down so can
have the codereview updated with this change very shortly.

On 4 June 2012 13:07, James Horsley james.hors...@gmail.com wrote:

 I finally managed to get time to look at this. I added tests to answer to
 Alexis's original question and my current patch out for review would not
 work with his supplied case. Luckily, it was a fairly easy change to
 addPathsToResolution to have it add the child resolutions without handling
 the edge case Thomas pointed out.

 I really Thomas's .keys. and .values. suggestion for disambiguation of
 a common property name between the key and value types so, unless anyone
 prefers theMap.e pulling in both the key's E's and values's E's,
 I'll take a stab at that change.

 Let me know if there're any other suggestions.

 Cheers,
 James

 On 25 May 2012 22:06, Thomas Broyer t.bro...@gmail.com wrote:

 AutoBean has no equivalent to these partial loading; just like a POJO
 has no notion of lazy loading, compared to JPA entities.
 Le 25 mai 2012 21:06, James Horsley james.hors...@gmail.com a écrit :

 I read Alexis's email too hastily and hadn't noted he was asking about
 nested complex types. I'll add some tests to see how it behaves. I'll be
 interested to dig into what AutoBean's behaviour is here as that's what I
 based on, mimicked, and leveraged for this patch.

 On 25 May 2012 19:38, t.bro...@gmail.com wrote:

 On 2012/05/25 17:09:32, james.horsley wrote:

 I added tests for complex keys and complex values which're passing so

 it

 should do yes.


 I don't see any change to addPathsToResolution...
 Also, how would it work? Say I have a MapA,B, A has a reference c to
 a proxy C, and B has a reference d to a proxy D. What should I pass to
 Request#with() to get the Ds of B without the Cs of A? with(theMap.d)
 ? Now what if A and B both have a property e referencing a proxy E, I
 want B's Es but not A's Es, with(theMap.e) wouldn't work here.
 I think maybe there should be special subproperties keys and values,
 so one can say: with(myMap.keys.c, myMap.values.d, myMap.values.e)
 to get A's Cs, and B's Ds and Es (without A's Es!)



 http://codereview.appspot.com/**6132056/http://codereview.appspot.com/6132056/





-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[James Horsley]

I added tests for complex keys and complex values which're passing so it
should do yes.

On 25 May 2012 17:01, alexisnou...@gmail.com wrote:

 Hello
 With your patch, does the function .with() works for a map for example
 in an entity:

 Map(String,ServiceParam) params;

 requestContext.find(id).with(**params.ServiceParam.Reader);

 ServiceParam and Reader are also Entity.
 Will it work?

 thanks,




 http://codereview.appspot.com/**6132056/http://codereview.appspot.com/6132056/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[James Horsley]

I read Alexis's email too hastily and hadn't noted he was asking about
nested complex types. I'll add some tests to see how it behaves. I'll be
interested to dig into what AutoBean's behaviour is here as that's what I
based on, mimicked, and leveraged for this patch.

On 25 May 2012 19:38, t.bro...@gmail.com wrote:

 On 2012/05/25 17:09:32, james.horsley wrote:

 I added tests for complex keys and complex values which're passing so

 it

 should do yes.


 I don't see any change to addPathsToResolution...
 Also, how would it work? Say I have a MapA,B, A has a reference c to
 a proxy C, and B has a reference d to a proxy D. What should I pass to
 Request#with() to get the Ds of B without the Cs of A? with(theMap.d)
 ? Now what if A and B both have a property e referencing a proxy E, I
 want B's Es but not A's Es, with(theMap.e) wouldn't work here.
 I think maybe there should be special subproperties keys and values,
 so one can say: with(myMap.keys.c, myMap.values.d, myMap.values.e)
 to get A's Cs, and B's Ds and Es (without A's Es!)



 http://codereview.appspot.com/**6132056/http://codereview.appspot.com/6132056/


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

Thanks for the update Rajeev. Look forward to hearing back on the patch.

Cheers,
James

On 2012/05/14 17:04:47, rdayal wrote:

Hey James,



Sorry, I have not had a chance to look this one over, but I am

planning to.

The turnaround on patches has been pretty bad for the past while, and

we're

actively going to make some changes soon that will result in big
improvements (I hope).



In the meantime, we're trying to review and land patches as fast as we

can.

No, you're not being pushy :).




Rajeev




On Thu May 10 16:15:15 GMT-400 2012, mailto:james.hors...@gmail.com

wrote:


 Rajeev, did you get a chance to look the patch over?

 I have no clue on what the turnaround is on submitted patches so
 hopefully am not being too pushy. I saw that GWT 2.5 is close to

being

 released and I'd love to have this functionality available in it.

 Thanks!

 On 2012/05/07 20:28:44, james.horsley wrote:
  The instructions at



https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches

 say
  to add this patch to the issue
 

(http://code.google.com/p/google-web-toolkit/issues/detail?id=5524)

 but I don't
  see how to do that. Is there a permission I'm missing?






http://codereview.appspot.com/6132056/%3Chttps://www.google.com/url?sa=Dq=http://codereview.appspot.com/6132056/






http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

Rajeev, did you get a chance to look the patch over?

I have no clue on what the turnaround is on submitted patches so
hopefully am not being too pushy. I saw that GWT 2.5 is close to being
released and I'd love to have this functionality available in it.

Thanks!

On 2012/05/07 20:28:44, james.horsley wrote:

The instructions at


https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches
say

to add this patch to the issue
(http://code.google.com/p/google-web-toolkit/issues/detail?id=5524)

but I don't

see how to do that. Is there a permission I'm missing?




http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

The instructions at
https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches
say to add this patch to the issue
(http://code.google.com/p/google-web-toolkit/issues/detail?id=5524) but
I don't see how to do that. Is there a permission I'm missing?

http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

The latest patch should incorporate all relevant feedback. Including
adding suggested tests and fixing where things when the tests failed.

On 2012/05/03 00:10:56, t.broyer wrote:

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java

File


src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java

(right):



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java#newcode523

src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java:523:

if (ctx instanceof MapPropertyContext 

((MapPropertyContext)ctx).getKeyType()

!= null) {
 This method is called by both

AutoBeanVisitor.visitCollectionProperty

 and AutoBeanVisitor.visitMapProperty since some of the ctx's

implemented

 both MapPropertyContext and CollectionPropertyContext. The null

checked

 seemed to safely (as best as I could tell) distinguish the cases.



I haven't looked whether there'd be an alternate approach, but it

might at least

be worth a comment in the code.

Added.



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java

File

src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java

(right):



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java#newcode135

src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:135:
if

(ValueCodex.canDecode(keyType)) {
 I originally did as you're suggesting but switched after digging

into

 what AutoBean is doing. From what I could tell from
 AutoBeanCodexImpl.MapCoder and


http://code.google.com/p/google-web-toolkit/wiki/AutoBean#JSON_structures

 AutoBean has been updated to allow non-value type keys; as such I

just

 followed what AutoBean's doing.



Oh, I'm more than OK to mimick AutoBean then!




http://codereview.appspot.com/6132056/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add Map support to RequestFactory (issue 6132056)

[james . horsley]

Will follow shortly with a patch taking into account the following
feedback but wanted to get yours and Rajeev's feedback on some points
before fixing others.

On 2012/05/02 13:59:05, t.broyer wrote:

Adding Rajeev as a reviewer.



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java

File

src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java

(right):



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java#newcode86

src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java:86:

DeclaredType asCollection =
Rename to asMap ?

Fixed.



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/server/Resolver.java

File src/com/google/web/bindery/requestfactory/server/Resolver.java

(right):


http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/server/Resolver.java#newcode505

src/com/google/web/bindery/requestfactory/server/Resolver.java:505:
accumulator.put(resolveDomainValue(entry.getKey(),

detectDeadEntities),

resolveDomainValue(entry.getValue(), detectDeadEntities));
Line too long.

Fixed



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/server/Resolver.java#newcode702

src/com/google/web/bindery/requestfactory/server/Resolver.java:702:


accumulator.put(resolveClientValue(entry.getKey(),entryTypes[0]).getClientObject(),

resolveClientValue(entry.getValue(),entryTypes[1]).getClientObject());
Line too long.

Fixed



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java

File


src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java

(right):



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java#newcode523

src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java:523:

if (ctx instanceof MapPropertyContext 

((MapPropertyContext)ctx).getKeyType()

!= null) {
Why is this null-check necessary? (or useful)

This method is called by both AutoBeanVisitor.visitCollectionProperty
and AutoBeanVisitor.visitMapProperty since some of the ctx's implemented
both MapPropertyContext and CollectionPropertyContext. The null checked
seemed to safely (as best as I could tell) distinguish the cases.



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java

File

src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java

(right):



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java#newcode25

src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:25:

import com.google.web.bindery.autobean.vm.impl.TypeUtils;
We're in 'shared', so we can't use 'vm' here (unless there's a

super-source

version of the class, which is not the case here).

Unused import that I've removed now.



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java#newcode29

src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:29:

import java.nio.charset.CoderMalfunctionError;
We're in 'shared' and java.nio is not emulated (and EntityCodex has no
super-source version)

Unused import that I've removed now.



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java#newcode135

src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:135:
if

(ValueCodex.canDecode(keyType)) {
So, if the key is a value type, serialization would use a JSON

object; and

otherwise it'd use two lists?



Can't we have a single serialization for maps? And how about a list of

key-value

pairs rather than a pair of lists (list of keys and list of values)?
Or wouldn't it be easier to simply restrict keys to value types? (like

AutoBean

does already)

I originally did as you're suggesting but switched after digging into
what AutoBean is doing. From what I could tell from
AutoBeanCodexImpl.MapCoder and
http://code.google.com/p/google-web-toolkit/wiki/AutoBean#JSON_structures
AutoBean has been updated to allow non-value type keys; as such I just
followed what AutoBean's doing.



http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java#newcode141

src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:141:

Object key = ValueCodex.decode(keyType,

StringQuoter.create(propertyKey));

StringQuoter.create() always creates a String Splittable (isString()

== true,

asString() != null), so ValueCodex won't be able to decode booleans,

numbers or

enums.



= add a unit test using either an Integer or enum as key.

[gwt-contrib] Add Map support to RequestFactory (issue 6132056)

[james . horsley]

Reviewers: t.broyer,

Message:
Thomas, I put you as the reviewer as I believe bobv, whose name was on
the issue, is no longer on the GWT team and I'd noticed you're very well
versed in requestfactory based on your community activity. Please let me
know if I should add/change reviewers.

Thanks!

Description:
Add Map support to RequestFactory (Issue 5524)

I tested it with a simple requestfactory web app in the same eclipse
workspace.

Please review this at http://codereview.appspot.com/6132056/

Affected files:
  M  
src/com/google/web/bindery/requestfactory/apt/ClientToDomainMapper.java
  M  
src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java

  M src/com/google/web/bindery/requestfactory/server/Resolver.java
  M  
src/com/google/web/bindery/requestfactory/server/ResolverServiceLayer.java
  M  
src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java
  M  
src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
  M  
src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java
  M  
test/com/google/web/bindery/requestfactory/gwt/client/FindServiceTest.java
  M  
test/com/google/web/bindery/requestfactory/gwt/client/RequestFactoryTest.java

  M test/com/google/web/bindery/requestfactory/server/SimpleFoo.java
  M test/com/google/web/bindery/requestfactory/shared/BaseFooProxy.java


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: gwt issues marked as patcheswelcome don't show up under open issues

[James Horsley]

Aren't tasks like CellTable column resizing something that the GWT community
are much more likely to have expertise in to implement locally and hopefuly
contribute back (it is open source after all) compared with compiler
optimizations and code splitting? I've been very happy with the speed
improvements to dev mode, compilation, etc. although of course am happy to
have those along with the widget fixes/improvements if the GWT team have
bandwidth :)

On 7 October 2011 12:56, David david.no...@gmail.com wrote:

 This issue is marked now as PatchesWelcome:

 http://code.google.com/p/google-web-toolkit/issues/detail?id=6401

 So if I understand you correct:
 Resizing columns in the CellTables will not be implemented unless we
 find a way to do it ourselfs ...
 A lot of people are waiting on this rather obvious feature (from the
 perspective of the user at least)

 I see some others related to the CellTable that would make it a decent
 component (like horizontal scrolling) also marked as PatchesWelcome.

 So after making us wait years for a fast replacement for the incubator
 tables, the cell table has become abandonware as well ?

 I'm really starting to regret chosing GWT for development. The only
 thing where there are many commits is the compiler optimisations and
 code splitting stuff ... in my opinion that is a waste of time since
 the browsers are getting faster every day anyway.

 David


 On Thu, Oct 6, 2011 at 9:02 PM, Eric Clayberg (Google)
 clayb...@google.com wrote:
  At least for the moment, that is intentional.
  As you probably know, the GWT issue tracker has not had a lot of love
  lately, and we would like to fix that. We are undertaking a multi-week
  project to triage as many of the open issues as we can. We would like to
  close stale, invalid, fixed  duplicate issues, assign owners as
  appropriate, or mark issues as PatchesWelcome if it is something that
 we
  think is a reasonable idea but not something we (the GWT development
 team)
  are going to commit to. By treating PatchesWelcome as a closed state,
 we
  are, in essence, making a positive indication that, while we are happy to
  look at a patch, we are not going to address this ourselves (similar to
  NotPlanned).
  We are willing to be convinced otherwise, if folks think it is a bad
 idea.
 
  --
  http://groups.google.com/group/Google-Web-Toolkit-Contributors

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

GWT SDK 2.4 jars

[James Horsley]

Is there a good breakdown of what each of the jars are for and at what point
in the dev lifecycle they're intended to be used? There seems to be a large
set of overlap between the various jars content wise. While I can make
educated guesses it'd be great to have an official statement of their
intents.

Cheers,
James

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: GWT SDK 2.4 jars

[James Horsley]

Thomas, you've cleared up all the questions I had so many thanks for your
super informative answer! Seems like this should be in a wiki somewhere on
the main GWT site or perhaps worth a posterous entry from yourself?

Cheers,
James

On 12 September 2011 13:38, Thomas Broyer t.bro...@gmail.com wrote:

 I unfortunately don't think you'll find any official statement (or maybe
 in documentation for older versions, but I cannot find any in the current
 documentation).


- gwt-dev contains the compiler and the DevMode; i.e. the dev tools.
It's only needed at compile-time, and shouldn't be needed by your code,
unless you're coding generators or linkers (that somehow plug into the
compiler and devmode, so their APIs are defined in gwt-dev)
- gwt-user contains the user library, i.e. what you'll use in your
code that will either be compiled to JS or run on the server. gwt-user has
an implicit dependency on gwt-dev, as it contains generators and linkers.
It also contains a few tools (webAppCreator, i18nCreator, etc.), most
of which a deprecated (webAppCreator, i18nCreator, etc.), and the JUnit
support (GWTTestCase et al.)
This is what you'll add as to your project as a dependency
(compile-time only though). gwt-user bundles a few dependencies
(javax.servlet, “Flute” the CSS parser from the W3C) so it's not to be
deployed.
- gwt-servlet is a subset of gwt-user (well, there are also a few
classes from gwt-dev) containing code to be run on the server
(RemoteServiceServlet, etc.)

 The line between gwt-dev and gwt-user is a bit blurry though, and a few
 utility classes from gwt-dev are used in gwt-servlet too. This is all
 historical. If GWT were to be repackaged today, classes would probably be
 split differently among JARs.

 Finally, unless you intend to contribute to GWT (or go into deep debug
 sessions of GWT itself), all you have to know is that your project should
 have gwt-user.jar as a dependency; possibly gwt-dev.jar too; and you'll only
 ever deploy gwt-servlet.jar. gwt-dev is used for the devmode or to compile
 your code (or as a dependency if you have a generator or linker in your
 code).

 Now, in GWT 2.4, there are a few new JARs:

- requestfactory-client: client-side code for RequestFactory (includes
RequestFactorySource), to be used in a VM (unit tests, stress-tests, or an
Android or desktop app)
- requestfactory-server: server-side code for RequestFactory (includes
RequestFactoryServlet). If you only use RF on the server (no GWT-RPC, no
SafeHtml, etc.) then you can deploy this JAR instead of gwt-servlet.jar.
- requestfactory-apt: annotation processor, used at compile-time only.
See

 http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation

 There's a large overlap between client and server, as shared code is in
 both JARs.

 Additionally, all three (client, server and apt) are bundled within
 gwt-user.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/frzl_Ljvo6wJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: HeaderLayoutPanel?

[James Horsley]

Setting the height of the SplitLayoutPanel to 100% works, but he
problem of it not resizing when the browser is resized by dragging the
bottom border of the window. Corner and left/right dragging trigger a
layout just fine.

On 31 August 2011 21:31, James Horsley james.hors...@gmail.com wrote:
 Thanks for the breakdown Thomas. At first I thought it was something
 particular to my application but I created a basic starter project and
 it doesn't show the SplitPanelLayout with the super basic example
 below. Oddly enough if you change the CSS position of the
 SplitLayoutPanel element to static then it shows just fine with the
 caveat that, although corner dragged resizes are handled okay, bottom
 edge draggged resizes don't update the HeaderPanel's layout.

 g:HeaderPanel

    !-- Header --
    g:HTMLPanel h1header/h1 /g:HTMLPanel

    !-- Center --
    g:SplitLayoutPanel
        g:west size=200
            g:HTMLPanel h2Navbar/h2 /g:HTMLPanel
        /g:west

        g:center
            g:HTMLPanel h1Stuff/h1 /g:HTMLPanel
        /g:center
    /g:SplitLayoutPanel

    !-- Footer --
    g:HTMLPanel h1footer/h1 /g:HTMLPanel

 /g:HeaderPanel

 On 31 August 2011 15:57, Thomas Broyer t.bro...@gmail.com wrote:

 On Wednesday, August 31, 2011 9:18:22 AM UTC+2, James Horsley wrote:

 Would love to have the naturally resizing header and footer but to
 then add a SplitLayoutPanel as the center. Doing so causes nothing to
 show which I'm guess is due to HeaderPanel not being a LayoutPanel?

 HeaderPanel is a RequiresResize, and if you look at its source, you'll see
 that it'll call onResize on its content widget if it's a RequiresResize too.
 I guess the reason HeaderPanel doesn't implement ProvidesResize is because
 it doesn't implement the behavior for the header and footer.
 This does however make it a layout panel.
 In other words: it should work. (and I have no idea why it doesn't)

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/Kpd-yKfZSuIJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

HeaderLayoutPanel?

[James Horsley]

Would love to have the naturally resizing header and footer but to
then add a SplitLayoutPanel as the center. Doing so causes nothing to
show which I'm guess is due to HeaderPanel not being a LayoutPanel?

Any plans for a HeaderLayoutPanel?

Cheers,
James

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: HeaderLayoutPanel?

[James Horsley]

Thanks for the breakdown Thomas. At first I thought it was something
particular to my application but I created a basic starter project and
it doesn't show the SplitPanelLayout with the super basic example
below. Oddly enough if you change the CSS position of the
SplitLayoutPanel element to static then it shows just fine with the
caveat that, although corner dragged resizes are handled okay, bottom
edge draggged resizes don't update the HeaderPanel's layout.

g:HeaderPanel

!-- Header --
g:HTMLPanel h1header/h1 /g:HTMLPanel

!-- Center --
g:SplitLayoutPanel
g:west size=200
g:HTMLPanel h2Navbar/h2 /g:HTMLPanel
/g:west

g:center
g:HTMLPanel h1Stuff/h1 /g:HTMLPanel
/g:center
/g:SplitLayoutPanel

!-- Footer --
g:HTMLPanel h1footer/h1 /g:HTMLPanel

/g:HeaderPanel

On 31 August 2011 15:57, Thomas Broyer t.bro...@gmail.com wrote:

 On Wednesday, August 31, 2011 9:18:22 AM UTC+2, James Horsley wrote:

 Would love to have the naturally resizing header and footer but to
 then add a SplitLayoutPanel as the center. Doing so causes nothing to
 show which I'm guess is due to HeaderPanel not being a LayoutPanel?

 HeaderPanel is a RequiresResize, and if you look at its source, you'll see
 that it'll call onResize on its content widget if it's a RequiresResize too.
 I guess the reason HeaderPanel doesn't implement ProvidesResize is because
 it doesn't implement the behavior for the header and footer.
 This does however make it a layout panel.
 In other words: it should work. (and I have no idea why it doesn't)

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/Kpd-yKfZSuIJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.