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

[David Nouls]

I managed to find a jdk 8 for my system and the build works. Thanks for the 
quick response.
On 22 Mar 2023 at 13:23 +0100, Colin Alworth , wrote:
> That patch is delayed since it turns out there are some tests that rely on 
> specific behavior from the JVM - a few JPMS violations in legacy dev mode, 
> and apparently Annotation.toString() changed slightly breaking a few other 
> tests. I think it is just about ready, but each round of testing takes a few 
> hours, so it is hard to get it done in one sitting.
>
> But it will produce working output, including docs, if you want to use it to 
> build a GWT SDK locally.
>
> > On Wednesday, March 22, 2023 at 4:25:48 AM UTC-5 Jens wrote:
> > > Doctool hasn't been updated yet, see: 
> > > https://github.com/gwtproject/gwt/pull/9780
> > >
> > > You can install Java 8 for Mac x86 using 
> > > https://adoptium.net/de/temurin/releases/?version=8
> > >
> > > If you use a Mac with Apple Silicon and don't want to install Rosetta 2 
> > > you would need to install Java 8 from a different vendor, e.g. Azul Zulu 
> > > or Amazon Corretto 8 (also available via brew.sh). Or you make/use a 
> > > Docker image with Java 8 + ANT (+ Maven if you want to push the build to 
> > > a corporate repository), mount the GWT SDK + Tools repositories and 
> > > compile inside the container.
> > >
> > > -- J.
> > >
> > > > stuckagain schrieb am Mittwoch, 22. März 2023 um 09:21:42 UTC+1:
> > > > > Is it possible to compile GWT on a Mac ? Is it mandatory to use Java 
> > > > > 8, that version is no longer available.
> > > > >
> > > > > I have Java 11 installed, but I get the following error:
> > > > >
> > > > >
> > > > > compile:
> > > > >     [mkdir] Created dir: 
> > > > > /Users/me/Projects/gwt/build/out/build_tools/doctool/bin
> > > > >     [javac] Compiling 10 source files to 
> > > > > /Users/me/Projects/gwt/build/out/build_tools/doctool/bin
> > > > >     [javac] -Xbootclasspath/p is no longer a supported option.
> > > > >     [javac] Error: Could not create the Java Virtual Machine.
> > > > >     [javac] Error: A fatal exception has occurred. Program will exit.
> > > > >
> > > > >
> --
> You received this message because you are subscribed to the Google Groups 
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/a72e40cb-8dd4-4e20-be09-5739020c8c55n%40googlegroups.com.

-- 
You received this message because you are subscribed to 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/2592d5d2-2c3b-4e6b-b42c-f9c72846ed06%40Spark.

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

[David Nouls]

In my case we have different codebases that overlap with reusable components. 
Not all projects are willing to invest in a newer jdk since they are basically 
in maintenance mode.

If GWT would drop Java 8 it would be a problem. On the other hand, maybe it 
will finally force people to move on faster. They tend to complain that we are 
using old technology (GWT) but at the same time they stick with Java 8.
On 4 Aug 2022, 06:05 +0300, Colin Alworth , wrote:
>
>
> If there’s one thing that GWT has tried to be consistent about, it is 
> retaining support for technologies past their “best by” dates. This is a sore 
> point from time to time, as it makes the tooling feel dated even right after 
> a release, but it has some specific advantages with regards to enabling 
> projects that are otherwise in maintenance mode to still be able to upgrade 
> to a newer version. Similarly, GWT has traditionally only supported the 
> current release, with no fixes backported, due to the extra work that would 
> need to be done in testing, backporting, etc.
>
>
> To get stuck on a tangent before even reaching the point of this post, this 
> is part of the reason that each of the GWT modules which previously lived in 
> gwt-user.jar is getting its own git repo, and being released as its own pace, 
> separate from the GWT compiler and its neighbors (and also separate from 
> J2CL, with tests to ensure it can work with both toolkits). Migrating to a 
> specific version of one of those modules might require some code changes be 
> made to a project, but is intended to uncouple changes to that project from 
> changes made to either J2CL or GWT2 toolchains.
>
> GWT 2.10 has been released, with a few important changes that border on 
> breaking - the groupId has changed from com.google.gwt to org.gwtproject, 
> Jetty was updated after languishing for years, and IE 8, 9, and 10 support 
> has been dropped. The Jetty change has caused a few minute hiccups, one of 
> which will probably result in a GWT 2.10.1 release, but otherwise things seem 
> to have gone well.
>
> Looking forward, we have some other decisions to make around deprecating or 
> dropping support for certain features or compatibility. The chief issue is 
> dropping support for Java 8. Jetty 9 is EOL (though still receiving 
> occasional security updates for now), and Jetty 10 requires Java 11 at a 
> minimum. Recent versions of the Eclipse JDT will also require Java 11, so we 
> can’t add support for Java 17 language features without dropping support for 
> running on Java 8. While it is possible that we might be able to continue to 
> compile gwt-servlet and other production server-side code for Java 8, that is 
> going to need dedicated testing to ensure it behaves as we expect, so I 
> wouldn’t want to have it be one of our first choices.
>
> We would be in good company with dropping Java 8 in our next release - the 
> Spring Framework has gone so far as to drop Java 11 support as well, 
> requiring Java 17 as the minimum supported Java version as of version 6.
>
> Other deprecations/updates/removals to consider - I haven’t spent a great 
> deal of time investigating any of these, but wanted to at least open the door 
> to some of these.
>
>
> • Legacy Dev Mode - the use cases are diminishing but not totally gone yet. 
> IE11 technically supports it, and HtmlUnit can use it as well. Some testing 
> tools like gwt-mockito and Emma require it as well. With that said, if 
> removed, there is considerable old code that can go with it, not just in the 
> compiler and dev mode, but simplification that can happen in emulation as 
> well.
> • Selenium - Selenium support is ancient, and I’m not aware of a way to make 
> it work with recent browsers. Moving to modern WebDriver would make sense, 
> though this is a bit of a moving target in my experience, but downstream 
> projects should be able to update without affecting GWT. It might even make 
> sense to leave this as an optional dependency, and rely on the downstream 
> project adding its own implementation.
> • javax.servlet -> jakarta.servlet - This could potentially be done in a way 
> to support both APIs in a single release, though that may also require 
> supporting two sets of dev mode implementations, for users that run their own 
> servlets in the dev mode server.
>
>
> Inevitably, removing these before they are formally end-of-life’d is bound to 
> inconvenience at least a few downstream developers, so this isn’t to be taken 
> lightly, nor done without some plan to continue to support critical fixes. 
> Some quick options, based on how much pushback we get on each:
>
> • Keep all compatibility until the dependency in question is formally 
> end-of-life’d. We’ll be waiting until something like 2026 to pick up the Java 
> 17 support through JDT, though other options might be possible along the way.
> • Be very aggressive in dropping support, such as Spring’s model, where the 
> next release will only support 

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

[David Nouls]

+1 for dropping support for ie8-10.

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

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

[David Nouls]

We still need IE11 support in the banking sector. We still have a majority of 
customers that use IE11 due to technical reasons (plugins needed for accessing 
secure token don’t install properly in Chrome without internet access amongst 
others).

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

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5e524a19-81a2-44f6-8246-b25562b40861%40Spark.

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

[David Nouls]

Working in the bankings sector. We support all IE versions that are still 
available with a (payable) supported version of Windows.

So for us it is IE11 and Edge.


On 14 Jun 2020, 07:38 +0200, Alberto Mancini , wrote:
> Hi,
> I think that keeping just IE11 is ok.
>
> Thanks,
>    Alberto
>
> > On Sun, Jun 14, 2020 at 5:30 AM Freddy Boucher  
> > wrote:
> > > Hi,
> > > On our side, an enterprise GWT webapp, 14% of our Users still use IE11 
> > > (we already dropped prior IE versions).
> > > And unfortunately we still have to support IE11 for some time.
> > > Regards
> > > --
> > > You received this message because you are subscribed to 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/8bb390c7-855e-455e-bb34-16b6d18f6452o%40googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups 
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGv30Vmb7%2BHwMr%2BkZfS72ZPSSi%2BQ8DXLy%3DtR-ib-zda_-Bi%3DPQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/66e1c5ce-2656-4531-9a44-71fc5fb41446%40Spark.

Re: [gwt-contrib] Re: 2.9 progress

[David Nouls]

Is it acceptable that an official GWT implementation of the time API would be 
based on moment.js ? Or is it expected that it is all implemented with standard 
browser API and pure Java code ?
On 5 Dec 2018, 15:03 +0100, Jens , wrote:
>
> > For the emulation changes I can live with what is available now and get 
> > some more in a later release. But how does the gwt team decide which are 
> > crucial and which ones can be done in a separate library ? The java.time 
> > API should really be considered, the Date object has been deprecated for 
> > ages. Right now I use moment.js with a JsInterop mapping to handle dates 
> > and times.
>
> It is generally preferred to have JRE emulation within GWT itself instead of 
> having separate libraries. Basically a single source of trust, which is well 
> reviewed, tested and optimized. Also J2CL uses the same emulation and it 
> might be beneficial to have J2CL experts take a look at the emulation code as 
> well.
>
> There was someone who did java.time emulation but he never contributed it. It 
> was based on the threeten repository on Github. Personally I think java.time 
> should really be tackled by GWT because working with Date in Client code is a 
> pain. Using momentjs works, however it is still a pain for code you want to 
> share between client and server. (There is also a java.time emulation on 
> Github somewhere which uses momentjs under the hood I believe)
>
> -- 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/5fcf5659-b317-42bf-9ed9-61b3ca42b061%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/e816e7db-c698-422a-820f-fcbcb48bb2f2%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: 2.9 progress

[David Nouls]

I am using var in some simple cases and the gwt compiler did not have a 
problem. I don’t use them on lambda parameters though. So my code is using  
Java 10 but not 11 features.

For the emulation changes I can live with what is available now and get some 
more in a later release. But how does the gwt team decide which are crucial and 
which ones can be done in a separate library ? The java.time API should really 
be considered, the Date object has been deprecated for ages. Right now I use 
moment.js with a JsInterop mapping to handle dates and times.

And yes please updates on a regular release cycle is the approach that many big 
projects use. As long as it has been tested wel, and GWT is as far as I have 
seen over all these years.
On 5 Dec 2018, 11:18 +0100, Jens , wrote:
> I think the JDT version GWT currently uses does not officially support Java 
> 11. However Java 11 has no notable syntax changes except the var keyword for 
> lambda parameters. So it might work, but maybe it doesn't. Have you tried 
> running GWT with Java 11 and using that new syntax?
>
> Also no Java API emulation additions have been added since Java 8 (and even 
> some Java 8 stuff is still missing). I am working on a detailed list of 
> differences between GWT HEAD and Java 11 source whenever I find time for it. 
> This is not really a blocker, but if we state GWT supports Java 11 we might 
> want to have the most useful API additions available.
>
> Automated releases that are tested like the SNAPSHOT builds, but with a fixed 
> version number would be the solution to GWTs slow (fully tested) release 
> cycle.
>
> -- 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/4414c464-fd70-4229-9876-f700c28d4df6%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/872d99aa-a233-4266-ad70-f006bb2a95da%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Java10 support

[David Nouls]

Thanks Thomas, that fixed the problems!
On 13 Jul 2018, 16:13 +0200, Thomas Broyer , wrote:
>
>
> On Thursday, July 12, 2018 at 4:18:38 PM UTC+2, stuckagain wrote:
> > Thomas,
> >
> > would you mind pushing a new snapshot release of your maven plugin release 
> > to sonatype ?
> > I see that you have migrated to a newer version of the surefire plugin on 
> > github, but this version is not yet available on sonatype. (latest update 
> > is 20170920)
> > I can’t build the verson myself, due to security restrictions, but we want 
> > to prepare for java 10. The NPE that you mention is stopping us from 
> > completing this migration.
>
> Should be OK within minutes: 
> https://travis-ci.org/tbroyer/gwt-maven-plugin/jobs/403569831
>
> > I thought it would be better to ask now, before Belgium beats France on 
> > saturday :-P
>
> I'm absolutely not a football/soccer fan (quite the contrary actually; except 
> during Euro or World cup when France has a good team), but that match (last 
> tuesday ;-) ) was a good watch; Belgian team was probably as deserving as 
> Frenchies. See ya at Euro 2020? ;-)
> (crossing fingers for Sunday, with Croatia still resentful after 20 years… 
> but in the mean time, Bastille Day!)
> --
> You received this message because you are subscribed to 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/0fb20425-96ef-479c-a1b9-17a6fdf5c94f%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/8e76180f-9ea7-419c-9180-33c36102002c%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Java10 support

[David Nouls]

Just a little bit, but mostly because we can’t seem to get the Java 10 working 
properly.

We are having problems running the GWTTestCase using the maven plugin from 
Thomas.

The snapshot release in sonatype of the maven plugin looks to be quite old so 
it is still depending on older versions of the surefire maven plugin.
But we tried overriding it (upgrading both the surefire and common-lang3 
dependencies to Java 10 compatible versions) without success.

But at the same time we also notice that the HEAD-SNAPSHOT release of GWT that 
we are pulling in seems to not be very recent… (old non-java-10 asm version for 
example). But I need to figure out if this is a local problem due to our 
mirrors of the maven repos or if the HEAD-SNAPSHOT is maybe not updated for 
some time.

On 12 Jul 2018, 22:03 +0200, Jens , wrote:
>
> > I guess I am bit overworked :) ignore the last statement!
>
> :D :D and now you are sad? :)
> --
> You received this message because you are subscribed to 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/526591e7-bb40-4e09-a280-31206f705d86%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/9e25d356-6ad5-4ffd-9142-13d4e05e54a6%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Java10 support

[David Nouls]

I guess I am bit overworked :) ignore the last statement!
On 12 Jul 2018, 16:18 +0200, stuckagain , wrote:
> Thomas,
>
> would you mind pushing a new snapshot release of your maven plugin release to 
> sonatype ?
> I see that you have migrated to a newer version of the surefire plugin on 
> github, but this version is not yet available on sonatype. (latest update is 
> 20170920)
> I can’t build the verson myself, due to security restrictions, but we want to 
> prepare for java 10. The NPE that you mention is stopping us from completing 
> this migration.
>
> I thought it would be better to ask now, before Belgium beats France on 
> saturday :-P
>
> --
> You received this message because you are subscribed to 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/8b159ed2-9ca5-4b30-8d57-6940badd77ef%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/b5164aec-c74f-40e1-acca-273e637beb00%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Update on J2CL

[David Nouls]

Thanks for the update,

I fail to understand why the prerequisite of using bazel was enforced and why 
it seems to have such a big impact on opensourcing J2CL.
As far as I understand Google is probably the only company that uses bazel, and 
internally that is not even the same product as the opensource one.

Does J2CL depend on Bazel somehow ? That sounds like a liability to me.
Newer versions of Gradle have a lot of optimisations and caching implemented, 
so was it really worth the effort to use Bazel ?
On 12 Jun 2018, 08:54 +0200, 'Goktug Gokdogan' via GWT Contributors 
, wrote:
> We recently sent an update on J2CL and we would like to cross post it to GWT 
> contributor list since there was recent questions about it. I would like to 
> also remind everybody that GWT3 != J2CL; GWT3 work is still ongoing in the 
> open source community and I will talk to steering committee to see if an 
> update on it could be provided as well.
> 
>
> Since we gave access to more people, we thought that this would be a good 
> time to give you an update on J2CL; what is happening, if it is really a 
> thing or not and what to expect from it.
>
> First the good parts:
>
> 1- J2CL is feature complete for a while and had a very strong traction in 
> Google in the last year.
> We got pretty big customers on board and some launched to production and they 
> are pretty happy about it.  To name a few projects that are already running 
> J2CL code: New GMail, Inbox, Docs, Slides. And more are coming.
> We could not have achieved this with GWT since our customers apps have very 
> strict expectations on code size/performance and interoperation with their 
> existing JavaScript stack. And this is why we built J2CL in the first place.
>
> 2- J2CL has improved on code size compared to already quite performant GWT 
> compiler.
> The last time I checked it was around 5-10% code size reduction and we will 
> continue working on that.
>
> 3- Optimized compiles improved by 50% and it is possible to get a couple of 
> second refresh times for development.
>
>
> And now the “could be better” parts :)
>
> 1- Open-source build is not fully working
> J2CL is highly optimized for Google infrastructure and scales very well with 
> Bazel. There are multiple reasons for that:
> - Bazel works very well as a cross-platform build solution. You can build 
> your Android, iOS and Web application together with Bazel.
> - Bazel has a very good caching/scaling architecture and we already designed 
> J2CL based on that.
> - Bazel is our only expertise on build systems so we can only ensure 
> developers gets a good development experience using Bazel.
> For pure J2CL experience in open source, we decided early on to rely on Bazel 
> and made it a prerequisite for open-sourcing it.
> However, our internal build macros used things that are only available 
> internally so we need to clean and port to a more proper solution that could 
> also work well for open-source. And during that process we keep hitting 
> limitations that block us and cause delays. Also please keep in mind that 
> J2CL’s success is highly related to its internal success and we were busy 
> helping internal customers to have successful production launches so we 
> didn't have much bandwidth either.
>
> On the bright side, most of the blocking issues are getting resolved and we 
> had progress in the last couple of months and we are prioritizing this even 
> further.
>
> (Note that this doesn’t mean you will be *required* to use Bazel for J2CL and 
> our contributors are already working on Maven/Gradle solutions.)
>
> 2- For now your mileage may vary w.r.t performance
> Even though optimized compiles are much better for Google, I am not sure how 
> this will translate to open- source  since the two compilers scale 
> differently and historically open source users got better performance out of 
> GWT than we did internally. However I'm optimistic on this in the long run.
>
> For development edit/refresh cycles, it is hard to beat GWT’s SDM since it is 
> already designed to do the very minimal things required to serve development 
> code. Being said that it is still possible to have good refresh times using 
> something called 'iblaze' which is essentially a file watcher that triggers a 
> warm transpiler and code bundler where we could do caching.
> One worry I have here is, we use some tools that does code pruning during 
> build which helps some with the performance, and those tools are not 
> available for open source. Something we will eventually look at but not very 
> soon.
>
>
> Anyway, this is the quick summary of how things are and I hope it sheds some 
> light to the questions.
> --
> You received this message because you are subscribed to the Google Groups 
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 

Re: [gwt-contrib] GWT 2.8.2 release

[David]

Thanks guys!

One question:

   - Migrate guava JRE emulation to GWT

Does this mean I have to migrate to a newer version of guava ?

On Thu, Oct 19, 2017 at 10:31 PM Colin Alworth  wrote:

> Today we released the next version of GWT, version 2.8.2. A few quick
> highlights from this new release:
>
>- GWT can now run on Java 9 (though Java 9 features are not yet
>supported, coming soon!)
>- Chrome 61 change in getAbsoluteTop/Left has been fixed
>- Errors on the page reported from window.onerror are now reported to
>your uncaught exception handler
>- GWT now generates CSP compliant dom elements
>
> The release notes can be found at
> http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_2. Get
> yours from Maven Central, or from the zip release .
> Special thanks to Max Barkley of RedHat who helped lead the release effort
> this time, and to all of the fantastic testers who helped us ensure that
> this release was ready to go.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/c22fab4d-87ee-4c75-a49a-460cdc6ac3a7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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/CABrJHW3jvQnQDFSLJ4vSdGJ5Ck%2B8mubj%2B1hrEqv63xhmp%2BT3Yg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

[David]

I guess he is going through the same steps like most devs who relied on
GWT. I recognise the same reactions I initially had. We also have huge
applications build on GWT and we don't like rewriting hings that work.  But
sometimes it is a good moment to reflect on the choices that were made.
With Java 8 support in place I have the tendency to do things different
anyway.

After working iwth JsInterrop and Elemental2 (and the ability to quickly
interface with other js based widgets) I noticed that my code is much
smaller and maintainable.

Right now I still depend on UiBinder and CellWidgets, but I plan to move
too Elemento2 and possibly vaadin grid instead or bootstrap datatable.

Superdevmode is also fine in most cases. Sure sometimes it is a fight to
put a breakpoint in the right location, but with pretty mode the mapping
between js and java is very readable.

Now I just need a replacement for GWTP with annotation processors. If
needed I would even like to help out in getting it done.

On Mon, 22 May 2017 at 14:32, Paul Stockley  wrote:

> You are putting words in my mouth. Try reading my comment again. All I
> said was the approach we took was a lot faster and resulted in smaller code
> size, both of which are true. I said it came with some compromise, which
> for our use case and I suspect many others isn't a big deal. However, it
> also comes with other benefits. For example, we can easily communicate with
> non-java backends and services using the same JSON based approach.
>
> It sounds like your use case isn't applicable to this approach. Google
> have made it pretty clear they don't want to use or support GWT RPC
> anymore. To be honest they are totally in their right to do this. This is
> one of the most one sided open source projects I have seen. Virtually all
> the work has been done by google over the years. Over the last few years
> all I have seen is people complain that their use cases (RPC, UiBinder,
> etc) are being abandoned. Now is the time to step up as a community and
> actually start contributing back. Our company relies on base widgets,
> UiBinder and Resources. If google doesn't offer these going forward, we
> will help to come up with alternatives that will work with J2CL.
>
> I would suggest you gather up support from everyone who still wants RPC
> and start planning to build an alternative. It sounds like you have lots of
> ideas how to make a better version. Talk is cheap, why not make something
> happen.
>
>
> On Sunday, May 21, 2017 at 9:03:55 AM UTC-4, Learner Evermore wrote:
>>
>>
>>
>> On Sunday, May 21, 2017 at 7:04:19 AM UTC-4, Paul Stockley wrote:
>>>
>>> I am really interested to hear how you can make a version of GWT RPC as
>>> fast as a pure JSON approach. We take a tree of thousands of objects and
>>> just use one JSON.parse / JSON.stringify call to deserialize / serialize
>>> which happens within the browser in C++ code. No other processing is
>>> required. We use Overlay types to access the data and that is it. In the
>>> future we will switch to JsInteop types instead of overlays, that way we
>>> only have one version of our DTO's that are used on the client / server.
>>>
>>
>> As I suspected, you are comparing apples to oranges...
>>
>>
>>1. You made dumb DTOs for this which means that you have to have the
>>code that copies data into them specifically for this purpose. And while
>>DTOs have followers for some cases they are *downright antipatterns* in
>>other cases. But we don't need to discuss that.
>>2. You either don't have/use polymorphism or have had to code around
>>that as well.
>>3. Any logic you have has to be either outside of the overlay types
>>or not polymorphic and you need to deal with that too.
>>4. You also probably excluded the cost of delayed type conversion.
>>5. How are you communicating long/Long? There are other examples.
>>6. You can't include data of a third party library unless you have
>>the means to make full copies of it and keep in sync with that.
>>7. Enjoy communicating cyclic graphs?
>>
>>
>> Then we come to the point of how much work you spend addressing the
>> above, esp. for complex types. We don't have to spend any of that. None.
>> Zilch. Nada. We have spent that time ensuring that we *never* have to
>> send so many objects even if we have to show millions (literally) and made
>> our product better overall.
>>
>> --
> You received this message because you are subscribed to 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/81724bf2-552d-4461-9f92-b6fc388f4840%40googlegroups.com
> 

Re: [gwt-contrib] Re: GWT 2.8.1 release

[David]

I migrated my code immediatly (including the beta release of Elemental2)

Seems to work fine so far.

On Wed, 26 Apr 2017 at 14:18, Matic Petek  wrote:

> Thank you very much for this.
>
>
> On Tuesday, April 25, 2017 at 9:30:20 PM UTC+2, Colin Alworth wrote:
>>
>> I'm very pleased to announce the release of GWT 2.8.1. This contains many
>> bugfixes and a few enhancements to JsInterop.
>>
>>
>> Highlights from release notes:
>>
>>-
>>
>>Elemental1's JSON parser now correctly throws an exception when a
>>string, object, or array is not correctly ended.
>>-
>>
>>Support filtering JsInterop types for export, with
>>whitelist/blacklist and wildcards. The -generateJsInteropExport flag
>>is still used to enable the feature, but -includeJsInteropExport and
>>-excludeJsInteropExport now exist to specify packages with optional *
>>wildcards. Later arguments and patterns override earlier ones.
>>-
>>
>>Support "*" (any) and "?" (unknown) types as a JsType native name.
>>The "Unknown" type can be preferred over Object if the type is unknown,
>>while "any" is preferred supertype of any JS type, including primitives.
>>
>>
>> Additionally, this supports the recent beta release of jsinterop.base and
>> elemental2, available from Maven Central.
>>
>>
>> Please check out the full release notes
>> , then
>> download the release zip  or update your project
>> to get version 2.8.1 from Maven Central.
>>
> --
> You received this message because you are subscribed to 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/472fb8cf-54da-495a-95ee-fdfeb06a88cc%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/CABrJHW32o0Lnuw%3DaxHswWpwaF4KFBQBPHnhhpxCY%3Dxgse5RUjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Yu]

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
> <https://docs.google.com/document/d/14mQeAGQ9M_5uTTUbzRQzCYETA887dTO-xFLtQhgUXXk/edit?usp=sharing>
> .
>
>
> We also split Elemental into smaller jar files:
>
>
> Jar file
>
> artifact-id
>
> GWT module
>
> elemental2-core.jar
> <https://oss.sonatype.org/content/repositories/releases/com/google/elemental2/elemental2-core/1.0.0-beta-1/elemental2-core-1.0.0-beta-1.jar>
>
> elemental2-core
>
> elemental2.core.Core
>
> elemental2-promise.jar
> <https://oss.sonatype.org/content/repositories/releases/com/google/elemental2/elemental2-promise/1.0.0-beta-1/elemental2-promise-1.0.0-beta-1.jar>
>
> elemental2-promise
>
> elemental2.promise.Promise
>
> elemental2-dom.jar
> <https://oss.sonatype.org/content/repositories/releases/com/google/elemental2/elemental2-dom/1.0.0-beta-1/elemental2-dom-1.0.0-beta-1.jar>
>
> elemental2-dom
>
> elemental2.dom.Dom
>
> elemental2-svg.jar
> <https://oss.sonatype.org/content/repositories/releases/com/google/elemental2/elemental2-svg/1.0.0-beta-1/elemental2-svg-1.0.0-beta-1.jar>
>
> elemental2-svg
>
> elemental2.svg.Svg
>
> elemental2-webgl.jar
> <https://oss.sonatype.org/content/repositories/releases/com/google/elemental2/elemental2-webgl/1.0.0-beta-1/elemental2-webgl-1.0.0-beta-1.jar>
>
> elemental2-webgl
>
> elemental2.webgl.WebGl
>
> elemental2-media.jar
> <https://oss.sonatype.org/content/repositories/releases/com/google/elemental2/elemental2-media/1.0.0-beta-1/elemental2-media-1.0.0-beta-1.jar>
>
> elemental2-media
>
> elemental2.media.Media
>
> elemental2-indexeddb.jar
> <https://oss.sonatype.org/content/repositories/releases/com/google/elemental2/elemental2-indexeddb/1.0.0-beta-1/elemental2-indexeddb-1.0.0-beta-1.jar>
>
> elemental2-indexeddb
>
> elemental2.indexeddb.IndexedDb
>
> elemental2-webstorage.jar
> <https://oss.sonatype.org/content/repositories/releases/com/google/elemental2/elemental2-webstorage/1.0.0-beta-1/elemental2-webstorage-1.0.0-beta-1.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
> <https://oss.sonatype.org/content/repositories/google-snapshots/com/google/gwt/gwt/HEAD-SNAPSHOT/>
> .
>
>
> 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
> <https://oss.sonatype.org/content/repositories/releases/com/google/jsinterop/base/1.0.0-beta-1/base-1.0.0-beta-1.jar>
> 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/CABXeq2QsTarhDKbYmz0y1SOrjpuFN
> doNmAnvAYKacO1f4rLcLg%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABXeq2QsTarhDKbYmz0y1SOrjpuFNdoNmAnvAYKacO1f4rLcLg%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

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

[David]

I had the same issue that the EventListeners were not triggered.
It was solved by adding -generateJsInteropExports to the SDM startup and to
the gwtc arguments.

Make sure that you delete the folder in temp that is generated by SDM. In
my case, for unknown reason to me, adding the flag did not clear the cache.


On Thu, Feb 2, 2017 at 10:04 PM John Huss  wrote:

> I tried this out by converting a small project that was using elemental 1
> to elemental 2.  I was able to get it to compile both in dev mode and in a
> production compile.  But my event listeners weren't firing at all when I
> ran it.
>
> Some feedback:
>
> 1) Lambda event listeners have to be cast into order to avoid an error
> from "javac":
>
> [javac] /Users/john/.../src/com/App.java:208: error: reference to
> addEventListener is ambiguous
>
> [javac] doc.getElementById("list").addEventListener("click", event ->
> listPressed(event));
>
> [javac]^
>
> [javac]   both method
> addEventListener(String,AddEventListenerListenerCallback) in Node and
> method addEventListener(String,EventListener) in Node match
>
> You can avoid this error with an explicit cast to EventListener (or
> AddEventListenerListenerCallback), but that isn't ideal:
>
> .addEventListener("click", (EventListener)event -> listPressed(event
> ));
>
> 2) Some things weren't defined on HTMLElement that I needed, namely:
> "outerHTML" and "children". These were available in elemental 1. They can
> be added by extending the class like so and casting to it:
>
> @JsType(isNative = true, namespace = JsPackage.GLOBAL)
>
> public class HTMLElementEx extends HTMLElement {
>
>  public String outerHTML;
>
> public HTMLCollection children;
>
> }
>
>
> On Wednesday, June 29, 2016 at 7:23:51 PM UTC-5, 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/d4cb6c43-cd40-494d-88eb-2aa786a18b6a%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/CABrJHW2cre56Eg89F2EXWKTDvozxs6Tj6DDxo629MLa8DiWerg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

[David]

Speaking of j2cl and GWT 3.0 it would be nice if somehow the development
did not happen behind closed doors.
It would give us a better indication of where it is heading. I feel a bit
anxious about the future because of this.

I do think GWT 2.8 is a great step forward and cutting all the old stuff
that no longer makes sense is also very good and the JsInterrop makes it
really easy to directly target JS libs.

But we are now more than a year further down the road and we still don't
see any public roadmap and concrete presentation on where this is going.
There is not a lot of activity on the public GWT github repo, nor on the
eclipse plugin (reported a few issues last year).

Anyway, back to the debugging experience. I switched to SDM some time ago
and I like it a lot. It is a very efficient workflow in most case. If you
see what people nowadays need to do to do pure JS development, I don't
think they are much more light weight than GWT anymore.

I miss some of the debugging features that I am used to in eclipse but in
reality I don't really need those features a lot. In Java those features
might be more used because we are writing multihreaded applications on it,
but in JS those kind of complicated issues do not really exist. So my needs
for debugging features are limited.

In the end we are targetting the browser with JS, CSS and HTML as the
native language. You cannot expect to stay shielded from those details in
all cases.

On Sun, Jan 15, 2017 at 8:28 PM, Stephen Haberman <
stephen.haber...@gmail.com> wrote:

> > This community needs more people *doing* stuff.
>
> Agreed (although I'm calling the kettle black here).
>
> I think historically GWT was really hard to contribute to; as you said, it
> was a single toolkit, and had a lot of complexity in it (non-trivial
> optimizations, non-trivial old browser support, etc.).
>
> My hope is that the just-a-transpiler approach of j2cl will also make it
> easier for a community to spring up around it. (And for separate small
> communities to spring up around whatever j2cl-based RPC, j2cl-based UI,
> j2c-based etc. libraries and frameworks come along.)
>
> - Stephen
>
>
>
>
>
> On Sun, Jan 15, 2017 at 8:51 AM Ivan Markov  wrote:
>
>>
>> Thank you, GWT people, for spending your time answering my thoughts.
>>
>>
>> To summarize (and TLDR), these were responses in the thread:
>>
>>
>> Ivan Markov: We should improve javascript-side debugging to match DevMode.
>>
>> Jens: Google is busy doing other things, so no hope with gwtromium.
>>
>> Jens: Change your attitude towards SuperDevMode. Also, DevMode was not so
>> cool.
>>
>> Arnaud: Don’t believe what I said in article! // thanks Arnaud, I’m
>> better now ;)
>>
>> Arnaud: TCP via localhost is fast enough
>>
>> Thomas Broyer: Even moving towards Typescript in GWT architecture,
>> there’s still big value of Java as language due to code reuse.
>>
>> Thomas Broyer: js-java glue that was related to codeserver for DevMode is
>> already in rotten state.
>>
>> Stephen Haberman: Abstract away browser and debug in JVM without browser.
>>
>>
>> I will respond here in one message to each of these points:
>>
>>
>> Ivan Markov and Jens, there’s a lot more to JVM debugging that stepping
>> and seeing the source. This is "drop frame", hot code reload, evaluate Java
>> expression (before deciding whether I should step into or over function
>> “verifyCondition(x1.var1, x2.var2)” I evaluate it in expression evaluator
>> first to check whether it’s valid – not working with java code in front of
>> me in IDE, when JS being evaluated). Also: breakpoint skip count and
>> specified exception breakpoint; field access breakpoint; something else
>> obvious so much that I even can’t specially recall. I code in java since
>> long ago, and these features are just common tools for me, hardwired into
>> the muscles, and this makes SuperDevMode looking like a toy. Last time I
>> checked, source maps do not map even variables names (not mentioning
>> scopes), and, knowing the pace of its development, I don’t give much hope
>> to that. Integration of JS debugging into IDEs can't help much with all
>> this. Saying all above, I see your (and similar people) favorable attitude
>> towards SuperDevMode coming from both low expectations [1] of what good
>> debugging is and maybe (sorry!) from excessive self-convincing that
>> SuperDevMode is super, due to apparent lack of alternative (which I try to
>> change by idea of gwtromium).
>>
>>
>> [1] I’m aware of two opposing attitudes toward debugging, best
>> illustrated by systems-level embedded programmers which usually can afford
>> only printf() and must put most effort in writing code that works correct
>> in first place (this influences their thought process and attitude even
>> after they move to upper levels), as opposed to high-level programmers
>> which can literally edit-and-continue most of their time.
>>
>>
>>
>> I openly admitted that the current GWT debugging experience 

[gwt-contrib] Re: Proposed LauncherDir change, add template bindAddress replacement

[David Becker]

A while back -bindAddress 0.0.0.0 was changed in GWT 2.8 to use the actual 
IP address instead of a local hostname to work better when operating in an 
environment where the local hostname isn't recognized by the client 
(specifically, things like windows tablets don't seem to recognize the mac 
myhost.local syntax). This seems like a logical extension of that 
functionality to cover even more scenarios and sounds good to me.

On Wednesday, October 12, 2016 at 10:17:42 AM UTC-7, Brandon Donnelson 
wrote:
>
> What would you think of adding a bindAddress replacement to the 
> template.nocache.js file. __bindAddress__ instead of 
> $window.location.hostname?
>
>
> Example Source - Used for testing Hack
>
> https://github.com/gwt-plugins/codeserver/blob/master/codeserver/src/main/java/com/google/gwt/dev/codeserver/LauncherDir.java#L127
>
> Reason
> Running code server on a local private ip and deploying the web app on a 
> different ip, this simplifies the setup. 
>
> Thoughts? 
>
> Thanks,
> Brandon
>

-- 
You received this message because you are subscribed to 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/9a15a854-b8e9-44a4-ba73-2307df0caf89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SNAPSHOT of 21 Sept breaks my build (invalid namespace

[David]

I'm using maven and I only have a dependency on 2.8.0-SNAPSHOT.
I have forced an update of the snapshots in an eclipse refresh and now it
seems to work.
I guess it was a local maven/nexus issue ?

I hope -strict becomes the default, why would you want to ignore errors ?
In most cases it is hiding some issue that will surface later.

On Wed, 21 Sep 2016 at 14:44, Thomas Broyer  wrote:

>
>
> On Wednesday, September 21, 2016 at 11:46:25 AM UTC+2, stuckagain wrote:
>>
>> It looks like some changes to JSInterop are breaking my build
>>
>> Compiling module com.swift.common.paging.PagingTest.JUnit
>>Ignored 1 unit with compilation errors in first pass.
>> Compile with -strict or with -logLevel set to TRACE or DEBUG to see all
>> errors.
>>Errors in com/google/gwt/emul/java/lang/String.java
>>   [ERROR] Line 165: 'String.NativeFunction
>> String.getFromCharCodeFunction()' has invalid namespace ''.
>>   [ERROR] Line 757: 'String.NativeString' has invalid namespace
>> ''.
>>
>
> Make (extra)sure you have the latest gwt-dev as well.
>
>
>> Additionally, how can I enable strict mode for GWTTestCases when using
>> tbroyer's maven plugin ?
>>
>
> This actually is not possible, and a limitation of GWT itself (JUnitShell
> doesn't support -strict or -failOnError).
>
> --
> You received this message because you are subscribed to 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/e3ffcc03-8b4b-4cc1-b9eb-936d0232dde3%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/CABrJHW2MpAJerjJkf1e9Ny-j2LuzrnNiz8QLWnjH%3DYbiibytKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: ScriptInjector seems to be broken (2.8-SNAPSHOT)

[David]

I'm sure my stuff was working fine with JsInterop 1.0 but with JsInterop
2.0 the only solution seems to be to use Global.top.window.document
As far as I remember I had it working somewhere half of July - but I might
be wrong. Can I force in maven to take a very specific snapshot version of
GWT 2.8.0, then I could double check ?

>From what you explain it seems like Global.window should have worked. But I
have this in my html:

I'm here!

Then when I try these:
Global.document.getElementById("test") -> null
Global.window.document.getElementById("test") -> null
Global.top.document.getElementById("test") -> [object HtmlDivElement]

Is this really how it should be ? I cannot use top since my app could be
embedded in an IFrame. I would have expected Global.document.getElementId
to have worked but it does not.

Anyway, maybe its because there is not enough docs available yet that I am
confused. Maybe it was accidentally working before and all this is just how
it is supposed to be ?


On Fri, Sep 9, 2016 at 12:13 PM Jens  wrote:

>
> This scoping is all very confusing :-).
>>
>> Anyway, this is what I am seeing with Elemental2:
>> - I have an application that generates HTML using a custom templating
>> system.
>> - I then put the HTML string in an Element with setInnerSafeHtml.
>> - After this I use Element2 to bind to the generated html. For that I was
>> using Global.document.getElementById(...).
>>
>> This used to work, but since a few weeks this stopped working.
>>
>> I now have to use Global.window.top.document.getElementById(...) to get
>> access to the ui dom nodes that I generated.
>>
>> Is this how it is supposed to be ? I was probably making the wrong
>> assumptions before ?
>>
>
> No. Elemental2's Global class uses @JsType(isNative = true, name =
> "window", namespace = JsPackage.GLOBAL) which translates to $wnd.window
> because JsInterop qualifies everything with $wnd (unless
> namespace="window" has been set as of the commit you have referenced
> before), JsPackage.GLOBAL is an empty namespace and window is the name.
>
> Are you sure nothing has changed in your app ?! I don't think something
> has changed in GWT as such (breaking) changes would normally cause more
> posts on gwt-contrib / gwt-user.
>
> -- 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/9b7a6321-c9ca-44a8-bd8d-01e6dc113f13%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/CABrJHW2JDzPyAHXD6MVgazyPGb_5t8tugTJqKrR4vbzVN5XCOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: ScriptInjector seems to be broken (2.8-SNAPSHOT)

[David]

This scoping is all very confusing :-).

Anyway, this is what I am seeing with Elemental2:
- I have an application that generates HTML using a custom templating
system.
- I then put the HTML string in an Element with setInnerSafeHtml.
- After this I use Element2 to bind to the generated html. For that I was
using Global.document.getElementById(...).

This used to work, but since a few weeks this stopped working.

I now have to use Global.window.top.document.getElementById(...) to get
access to the ui dom nodes that I generated.

Is this how it is supposed to be ? I was probably making the wrong
assumptions before ?



On Thu, Sep 8, 2016 at 11:17 PM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Global object is not scoped to window unless you explicitly say "window";
> so it should be $wnd by default.
>
> On Wed, Sep 7, 2016 at 2:50 AM, David <david.no...@gmail.com> wrote:
>
>> I was depending on JsInterop Global.document to get access to UI
>> components generated by my template engine.
>> The Global object is now scoped window, so I guess it is accessing the
>> wrong document as well ?
>>
>>
>> On Wed, 7 Sep 2016 at 11:40, David <david.no...@gmail.com> wrote:
>>
>>> I'm sure that it worked before. I'm also seeing some other issues where
>>> I am using JsInterop to interact with some generated HTML - but I am still
>>> investigating if that is due to changes in GWT or in our codebase.
>>>
>>> I did not work on this project for about 8 weeks, so I have quite a
>>> backlog to go through.
>>>
>>> On Tue, 6 Sep 2016 at 19:28, 'Goktug Gokdogan' via GWT Contributors <
>>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>>
>>>> It is surprising as Jens pointed out, we always qualified references
>>>> with $wnd until https://gwt-review.googlesource.com/#/c/15520/
>>>> (submitted 5 weeks ago). So it shouldn't have worked earlier if you were
>>>> not injecting it to TOP_WINDOW.
>>>> If it worked earlier, then we unintentionally fixed a bug. Could you
>>>> double check if this was working before so we can see if there are some
>>>> other unintended behavior change introduced somewhere else?
>>>>
>>>> On Tue, Sep 6, 2016 at 2:43 AM, stuckagain <david.no...@gmail.com>
>>>> wrote:
>>>>
>>>>> It was working fine before.
>>>>>
>>>>> Since it looks like JsInterop has changed recently (and it is still in
>>>>> beta) I will just update my code to either inject in the TOP_WINDOW or I
>>>>> try it with using window as namespace.
>>>>>
>>>>>
>>>>> On Monday, September 5, 2016 at 6:29:48 PM UTC+2, Jens wrote:
>>>>>>
>>>>>> Hm wondering how it ever worked for you as JsInterop usually
>>>>>> qualifies JS code with $wnd but your D3.js has been injected into the GWT
>>>>>> iframe. So AFAICT with JsInterop you would had to use TOP_WINDOW anyways.
>>>>>> You can make it work within the GWT iframe but then you can't use
>>>>>> JsPackage.GLOBAL but use a namespace that points to the iframe content
>>>>>> window.
>>>>>>
>>>>>> Also see:
>>>>>> https://groups.google.com/d/msg/google-web-toolkit/GcsWUuzexvE/ApUg3sLZCQAJ
>>>>>>
>>>>>> So it looks like this behavior has changed? But yes you would need to
>>>>>> use "window" now to references the iframe's content window if you inject
>>>>>> the code into the iframe.
>>>>>>
>>>>>> -- 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/7862784c-854a-4bb1-85c0-2b7734a984d3%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/7862784c-854a-4bb1-85c0-2b7734a984d3%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>&

Re: [gwt-contrib] Re: ScriptInjector seems to be broken (2.8-SNAPSHOT)

[David]

I'm sure that it worked before. I'm also seeing some other issues where I
am using JsInterop to interact with some generated HTML - but I am still
investigating if that is due to changes in GWT or in our codebase.

I did not work on this project for about 8 weeks, so I have quite a backlog
to go through.

On Tue, 6 Sep 2016 at 19:28, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> It is surprising as Jens pointed out, we always qualified references with
> $wnd until https://gwt-review.googlesource.com/#/c/15520/ (submitted 5
> weeks ago). So it shouldn't have worked earlier if you were not injecting
> it to TOP_WINDOW.
> If it worked earlier, then we unintentionally fixed a bug. Could you
> double check if this was working before so we can see if there are some
> other unintended behavior change introduced somewhere else?
>
> On Tue, Sep 6, 2016 at 2:43 AM, stuckagain  wrote:
>
>> It was working fine before.
>>
>> Since it looks like JsInterop has changed recently (and it is still in
>> beta) I will just update my code to either inject in the TOP_WINDOW or I
>> try it with using window as namespace.
>>
>>
>> On Monday, September 5, 2016 at 6:29:48 PM UTC+2, Jens wrote:
>>>
>>> Hm wondering how it ever worked for you as JsInterop usually qualifies
>>> JS code with $wnd but your D3.js has been injected into the GWT iframe. So
>>> AFAICT with JsInterop you would had to use TOP_WINDOW anyways. You can make
>>> it work within the GWT iframe but then you can't use JsPackage.GLOBAL but
>>> use a namespace that points to the iframe content window.
>>>
>>> Also see:
>>> https://groups.google.com/d/msg/google-web-toolkit/GcsWUuzexvE/ApUg3sLZCQAJ
>>>
>>> So it looks like this behavior has changed? But yes you would need to
>>> use "window" now to references the iframe's content window if you inject
>>> the code into the iframe.
>>>
>>> -- 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/7862784c-854a-4bb1-85c0-2b7734a984d3%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/CAN%3DyUA0RioQk7GatwdbkvwZKT6gKDEmB0daytVoKa9a%3DnGUd3A%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/CABrJHW3EG79VKA9Q9NpVBppwCO7j3XD05kzZAY%3DPPuCYV5z%2BXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: ScriptInjector seems to be broken (2.8-SNAPSHOT)

[David]

I was depending on JsInterop Global.document to get access to UI components
generated by my template engine.
The Global object is now scoped window, so I guess it is accessing the
wrong document as well ?


On Wed, 7 Sep 2016 at 11:40, David <david.no...@gmail.com> wrote:

> I'm sure that it worked before. I'm also seeing some other issues where I
> am using JsInterop to interact with some generated HTML - but I am still
> investigating if that is due to changes in GWT or in our codebase.
>
> I did not work on this project for about 8 weeks, so I have quite a
> backlog to go through.
>
> On Tue, 6 Sep 2016 at 19:28, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> It is surprising as Jens pointed out, we always qualified references with
>> $wnd until https://gwt-review.googlesource.com/#/c/15520/ (submitted 5
>> weeks ago). So it shouldn't have worked earlier if you were not injecting
>> it to TOP_WINDOW.
>> If it worked earlier, then we unintentionally fixed a bug. Could you
>> double check if this was working before so we can see if there are some
>> other unintended behavior change introduced somewhere else?
>>
>> On Tue, Sep 6, 2016 at 2:43 AM, stuckagain <david.no...@gmail.com> wrote:
>>
>>> It was working fine before.
>>>
>>> Since it looks like JsInterop has changed recently (and it is still in
>>> beta) I will just update my code to either inject in the TOP_WINDOW or I
>>> try it with using window as namespace.
>>>
>>>
>>> On Monday, September 5, 2016 at 6:29:48 PM UTC+2, Jens wrote:
>>>>
>>>> Hm wondering how it ever worked for you as JsInterop usually qualifies
>>>> JS code with $wnd but your D3.js has been injected into the GWT iframe. So
>>>> AFAICT with JsInterop you would had to use TOP_WINDOW anyways. You can make
>>>> it work within the GWT iframe but then you can't use JsPackage.GLOBAL but
>>>> use a namespace that points to the iframe content window.
>>>>
>>>> Also see:
>>>> https://groups.google.com/d/msg/google-web-toolkit/GcsWUuzexvE/ApUg3sLZCQAJ
>>>>
>>>> So it looks like this behavior has changed? But yes you would need to
>>>> use "window" now to references the iframe's content window if you inject
>>>> the code into the iframe.
>>>>
>>>> -- 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/7862784c-854a-4bb1-85c0-2b7734a984d3%40googlegroups.com
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/7862784c-854a-4bb1-85c0-2b7734a984d3%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/CAN%3DyUA0RioQk7GatwdbkvwZKT6gKDEmB0daytVoKa9a%3DnGUd3A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0RioQk7GatwdbkvwZKT6gKDEmB0daytVoKa9a%3DnGUd3A%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/CABrJHW2iWUBMUEThzroC7sZYnujoqXKo%3DTgmMjp2qh4uneCEmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Hide GWT Development Mode window

[David Becker]

Yes, just run in headless mode by adding "-Djava.awt.headless=true" to your 
VM arguments. I do this all the time on mac.

http://www.oracle.com/technetwork/articles/javase/headless-136834.html

On Friday, August 19, 2016 at 11:56:24 AM UTC-7, Paul Stockley wrote:
>
> When launching the SDM code server, is it possible to hide the swing UI 
> window?
>

-- 
You received this message because you are subscribed to 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/af941626-4911-4601-a77d-3d56cc24afba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

[David Becker]

That would be — awesome.  Pretty please?  :)

On Tuesday, May 17, 2016 at 11:13:09 AM UTC-7, Jens wrote:
>
>
> The issue is that @JsFunction implementors must "extend 
>> java.lang.Object" as their parent. because standard library functions 
>> are/canbe implemented on classes with complicated type hierarchies, 
>> this would cause failures to compile. 
>>
>> This restriction comes about from the efficiency trick we use to 
>> reparent a lambda to have the native JS Function object as it's 
>> parent. We can't reparent objects whose immediate supertype isn't 
>> java.lang.Object, but not doing this trick would make output more 
>> bloated/slow, and wouldn't allow Java8 lambas to act like JS functions 
>> (e.g. can call Function.bind/apply/etc on them) without some kind of 
>> wrapping/unwrapping process, plus an additional level of hacks to make 
>> sure referential integrity was preserved. 
>>
>
> Can you elaborate on it? I think its really annoying that every project 
> must redefine callbacks, functions, consumers, whatever just because JRE 
> has some default methods in their version and GWT can not handle it. IMHO 
> convenience is the most important thing here.
>
> For example wouldn't it be possible to redefine the way @JsFunction works 
> so something like:
>
> 1.) @JsFunction marks a parameter to be a functional parameter
> 2.) The type of the parameter that is marked with @JsFunction must have 
> exactly one @JsFunctionTarget in its class definition
> 3.) @JsFunctionTarget marks an abstract method in an interface or in an 
> abstract class.
>
>
> Then we would do something like
>
> @JsType(native = true, ...)
> class SomeAsyncClass {
>   void onSuccess(@JsFunction Consumer onSuccess);
> }
>
>
> interface Consumer {
>   @JsFunctionTarget
>   void accept(T value);
>
>
>   // other default methods
> }
>
>
>
> JavaScript:
>
> var asyncClass = new SomeAsyncClass();
> var someConsumer = // ...anything that has implemented Consumer
> asyncClass.onSuccess(
>   function(value) {  // @JsFunction tells GWT to generate a "bridge" 
> method using the parameters of @JsFunctionTarget and delegates to the 
> Consumer implementation
> someConsumer.accept(value);
>   }
> );
>
>
> The above is probably not fully correct JS and maybe has some "this" 
> problems but I think you get the idea. Marking parameters as @JsFunction 
> would allow you to choose wether or not you want GWT to handle a Consumer 
> as callback or as ordinary object, e.g. if you do not annotate a parameter 
> of type Consumer with @JsFunction then it will be passed as normal object 
> without any bridge methods that delegate to a @JsFunctionTarget method.
>
> Wouldn't this be possible?
>
> -- 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/3f80b897-d561-4bd3-9555-922cb6b95007%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

[David Becker]

Well bummer.  Thanks for the detailed info.  Perhaps someday it can check 
if they do directly extend Object or not and either take the shortcut or 
the long way...  I'm afraid that's way over my depth in the GWT code to 
attempt a patch though.

On Wednesday, May 11, 2016 at 6:07:15 PM UTC-7, Ray Cromwell wrote:
>
> The issue is that @JsFunction implementors must "extend 
> java.lang.Object" as their parent. because standard library functions 
> are/canbe implemented on classes with complicated type hierarchies, 
> this would cause failures to compile. 
>
> This restriction comes about from the efficiency trick we use to 
> reparent a lambda to have the native JS Function object as it's 
> parent. We can't reparent objects whose immediate supertype isn't 
> java.lang.Object, but not doing this trick would make output more 
> bloated/slow, and wouldn't allow Java8 lambas to act like JS functions 
> (e.g. can call Function.bind/apply/etc on them) without some kind of 
> wrapping/unwrapping process, plus an additional level of hacks to make 
> sure referential integrity was preserved. 
>
>
>
>
> On Wed, May 11, 2016 at 5:51 PM, Colin Alworth <nilo...@gmail.com 
> > wrote: 
> > No, its not a solution, so much as a "here is a workaround that might 
> > satisfy your specific case as you build your JsInterop-based lib so that 
> it 
> > looks like it can use @FunctionalInterface types". I do not believe it 
> to be 
> > a comprehensive way to provide the feature requested. At some point I'll 
> try 
> > to write it out in more detail in case there is any actual merit to it 
> (I'm 
> > all but sure that there isn't, or you would have thought of it already). 
> > 
> > On Wed, May 11, 2016 at 7:47 PM 'Goktug Gokdogan' via GWT Contributors 
> > <google-web-toolkit-contributors@googlegroups.com > wrote: 
> >> 
> >> We cannot impose @JsFunction restrictions on standard library 
> >> @FunctionInterfaces. You can see some of the limitations in the 
> Javadoc. 
> >> 
> >> @Colin: I didn't understand your solution. Feel free to propose 
> something 
> >> more concrete and we can discuss over that. 
> >> 
> >> On Wed, May 11, 2016 at 4:22 PM, Colin Alworth <nilo...@gmail.com 
> > wrote: 
> >>> 
> >>> Unfortunately, you can't add the annotation to an interface with more 
> >>> than one method, even if those methods are default methods, at least 
> as it 
> >>> is currently implemented. 
> >>> 
> >>> I can't remember the exact specifics around why this is the case, but 
> >>> believe it has to do with handling functions passed from js into java, 
> and 
> >>> not being able to nicely handle instances that decide to override 
> those 
> >>> other methods as well. 
> >>> 
> >>> You could nearly achieve this effect by just making a method reference 
> to 
> >>> the "apply" or "test" method, and passing that as an actual JsFunction 
> type. 
> >>> I don't right away see a problem with syntactic sugar doing this 
> >>> automatically, but am sure that someone will be able to enlighten us 
> as to 
> >>> what confusing side effects this might have (or alternately confirm 
> that 
> >>> this is a great idea, and point to where in the compiler the changes 
> need to 
> >>> be made). 
> >>> 
> >>> 
> >>> On Wed, May 11, 2016, 6:15 PM David Becker <david@sencha.com 
> > 
> >>> wrote: 
> >>>> 
> >>>> I think it would be good to add @JsFunction to all of the 
> >>>> java.util.function interfaces in the JRE Emulation so that we can use 
> >>>> standard function signatures with JsInterop. 
> >>>> 
> >>>> Would that work?  Any drawbacks? 
> >>>> 
> >>>> If you think that's a good idea, I can submit a patch. 
> >>>> 
> >>>> Thanks! 
> >>>> 
> >>>> -- 
> >>>> You received this message because you are subscribed to the Google 
> >>>> Groups "GWT Contributors" group. 
> >>>> To unsubscribe from this group and stop receiving emails from it, 
> send 
> >>>> an email to 
> google-web-toolkit-contributors+unsubscr...@googlegroups.com . 
>
> >>>> To view this discussion on the web visit 
> >>>> 
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/13df9bed-108f-4cdf-8c00-123f1186e461%40googlegroup

[gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

[David Becker]

I think it would be good to add @JsFunction to all of the 
java.util.function interfaces in the JRE Emulation so that we can use 
standard function signatures with JsInterop.  

Would that work?  Any drawbacks?

If you think that's a good idea, I can submit a patch.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/13df9bed-108f-4cdf-8c00-123f1186e461%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Newer gwt-maven-plugin than 2.8.0-beta1 ?

[David Becker]

Thank you, Thomas!  I swear I tried that repo and it couldn't find the 
plugin snapshot, but I've got it going now.  I'm still getting the JRE 
Emulation warning (on java.util.String no less) in IntelliJ though.  :( 
 But, that doesn't keep it from working.  I thought maybe there was a 
dependency there because it didn't do that when both the plugin and GWT 
were on 2.8.0-beta1, but perhaps it's really an issue with the GWT 
snapshot.  Being a snapshot, that's always a possibility of course.  :)

Thanks for your help!

On Monday, May 2, 2016 at 5:09:56 PM UTC-7, David Becker wrote:
>
> Is there a newer gwt-maven-plugin than 2.8.0-beta1 that should be used 
> with GWT 2.8.0-SNAPSHOT?  I want to try out the latest snapshots to keep 
> abreast of the current status-quo, but I'm getting red highlights on JRE 
> Emulation in IntelliJ that I don't get if I use GWT 2.8.0-beta1 with the 
> plugin.  If there is a newer plugin, where would I find it?  I tried many 
> different URLs I found by searching, but they're all old and none seem find 
> a 2.8.0-SNAPSHOT for gwt-maven-plugin.
>
> Thanks in advance for any help!
>

-- 
You received this message because you are subscribed to 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/7d991fc4-9b98-4855-829a-89052a4ff000%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Newer gwt-maven-plugin than 2.8.0-beta1 ?

[David Becker]

Is there a newer gwt-maven-plugin than 2.8.0-beta1 that should be used with 
GWT 2.8.0-SNAPSHOT?  I want to try out the latest snapshots to keep abreast 
of the current status-quo, but I'm getting red highlights on JRE Emulation 
in IntelliJ that I don't get if I use GWT 2.8.0-beta1 with the plugin.  If 
there is a newer plugin, where would I find it?  I tried many different 
URLs I found by searching, but they're all old and none seem find a 
2.8.0-SNAPSHOT for gwt-maven-plugin.

Thanks in advance for any help!

-- 
You received this message because you are subscribed to 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/3a3e9ebe-99ed-443c-9381-023be3044351%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Elemental 2 and J2CL timeline

[David Becker]

As a GXT developer at Sencha, we are keenly aware of the community's 
concerns around the future of things like Widget, UiBinder, etc. and how 
GWT 3 might upend the apple-cart.  GWT 3 is still very far away and its 
plans very nebulous.  It's far too early to talk specifics, but I assure 
you that we are keeping a close eye on it and planning for that future. 
Whatever the outcome, it is likely that you will find a way forward with 
Sencha.

That said, a community project to pick up the mantle for Widget, UiBinder 
and other pieces that get dropped from GWT is an excellent idea.

On Wednesday, April 27, 2016 at 7:50:42 AM UTC-7, Paul Stockley wrote:
>
> I am assuming that Google isn't really interested in Widgets and UiBinder 
> for J2CL given their usage of GWT in inbox etc. I could be wrong. Assuming 
> I am not, I would like to investigate starting up some community projects 
> for Widget and Uibinder support. These won't be trivial to replace so we 
> will need quite a long lead time. However, I think if we can show the 
> community that they will be able to rely on these in the future, it will go 
> a long way to reducing the fear that GWT is dead. 
>
>
> On Wednesday, April 27, 2016 at 10:06:20 AM UTC-4, Colin Alworth wrote:
>>
>> I can't speak for J2CL's timelines, as it is an internal project at this 
>> time. However, it has been stated that it will support GWT's JRE emulation 
>> and JsInterop out of the box, and the expectation is that it will simply be 
>> a transpiler and won't support generators (suggested that projects move to 
>> APT or the like), or linkers (since the Closure Compiler manages this part 
>> of things).
>>
>> By itself, this means that Widget can work, though Element will need to 
>> be reimplemented in JsInterop since JSOs won't exist (and JSNI is likely to 
>> have a replacement as well). On the other hand, UiBinder uses the GWT 
>> Generator system, which doesn't at this time have a clear upgrade path.
>>
>> To think about life without GWT.create(Foo.class), consider APT-based 
>> projects like AutoValue, where class sources are generated on your 
>> classpath (by your build tool, and your IDE if configured correctly) so 
>> that you can reference these generated classes directly from within your 
>> sources. For cases where you want to pick the right implementation (rtl, 
>> locale, device formfactor, etc), a factory methods can also be declared 
>> within the generated code, and you can reference  that rather than a 
>> constructor.
>>
>> On Tuesday, April 26, 2016 at 8:30:21 AM UTC-5, Paul Stockley wrote:
>>>
>>> Does anyone have any idea when elemental 2 will be available? Also what 
>>> is a rough timeline for a version on J2CL being available, is it 6 months, 
>>> a year or more away? 
>>>
>>> The reason I ask is that I am thinking about how our company can migrate 
>>> to the new compiler. We will need widgets and UiBinder for quite a while, 
>>> even though we will slowly migrate to React. I was contemplating creating a 
>>> project to port the basic Widget framework to use something like elemental. 
>>> Also I was thinking about how to build a new version of UiBinder that 
>>> didn't use GWT.create.
>>>
>>

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

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

[David]

Yes the org.w3c stuff was my own, it was defined in the html5 module you
see in the classpath.
I hope that this was a border case and not typical what happens if you have
super sources with import statements that cannot be resolved ?
Because in that case the compiler should give a better error message.

On Wed, 27 Apr 2016 at 15:50, Colin Alworth <niloc...@gmail.com> wrote:

> Thanks. Can you confirm that org.w3c.dom is your own code, and not part
> of GWT, so it was just out of date? I don't see a jar with that name on
> your classpath, and neither of the two EntityReference.java files in GWT
> live in that package or appear have jsinterop annotations.
>
>
> On Wednesday, April 27, 2016 at 8:46:13 AM UTC-5, stuckagain wrote:
>
>> Colin,
>>
>> The stacktrace was is my initial post.
>>
>> Anyway: I managed to find the root cause and solution.
>>
>> The super source java file is using JsInterop to map org.w3c.dom API's.
>> It had annotations like this:
>> @JsType(isNative=true, namespace=JsNamespace.GLOBAL).
>>
>> However, in the snapshot this JsNamespace no longer exists and is now
>> replaced with JsPackage.GLOBAL.
>> After changing those references the compilation now succeeds.
>>
>> The old sources were like this:
>> package org.w3c.dom;
>> import com.google.gwt.core.client.js.JsNamespace;;
>> import jsinterop.annotations.JsType;
>>  @JsType(isNative=true,namespace=JsNamespace.GLOBAL)
>> public interface EntityReference extends Node {
>> }
>> I changed it to this:
>> package org.w3c.dom;
>> import jsinterop.annotations.JsPackage;
>> import jsinterop.annotations.JsType;
>>  @JsType(isNative=true,namespace=JsPackage.GLOBAL)
>> public interface EntityReference extends Node {
>> }
>>
>>
>> On Wed, 27 Apr 2016 at 15:32, Colin Alworth <nilo...@gmail.com> wrote:
>>
> Can you share the stack trace, the file it is attempting to read, and your
>>> classpath? It does sound like it might be a bug, but without the ability to
>>> reproduce, it is difficult to say more. One case where it might not be a
>>> bug despite its behavior: where it is reusing gwt-unitCache or the like
>>> from an older version of gwt.
>>>
>>> On Wed, Apr 27, 2016 at 8:23 AM David <david...@gmail.com> wrote:
>>>
>> I managed to get this to run in a Debugger, from within the maven
>>>> invocation.
>>>> The exception is thrown on a super source file in one of my gwt-lib
>>>> maven artifacts.
>>>> It is trying to parse a .java file as a class file and this throws the
>>>> reported exception.
>>>>
>>>> This sounds like a bug to me!?
>>>>
>>>> On Wed, 27 Apr 2016 at 14:41, David <david...@gmail.com> wrote:
>>>>
>>> It was working fine with GWT 2.8.0-beta1 using the exact same pom files.
>>>>> When I point to GWT-2.8.0-SNAPSHOT I get this error.
>>>>> So the only thing that changed is the version of GWT moving from beta1
>>>>> to SNAPSHOT.
>>>>>
>>>>> I am using logLevel ALL but it looks like the 2.8 compiler does not
>>>>> really use logging. Besides a few INFO and WARNING statements nothing is
>>>>> logged
>>>>>
>>>>> This is the path that is being used.
>>>>>
>>>>> [DEBUG]   (s) projectArtifactMap =
>>>>> {com.google.gwt:gwt-user=com.google.gwt:gwt-user:jar:2.8.0-SNAPSHOT:compile,
>>>>> com.google.jsinterop:jsinterop-annotations=com.google.jsinterop:jsinterop-annotations:jar:sources:1.0.0-SNAPSHOT:compile,
>>>>> javax.validation:validation-api=javax.validation:validation-api:jar:sources:1.0.0.GA:compile,
>>>>> com.google.gwt:gwt-dev=com.google.gwt:gwt-dev:jar:2.8.0-SNAPSHOT:compile,
>>>>> org.ow2.asm:asm=org.ow2.asm:asm:jar:5.0.3:compile,
>>>>> org.ow2.asm:asm-util=org.ow2.asm:asm-util:jar:5.0.3:compile,
>>>>> org.ow2.asm:asm-tree=org.ow2.asm:asm-tree:jar:5.0.3:compile,
>>>>> org.ow2.asm:asm-commons=org.ow2.asm:asm-commons:jar:5.0.3:compile,
>>>>> org.eclipse.jetty.websocket:websocket-client=org.eclipse.jetty.websocket:websocket-client:jar:9.2.14.v20151106:compile,
>>>>> org.eclipse.jetty:jetty-util=org.eclipse.jetty:jetty-util:jar:9.2.14.v20151106:compile,
>>>>> org.eclipse.jetty:jetty-io=org.eclipse.jetty:jetty-io:jar:9.2.14.v20151106:compile,
>>>>> org.eclipse.jetty.websocket:websocket-common=org.eclipse.jetty.websocket:websocket-common:jar:9.2.14.v20151106:compile,
>&

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

[David]

Colin,

The stacktrace was is my initial post.

Anyway: I managed to find the root cause and solution.

The super source java file is using JsInterop to map org.w3c.dom API's.
It had annotations like this:
@JsType(isNative=true, namespace=JsNamespace.GLOBAL).

However, in the snapshot this JsNamespace no longer exists and is now
replaced with JsPackage.GLOBAL.
After changing those references the compilation now succeeds.

The old sources were like this:
package org.w3c.dom;
import com.google.gwt.core.client.js.JsNamespace;;
import jsinterop.annotations.JsType;
 @JsType(isNative=true,namespace=JsNamespace.GLOBAL)
public interface EntityReference extends Node {
}
I changed it to this:
package org.w3c.dom;
import jsinterop.annotations.JsPackage;
import jsinterop.annotations.JsType;
 @JsType(isNative=true,namespace=JsPackage.GLOBAL)
public interface EntityReference extends Node {
}


On Wed, 27 Apr 2016 at 15:32, Colin Alworth <niloc...@gmail.com> wrote:

> Can you share the stack trace, the file it is attempting to read, and your
> classpath? It does sound like it might be a bug, but without the ability to
> reproduce, it is difficult to say more. One case where it might not be a
> bug despite its behavior: where it is reusing gwt-unitCache or the like
> from an older version of gwt.
>
> On Wed, Apr 27, 2016 at 8:23 AM David <david.no...@gmail.com> wrote:
>
>> I managed to get this to run in a Debugger, from within the maven
>> invocation.
>> The exception is thrown on a super source file in one of my gwt-lib maven
>> artifacts.
>> It is trying to parse a .java file as a class file and this throws the
>> reported exception.
>>
>> This sounds like a bug to me!?
>>
>> On Wed, 27 Apr 2016 at 14:41, David <david.no...@gmail.com> wrote:
>>
>>> It was working fine with GWT 2.8.0-beta1 using the exact same pom files.
>>> When I point to GWT-2.8.0-SNAPSHOT I get this error.
>>> So the only thing that changed is the version of GWT moving from beta1
>>> to SNAPSHOT.
>>>
>>> I am using logLevel ALL but it looks like the 2.8 compiler does not
>>> really use logging. Besides a few INFO and WARNING statements nothing is
>>> logged
>>>
>>> This is the path that is being used.
>>>
>>> [DEBUG]   (s) projectArtifactMap =
>>> {com.google.gwt:gwt-user=com.google.gwt:gwt-user:jar:2.8.0-SNAPSHOT:compile,
>>> com.google.jsinterop:jsinterop-annotations=com.google.jsinterop:jsinterop-annotations:jar:sources:1.0.0-SNAPSHOT:compile,
>>> javax.validation:validation-api=javax.validation:validation-api:jar:sources:1.0.0.GA:compile,
>>> com.google.gwt:gwt-dev=com.google.gwt:gwt-dev:jar:2.8.0-SNAPSHOT:compile,
>>> org.ow2.asm:asm=org.ow2.asm:asm:jar:5.0.3:compile,
>>> org.ow2.asm:asm-util=org.ow2.asm:asm-util:jar:5.0.3:compile,
>>> org.ow2.asm:asm-tree=org.ow2.asm:asm-tree:jar:5.0.3:compile,
>>> org.ow2.asm:asm-commons=org.ow2.asm:asm-commons:jar:5.0.3:compile,
>>> org.eclipse.jetty.websocket:websocket-client=org.eclipse.jetty.websocket:websocket-client:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-util=org.eclipse.jetty:jetty-util:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-io=org.eclipse.jetty:jetty-io:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty.websocket:websocket-common=org.eclipse.jetty.websocket:websocket-common:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty.websocket:websocket-api=org.eclipse.jetty.websocket:websocket-api:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-webapp=org.eclipse.jetty:jetty-webapp:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-xml=org.eclipse.jetty:jetty-xml:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-servlet=org.eclipse.jetty:jetty-servlet:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-security=org.eclipse.jetty:jetty-security:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-servlets=org.eclipse.jetty:jetty-servlets:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-continuation=org.eclipse.jetty:jetty-continuation:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-http=org.eclipse.jetty:jetty-http:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-annotations=org.eclipse.jetty:jetty-annotations:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-plus=org.eclipse.jetty:jetty-plus:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-jndi=org.eclipse.jetty:jetty-jndi:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:apache-jsp=org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile,
>>> org.eclipse.jetty:jetty-server=org.eclipse.jetty:

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

[David]

I managed to get this to run in a Debugger, from within the maven
invocation.
The exception is thrown on a super source file in one of my gwt-lib maven
artifacts.
It is trying to parse a .java file as a class file and this throws the
reported exception.

This sounds like a bug to me!?

On Wed, 27 Apr 2016 at 14:41, David <david.no...@gmail.com> wrote:

> It was working fine with GWT 2.8.0-beta1 using the exact same pom files.
> When I point to GWT-2.8.0-SNAPSHOT I get this error.
> So the only thing that changed is the version of GWT moving from beta1 to
> SNAPSHOT.
>
> I am using logLevel ALL but it looks like the 2.8 compiler does not really
> use logging. Besides a few INFO and WARNING statements nothing is logged
>
> This is the path that is being used.
>
> [DEBUG]   (s) projectArtifactMap =
> {com.google.gwt:gwt-user=com.google.gwt:gwt-user:jar:2.8.0-SNAPSHOT:compile,
> com.google.jsinterop:jsinterop-annotations=com.google.jsinterop:jsinterop-annotations:jar:sources:1.0.0-SNAPSHOT:compile,
> javax.validation:validation-api=javax.validation:validation-api:jar:sources:1.0.0.GA:compile,
> com.google.gwt:gwt-dev=com.google.gwt:gwt-dev:jar:2.8.0-SNAPSHOT:compile,
> org.ow2.asm:asm=org.ow2.asm:asm:jar:5.0.3:compile,
> org.ow2.asm:asm-util=org.ow2.asm:asm-util:jar:5.0.3:compile,
> org.ow2.asm:asm-tree=org.ow2.asm:asm-tree:jar:5.0.3:compile,
> org.ow2.asm:asm-commons=org.ow2.asm:asm-commons:jar:5.0.3:compile,
> org.eclipse.jetty.websocket:websocket-client=org.eclipse.jetty.websocket:websocket-client:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-util=org.eclipse.jetty:jetty-util:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-io=org.eclipse.jetty:jetty-io:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty.websocket:websocket-common=org.eclipse.jetty.websocket:websocket-common:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty.websocket:websocket-api=org.eclipse.jetty.websocket:websocket-api:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-webapp=org.eclipse.jetty:jetty-webapp:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-xml=org.eclipse.jetty:jetty-xml:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-servlet=org.eclipse.jetty:jetty-servlet:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-security=org.eclipse.jetty:jetty-security:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-servlets=org.eclipse.jetty:jetty-servlets:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-continuation=org.eclipse.jetty:jetty-continuation:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-http=org.eclipse.jetty:jetty-http:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-annotations=org.eclipse.jetty:jetty-annotations:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-plus=org.eclipse.jetty:jetty-plus:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-jndi=org.eclipse.jetty:jetty-jndi:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:apache-jsp=org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty:jetty-server=org.eclipse.jetty:jetty-server:jar:9.2.14.v20151106:compile,
> org.eclipse.jetty.toolchain:jetty-schemas=org.eclipse.jetty.toolchain:jetty-schemas:jar:3.1.M0:compile,
> javax.servlet:javax.servlet-api=javax.servlet:javax.servlet-api:jar:3.0.1:provided,
> org.mortbay.jasper:apache-jsp=org.mortbay.jasper:apache-jsp:jar:8.0.9.M3:compile,
> org.mortbay.jasper:apache-el=org.mortbay.jasper:apache-el:jar:8.0.9.M3:compile,
> com.google.gwt:gwt-elemental=com.google.gwt:gwt-elemental:jar:2.8.0-SNAPSHOT:compile,
> com.google.inject:guice=com.google.inject:guice:jar:3.0:compile,
> javax.inject:javax.inject=javax.inject:javax.inject:jar:1:compile,
> aopalliance:aopalliance=aopalliance:aopalliance:jar:1.0:compile,
> com.acme.acmeproduct:gui.html5=com.acme.acmeproduct:gui.html5:gwt-lib:0.0.1-SNAPSHOT:compile,
> com.acme.acmeproduct:gui.editor=com.acme.acmeproduct:gui.editor:gwt-lib:0.0.1-SNAPSHOT:compile,
> com.acme.acmecommon:common.core=com.acme.acmecommon:common.core:jar:0.0.1-SNAPSHOT:compile,
> com.acme.acmecommon:common.config=com.acme.acmecommon:common.config:gwt-lib:0.0.1-SNAPSHOT:compile,
> com.acme.acmecommon:common.servlet=com.acme.acmecommon:common.servlet:jar:0.0.1-SNAPSHOT:compile,
> com.fasterxml.jackson.core:jackson-core=com.fasterxml.jackson.core:jackson-core:jar:2.7.3:compile,
> com.fasterxml.jackson.core:jackson-databind=com.fasterxml.jackson.core:jackson-databind:jar:2.7.3:compile,
> com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider=com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.6.3:compile,
> com.fasterxml.jackson.jaxrs:jackson-jaxrs-base=com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.6.3:compile,
> com.fasterxml.jackson.module:jackson-module-jaxb-annotations=com.fasterxml.jackson.module:jacks

Re: [gwt-contrib] Re: Addresses are different when running SDM with bindAddress 0.0.0.0?

[David Becker]

I have incorporated the latest review feedback and reposted.  Please review 
again.

Thank you all for your patience as I learn the ropes...

On Tuesday, March 22, 2016 at 2:51:05 PM UTC-7, David Becker wrote:
>
> Hi Jens, et. al,
>
> I was just wondering if you thought 
> https://gwt-review.googlesource.com/#/c/14300/ might get picked up in 
> time for 2.8?  It seems to have stalled out on the review front.
>
> Thanks!
>
> On Thursday, January 28, 2016 at 3:55:34 PM UTC-8, Brandon Donnelson wrote:
>>
>> Thanks Jens,
>> Brandon
>>
>> On Thu, Jan 28, 2016 at 3:52 PM, Jens <jens.ne...@gmail.com> wrote:
>>
>>> Make both lines the same:
>>>
>>>
>>> https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/dev/DevModeBase.java#156
>>>
>>> https://gwt.googlesource.com/gwt/+/master/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java#529
>>>
>>> One uses getHostName() while the other uses getHostAddress()
>>>
>>> -- 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/45e5da4d-6895-4174-8205-fd71040dd127%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/45e5da4d-6895-4174-8205-fd71040dd127%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Regards,
>> *Brandon Donnelson*
>> GXT Support Engineer
>> Office: +1-650-243-0623
>>
>> [image: Sencha Inc.] <https://www.sencha.com/>
>>
>> [image: http://cdn.sencha.com/img/2016-email-sig/icon-facebook-24x24.png] 
>> <http://www.facebook.com/senchainc>
>>
>> [image: http://cdn.sencha.com/img/2016-email-sig/icon-twitter-24x24.png] 
>> <http://twitter.com/sencha>
>>
>> [image: http://cdn.sencha.com/img/2016-email-sig/icon-linkedin-24x24.png] 
>> <https://www.linkedin.com/company/sencha-inc>
>>
>> [image: http://cdn.sencha.com/img/2016-email-sig/icon-youtube-24x24.png] 
>> <http://www.youtube.com/SenchaInc>
>>
>> [image: 
>> http://cdn.sencha.com/img/2016-email-sig/icon-googleplus-24x24.png] 
>> <https://plus.google.com/117303203295549187007?prsrc=3>
>>
>> *Winner of the SD Times 100 2015 Award* 
>> <https://www.sencha.com/company/press/sencha-wins-2015-sd-times-100-award-in-user-experience-category/>
>>
>>

-- 
You received this message because you are subscribed to 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/420fadb6-e231-4765-a38a-1f545282ade6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Addresses are different when running SDM with bindAddress 0.0.0.0?

[David Becker]

Hi Jens, et. al,

I was just wondering if you 
thought https://gwt-review.googlesource.com/#/c/14300/ might get picked up 
in time for 2.8?  It seems to have stalled out on the review front.

Thanks!

On Thursday, January 28, 2016 at 3:55:34 PM UTC-8, Brandon Donnelson wrote:
>
> Thanks Jens,
> Brandon
>
> On Thu, Jan 28, 2016 at 3:52 PM, Jens  
> wrote:
>
>> Make both lines the same:
>>
>>
>> https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/dev/DevModeBase.java#156
>>
>> https://gwt.googlesource.com/gwt/+/master/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java#529
>>
>> One uses getHostName() while the other uses getHostAddress()
>>
>> -- 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/45e5da4d-6895-4174-8205-fd71040dd127%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Regards,
> *Brandon Donnelson*
> GXT Support Engineer
> Office: +1-650-243-0623
>
> [image: Sencha Inc.] 
>
> [image: http://cdn.sencha.com/img/2016-email-sig/icon-facebook-24x24.png] 
> 
>
> [image: http://cdn.sencha.com/img/2016-email-sig/icon-twitter-24x24.png] 
> 
>
> [image: http://cdn.sencha.com/img/2016-email-sig/icon-linkedin-24x24.png] 
> 
>
> [image: http://cdn.sencha.com/img/2016-email-sig/icon-youtube-24x24.png] 
> 
>
> [image: http://cdn.sencha.com/img/2016-email-sig/icon-googleplus-24x24.png] 
> 
>
> *Winner of the SD Times 100 2015 Award* 
> 
>
>

-- 
You received this message because you are subscribed to 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/4c4b69a5-1c88-4792-be3c-3e80e02691b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

[David]

I don't seem to have access to 19.0 snapshot, but 19.0 is out. However it
does not work with gwt 2.8 beta1. So I am stuck on this since I will need
to wait for 20.0 which will be released after gwt 2.8 is released.

On Wed, 9 Dec 2015 at 17:43 Thomas Broyer  wrote:

>
>
> On Wednesday, December 9, 2015 at 5:22:28 PM UTC+1, stuckagain wrote:
>>
>> Great news!
>>
>> I tried to recompile with Java8 and GWT 2.8 beta1 a project I am working
>> on. But I see these 2 errors:
>>
>> guava-gwt 18.0 does not seem to compile:
>> [INFO]Tracing compile failure path for type
>> 'com.google.common.collect.GwtPlatform'
>> [INFO]   [ERROR] Errors in
>> 'jar:file:/C:/Users/dnouls/.m2/repository/com/google/guava/guava-gwt/18.0/guava-gwt-18.0.jar!/com/goo
>> gle/common/collect/super/com/google/common/collect/GwtPlatform.java'
>> [INFO]  [ERROR] Line 38: The method createFrom(T[], int) is
>> undefined for the type Array
>>
>>
> Known issue: https://github.com/google/guava/wiki/Release19#gwt-notes
> TL;DR: use Guava 19.0-SNAPSHOT.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/09a1cab0-b31c-4c5e-a8c5-5a0877a831c6%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/CABrJHW1hoDcSGqfD5TvB-V9QjHtjYQk2qwTb2woBBNUCBNX4jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[David]

did you post any articles about the design of your meta approach - I'm very
interested in reading a bit about it to see if I can learn from it ? I've
seen similar approaches where an XML representation was used (looking a lot
like XUL syntax), but I had to help in improving the performance and
factoring out GXT widgets with custom made ones.

On Mon, Nov 23, 2015 at 11:32 AM, CodeLess <codelessoluti...@gmail.com>
wrote:

> Good points and I agree with almost all you said ;-) We did not notice any
> performance degradation by using meta approach comparing to manual or
> UIBinder way, but that is something that we will try to demonstrate in the
> following weeks. Well, we do not have to support IE6/IE7 so this would be a
> good test, thanks for mentioning this! I will let you know when we create
> such a demo so you can take a look if you like.
>
> Let's see what will happen with Elemental2 in the following couple of
> weeks, I think Julien is working on it and if I remember well he
> said somewhere that he will have something in the following month or two.
> Anyway, I hope your fears will not come true.
>
> Cheers.
>
> On Mon, Nov 23, 2015 at 9:58 AM, David <david.no...@gmail.com> wrote:
>
>> Good points and in most cases we are covered:
>> - Using a Command Processor over GWT-RPC, but I will move it to a REST
>> implementation.
>> - GUI is split up in MVP and the important code is not depending on any
>> GWT widgets or anything else.
>>
>> We are using UiBinder in our current application, but switching to
>> something else is not something that I am afraid off. When I use UiBinder I
>> try to avoid using widgets as much as possible. So if this needs to move to
>> Angular or some other HTML based template mechanism, I don't expect a lot
>> of difficulties since it is already close to pure HTML anyway.
>>
>> Abstracting behind a meta description language for the UI that part we
>> did not do. One of the main reasons is that you lose a lot of the
>> performance benefits that GWT is offering. This optimisations mattered
>> because we needed to support older browser (IE6/IE7).
>>
>> One important component we have does this, but that one is very much
>> tuned for one specific task (editing financial messages defined through
>> XSchema's). It can not handle writing entire GUI's with rich tables, tabs,
>> splitter panels etc. But has some domain specific optimisations that are
>> not that easy to do when you need to write a complete abstraction of the UI.
>>
>> We alse have dependencies on the CellTables because they offer quite good
>> performance and we enhanced the capabilities of those cell tables to add
>> missing functionality. But the CellTables are hidden behind a factory and
>> the interactions happens against interfaces, so the client code will not
>> too much impacted either.
>>
>> What I am mostly afraid of with losing Element or Widget classes is that
>> every widget vendor will start declaring their own base classes and
>> interfaces for common functionality. This will make it hard to mix
>> components from different vendors.
>>
>> Web Components are interesting, but as usual it is too soon to go down
>> that trail. Chrome is not the most used browser in banking and enterprise
>> environments and web components on IE11 is still a mess. I tried polymer
>> but it is way too slow to scale to large GUI's at this point.
>>
>>
>> On Sun, Nov 22, 2015 at 12:19 PM, CodeLess Solutions <
>> codelessoluti...@gmail.com> wrote:
>>
>>> This is very good question and actually one of the biggest problem not
>>> only in this particular situation but also in general software development.
>>>
>>>
>>> Imagine you decide to build something large like ERP or Banking
>>> Information system for an example (with hundreds even thousands of tables
>>> and forms) You didn’t even finish it because of its complexity and one day
>>> you find out that Swing or Angular1 or Flex or “something else” come to its
>>> end of living and you are not able to switch easily to anything else?
>>>
>>>
>>> I happened to me once long time ago with some other widget library, so I
>>> am talking from the personal experience :-(
>>>
>>>
>>> I will try to explain our strategy how to solve this problem:
>>>
>>>
>>> We are using GWT and we are really enjoying to use it but:
>>>
>>>
>>> We are not using WindowBuilder (it’s not supported anymore since version
>>> GWT 2.6 and it’s also useless when you are creating large applic

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[David]

Good points and in most cases we are covered:
- Using a Command Processor over GWT-RPC, but I will move it to a REST
implementation.
- GUI is split up in MVP and the important code is not depending on any GWT
widgets or anything else.

We are using UiBinder in our current application, but switching to
something else is not something that I am afraid off. When I use UiBinder I
try to avoid using widgets as much as possible. So if this needs to move to
Angular or some other HTML based template mechanism, I don't expect a lot
of difficulties since it is already close to pure HTML anyway.

Abstracting behind a meta description language for the UI that part we did
not do. One of the main reasons is that you lose a lot of the performance
benefits that GWT is offering. This optimisations mattered because we
needed to support older browser (IE6/IE7).

One important component we have does this, but that one is very much tuned
for one specific task (editing financial messages defined through
XSchema's). It can not handle writing entire GUI's with rich tables, tabs,
splitter panels etc. But has some domain specific optimisations that are
not that easy to do when you need to write a complete abstraction of the UI.

We alse have dependencies on the CellTables because they offer quite good
performance and we enhanced the capabilities of those cell tables to add
missing functionality. But the CellTables are hidden behind a factory and
the interactions happens against interfaces, so the client code will not
too much impacted either.

What I am mostly afraid of with losing Element or Widget classes is that
every widget vendor will start declaring their own base classes and
interfaces for common functionality. This will make it hard to mix
components from different vendors.

Web Components are interesting, but as usual it is too soon to go down that
trail. Chrome is not the most used browser in banking and enterprise
environments and web components on IE11 is still a mess. I tried polymer
but it is way too slow to scale to large GUI's at this point.


On Sun, Nov 22, 2015 at 12:19 PM, CodeLess Solutions <
codelessoluti...@gmail.com> wrote:

> This is very good question and actually one of the biggest problem not
> only in this particular situation but also in general software development.
>
>
> Imagine you decide to build something large like ERP or Banking
> Information system for an example (with hundreds even thousands of tables
> and forms) You didn’t even finish it because of its complexity and one day
> you find out that Swing or Angular1 or Flex or “something else” come to its
> end of living and you are not able to switch easily to anything else?
>
>
> I happened to me once long time ago with some other widget library, so I
> am talking from the personal experience :-(
>
>
> I will try to explain our strategy how to solve this problem:
>
>
> We are using GWT and we are really enjoying to use it but:
>
>
> We are not using WindowBuilder (it’s not supported anymore since version
> GWT 2.6 and it’s also useless when you are creating large application
> because it’s to slow), not using UIBinder because it generates to much
> boilerplate that we do not need at all, not using Request Factory that
> generates who knows what, not using MVP… nothing that is too specific or
> bound too much for the platform. The only thing that we use and is specific
> is Code Splitting but it’s totally hidden from developers and done
> automatically for each controller. We are not using any external library to
> do this. It’s simple to implement and it would be probably easy to replace
> it with something else tomorrow. Everything is done with a single
> annotation.
>
>
> GWT-RPC may also disappear? We are using JPA classes (with Hibernate) but
> we don’t use DTOs because there is simply no need to pack and unpack
> everything. We do not write code for every document we need to save
> (create, update, delete), there is only ONE class that is doing the job via
> GWT-RPC. Exceptions are rare (less than 10%) that you have to do something
> special while persisting the document and you are able to do that as a
> custom business logic that executes in the same transaction. Current
> implementation is GWT-RPC based, but when we decide to change this, it can
> be done in a single day (probably in couple of hours) because its’ ONE
> class and not hundreds/thousands of classes that we have to change. We are
> not afraid of changes when someone decide to stop supporting GWT-RPC or
> it’s suddenly surprisingly proven that it is prone to vulnerabilities. We
> have less than 10 services to change and note that we are dealing with >650
> forms/JPA classes in this moment. All custom actions go via ONE custom
> action service, we do not create 100 services because it is used in 100
> controllers.
>
>
> About UI: We are using something that I call “meta description approach”
> for UI. Describe you fields, views and forms on technology agnostic way
> 

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[David]

Thanks for all the feedback. But it does not put my mind at rest right now.

It would have been much better if GWT 2.8 would have provided at least the
basis for the future of GUI development - because that was one of its main
selling points for me.

I understand why element/widget/uibinder are going away, but right now
there is no low-level alternative that would allow a less painful migration
later on.

I am not expecting a 100% backward compatibility with 3.0, but at least
some certainty that the code rewrites will be limited or easy, if we
restrain from using certain technologies. The only certainty we have right
now is that GWT 3.0 will compile Java into JavaScript, and all the rest
will change or will just disappear assuming that there will be 3rd party
extensions.

If GWT does not offer a basis for widget and UI development then there will
be multiple incompatible GUI libraries or frameworks that will make it
difficult to mix.

I could take the approach of JsInterop with AngularJS, but Angular 2,x is
also not going to offer backward compatibility. So I solve one problem and
end up with another one.

I guess I will be trying UiBinder with GQuery and not rely on Widget for my
project. The UiBinder might disappear, but we are using mostly plain HTML
and Bootstrap styles. So we are only interested in binding events. The
UiBinder templates will be easy to migrate later on.

Any idea what is going on with Singular ? Is it also abandoned or will it
finally appear after GWT 2.8 is final ?


On Mon, Nov 16, 2015 at 12:10 PM, Alain Ekambi 
wrote:

> Well the hope is that someone will step in and port existing js libraries
> to gwt 3 or create new one ? See vaadin sencha etc .. We will def port our
> ext js wrapper to gwt3
> On 16 Nov 2015 11:29, "Robert Stone"  wrote:
>
>>
>>
>> On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote:
>>>
>>>
>>> My worry about "just pick a mainstream JS framework and use it via
>>> JSInterop" is that if you're a) coupled to a JS environment for unit
>>> testing and b) interfacing with a framework that is inherently
>>> dynamic/untyped, what's the benefit of using GWT in the first place?
>>>
>>
>>
>> And this for me sums up GWTs main issues going forward. The benefit
>> before was that existing Java devs could use GWT to work on all the layers
>> of an application. GWT 3 will force (not a bad thing) Java devs to use
>> JavaScript for their views and will also force them to deal with
>> integrating JS and Java code. At this point, you have to ask 'Why bother
>> with Java/GWT at all' - switch the full application to pure JS.
>>
>> For existing large projects, switching to GWT 3 is almost a non-starter
>> as there will be far too much existing view code to convert over so they
>> will have to stick with the GWT 2 stream and hope that it remains well
>> supported. This is the situation my company face with one of our products.
>>
>> So GWT 3 is not ideal for new projects and doesn't help with existing
>> projects. Where is it's market?
>>
>> --
>> You received this message because you are subscribed to 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/342561ff-64da-4e7a-aec4-6e9b84846f09%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/CAGw%3D_ty7rjFQmUZhYv95aQBj8KgwSKcGk0nEyUkdTd4upBNtdA%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/CABrJHW2uZjj_BAdr8WZJCN%2BQX_p91zvUxE%2BTMBa%3DZpjijaDRyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[David]

Daniel,

Thanks for the background info.

In my applications (non public web apps for banking purposes)  I tend to
use GIN, Guava, UiBinder + Widgets + GWT-RPC.

- GWT-RPC has been a limitation (I filled several issues in the passed) and
I was looking for a REST/JSON replacement but it was not available at the
time (now it is). So I can already move away from GWT-RPC.
- UiBinder is really fundamental, but if we need to switch to pure HTML
then it should not be that hard to do, UiBinder files are already 80% pure
HTML anyway. CssResources and such might be a bit more work... we were
planning to move to GssResources ... will those remain ? probably not...
- Widgets ... by switching to GQuery we can avoid widgets for most cases
(although I will have a dependency on Element. But here again, I am sure
there will be a replacement for Element using Elemental (and hopefully a
GQuery update to moves to something else ?)
- CellWidgets. We depend and enhance the various cellWidgets a lot (adding
resizing, filtering, dynamic loading, custom generators to generate the
columns, ...). These will be hard to replace at this point (I do like the
Vaadin Grid ... who knows).

Is Singular planned to be a replacement for UiBinder or is it too early to
ask that question ?

Greets,
David


On Mon, Jun 15, 2015 at 11:05 AM James Horsley james.hors...@gmail.com
wrote:

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

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

[David]

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. Everything that made
it a tooltip will be scrapped.




On Sun, Jun 14, 2015 at 8:22 AM, Matic Petek maticpe...@gmail.com wrote:

 Hi,
  I'm also frustrated about which technologies to use on new GWT projects
 (see
 https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/_QSayBAmeX8
 ).
 But when it comes about the name, GWT should stay. The basic idea around
 GWT is writing code in Java which is then recompile (or whatever you call
 it / do it) into JavaScript. And this idea will stick with new GWT 3.0 (it
 was also very clearly emphasis is one of the talks), so the name should
 stay.
 Regards,
   Matic


 On Saturday, June 13, 2015 at 11:03:08 AM UTC+2, Paul Robinson wrote:

 The GWT Meetup 2015 videos are very interesting.


 I can see why the proposals for GWT 3.0 have been made. However, we
 should be clear about the fact that GWT 3.0 is not just going to break a
 few little things that can easily be fixed, but break things to the point
 that it's a completely different product and there will be lots of GWT
 applications that will never be ported to the new system.


 It will be confusing to all GWT users to continue to use the name GWT
 3.0. It would be much better to use a new name for the new system and treat
 it as what it is: a new idea about how Java can be used to build modern web
 applications.


 The situation we have now is that GWT will end at 2.8 and a new thing,
 that is currently vapourware, will be coming that people are expected to
 use. There's going to be a lot of confusion and those using GWT now, as
 well as those that will use the new thing when it does exist, will all be
 served much better if everybody stops calling the new thing GWT.


 Paul


  --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/43ceb941-d8cc-496f-bab3-ab8219c120bf%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/43ceb941-d8cc-496f-bab3-ab8219c120bf%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/CABrJHW0HrjzhwAmGGsSNqzD5YFrPySE7wn%2B_Sp%3Dk-Z1a9ExiMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Write access to GWT_TOOLS subversion repository

[david . ostrovsky]

What is the policy for write access to GWT_TOOLS subversion repository?

I would like to upload new artifacts needed to verify Jetty 9 and HtmlUnit
2.16 upgrade change [1]. Can someone grant me write access or upload
needed artifacts so that Gerrit verification can succeed?

Thanks.

[1] https://gwt-review.googlesource.com/7857

-- 
You received this message because you are subscribed to 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/03d3cda4-40af-4e0e-8c41-b9847ee9344c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Superdev and Jetty 9

[david . ostrovsky]

Am Freitag, 19. Dezember 2014 10:48:05 UTC+1 schrieb david.o...@gmail.com:


 Am Montag, 15. Dezember 2014 14:45:11 UTC+1 schrieb Michael Vogt:

 Hello. 

 Any work going on to solve 
 https://gwt-review.googlesource.com/#/c/7856/  
 https://gwt-review.googlesource.com/#/c/7856/ 


 Unfortunately not. I tried different approaches, but they all failed, 
 because GWT depends on Jetty 8.


I filed this issue for HtmlUnit project as it is the root cause for why GWT 
cannot switch to Jetty 9 atm: [1].

[1] https://sourceforge.net/p/htmlunit/bugs/1656/

-- 
You received this message because you are subscribed to 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/3c48aa02-1caa-44d8-b044-19100cbd1933%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Superdev and Jetty 9

[david . ostrovsky]

Am Montag, 15. Dezember 2014 14:45:11 UTC+1 schrieb Michael Vogt:

 Hello. 

 Any work going on to solve 
 https://gwt-review.googlesource.com/#/c/7856/  
 https://gwt-review.googlesource.com/#/c/7856/ 


Unfortunately not. I tried different approaches, but they all failed, 
because GWT depends on Jetty 8.
The most promising approach was to not package Jetty in gwt-dev at all, and 
maintain two different
codeserver versions targeting Jetty 8  Jetty 9. And by not shipping asm 
library in gwt-dev.jar in 2.7
was steps in the same direction. While viable option, this approach was 
abandoned, after codeserver
itself was shipped in gwt-dev.jar.

While all straight forward ways to get GWT + SDM + Jetty9 up and running 
failed, there is a hack:

1. strip outdated Jetty 8 from gwt-dev.jar
2. add dependency to Jetty 9
3. replace one source file from codeserver with this version [1]

See these changes for glory details [2], [3].

[1] 
https://gerrit.googlesource.com/gerrit/+/master/gerrit-gwtdebug/src/main/java/com/google/gwt/dev/codeserver/WebServer.java
[2] https://gerrit-review.googlesource.com/57642
[3] https://gerrit-review.googlesource.com/59354

-- 
You received this message because you are subscribed to 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/b6a15c6c-47ef-47dd-b70e-75711c75b633%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] SuperDevMode sometimes puts member fields in __proto__ why is that ?

[David]

In my case it is a boolean, but not final, the value does change. Is there
an optimisation that removes the field when it is false ?

On Fri, Dec 5, 2014 at 6:41 PM, 'Roberto Lublinerman' via GWT Contributors 
google-web-toolkit-contributors@googlegroups.com wrote:

 Yes,I meant (instance) final fields of primitive or string type
 initialized at declaration.

 Compile time constants are propagated by the compiler in draft and
 optimized mode.



 On Fri, Dec 5, 2014 at 8:49 AM, 'Ray Cromwell' via GWT Contributors 
 google-web-toolkit-contributors@googlegroups.com wrote:

 Static final fields on the prototype? I'm pretty sure these are
 promoted to global in optimized mode. Perhaps you meant final
 non-static fields? (which we should have an optimization for promoting
 to static :) )


 On Fri, Dec 5, 2014 at 7:29 AM, 'Roberto Lublinerman' via GWT
 Contributors google-web-toolkit-contributors@googlegroups.com wrote:
  In draft compile Java compile time constants are emitted in the
 prototype.
  This should be exactly static final fields of primitive or string type
  assigned at declaration.
 
  This is the approach to compile time constants taken to implement Java
  semantics.
 
  FWIW in optimized compiles other fields might be upgraded to compile
 time
  constants.
 
  On Dec 5, 2014 2:18 AM, stuckagain david.no...@gmail.com wrote:
 
  I've been trying out GWT 2.7 and SuperDevMode in combination with the
 SDBG
  eclipse plugin.
 
  In the Chrome debugger I noticed that some fields are sometimes
 available
  under 'this' but sometimes they are available only in 'this.__proto__'.
  It seems that if I have a boolean field that is set to false that it
 does
  not appear in 'this' but under 'this.__proto__' and that I can not see
 it at
  all in the SDBG plugin. I filed a bug report on SDBG, but I am trying
 to
  figure out how this works in GWT SuperDevMode.
 
  Another thing that takes getting used: list/map structures are not that
  easy to navigate anymore. I hope they found some way to make it easier
 to
  have some support to convert them to something readable in the
 debugger.
 
 
  --
  You received this message because you are subscribed to 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/d948f131-0da7-4e9a-998a-925e68a62ced%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/CAC7T7gnmswu4mF_7SRPnZjQYjvykkTvgnnthPDfuFy5gpGamcQ%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/CAPVRV7eTkVStPGXrtfiPk5kO8yr2gyjQCZY4xkAD5ufExWB_6g%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/CAC7T7gnaifVU5UEa7mU41UuRcEZvwp-NWv_6v5pHsq4Na%3D8uuQ%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gnaifVU5UEa7mU41UuRcEZvwp-NWv_6v5pHsq4Na%3D8uuQ%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/CABrJHW1-qd9Cuq3bktppFqnQEykA0xiXFCmFeNJWf1W0d-_XYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

[David]

Hi Rob,

I'm using Jboss Fuse which uses Felix and it works fine in SuperDevMode.
But did I read it right that you start the osgi container embedded with
superdevmode ? I would love to know how I can achieve that as well because
then I don't need to use the -noserver parameter anymore.

I am using the bookmarklets to force a compile and enforce superdevmode
with the remote server. That works just fine for me.

On Fri, Dec 5, 2014 at 10:42 AM, Rob Walker piste.shred...@googlemail.com
wrote:

 Sadly the -launcherDir won't work for us I don't think - we're running an
 embedded Felix/OSGi server which serves up our application from bundle
 JARS. So there is no dir we can point them at.

 As per thread below, I think I am making progress with Dev Mode launch
 though - at least it is actually launching now anyhow. Seemed to need quite
 a few command line mods from our original BAT file to launch Dev Mode

 On Friday, 5 December 2014 11:31:55 UTC+2, Thomas Broyer wrote:



 On Friday, December 5, 2014 10:00:59 AM UTC+1, Rob Walker wrote:

 I'm really not surprise people are hitting this issue. It's not clear
 (or wasn't to me) from the Release Notes that you no longer run Super Dev
 Mode from the standalone program in 2.7 as was done in 2.6, but that
 running via Dev Mode enables it.


 …or you can keep your launcher with CodeServer but add a -launcherDir
 argument pointing to the folder your standalone server is serving.
 CodeServer will then generate a .nocache.js in there that enables compile
 on load.

 And yes the docs need an update (and I wasn't even aware of the issue
 with the bookmarklets; good to know, and I believe we should try to fix it
 because it can be really handy)

  --
 You received this message because you are subscribed to 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/1d9b9b6e-07f1-4c35-96d6-bdc3aa471267%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/1d9b9b6e-07f1-4c35-96d6-bdc3aa471267%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/CABrJHW1bvqdnq2p%3D1X%3DrQw43S5%2BSH27USnFE3vM0fcr3M0RT-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Question to Windows users

[David]

On Mon, Oct 20, 2014 at 11:47 AM, Thomas Broyer t.bro...@gmail.com wrote:


 and you need to follow the steps very carefully (and hopefully no
 dependency has been changed since the document was written).


 I'm curious, which dependencies are you talking about?


In my case it was the checkstyle plugin for eclipse that was not compatible
with a newer eclipse version. But I gave up shortly afterwards.





 What we do (in an enterprise environment) is to just have a zip or
 machine image ready to be installed on a new machine. After 30 minutes or
 so a new developer is ready to code.


 In an Enterprise environment, you want to control the development
 environment so you don't give many choices to the developers.


We always have some rogue developers who use vi or IntelliJ, but indeed we
can be very enforcing on what developers have to use. On the other hand,
requiring a VM for development is also a very heavy requirement. I've had
to do such things on a Linux box (with windows in a virtual box) but that
kept on breaking with every update of the linux kernel. But I am not an
Linux expert. I stopped using it a very long time ago (95 or so)


 Here, we want to support different IDEs, we don't want to force you to use
 Eclipse or IntelliJ IDEA or whatever other IDE. Maintaining those ZIPs or
 images is also going to be a hassle I believe.
 I would like to have scripts to help setup the environment, and maybe we
 could have a script that downloads and configure Eclipse for instance (I
 doubt it though); we should have a script to setup the Gerrit commit-msg
 hook without the


Well one nice tool (from Google if I am not mistaken) is to use the
workspace mechanic. We use that mostly to keep all our eclipse
installations inline with our rules. Maybe that is an idea to make it
easier.


 need for the contributor to think about it (just run setup.sh or
 setup.bat and it does the right thing; I fear it wouldn't be that easy on
 Windows though; on Linux, where every tool is an apt-get or yum call away,
 things are much easier, not to mention that distributions come with many
 tools pre-installed: I think every distro comes with Python pre-installed
 because it's needed by other tools already, it might also be the case on OS
 X; but everything seems complicated on Windows, with installers that you
 need to go look for, download, run, answer the questions –i.e. click next
 and OK– then reboot the machine if you're unlucky; n ow maybe I'm overly
 pessimistic and the needed tools come bundled with Git for Windows, but I
 know some people won't even install that and instead use the JGit
 integrated within their IDE – and that won't work for us because IIRC JGit
 doesn't run git hooks).


I recently had to customize Bootstrap.css to be used in GWT (without GWT
wrappers) and that was really a painful process. It was nearly impossible
to get it working in the enterprise environment. I finally did it on my Mac
at home. But I really hate the fact that nowadays everything seems to be
using their own build systems. Sure ant is crappy and even maven is not
great in many ways ... but boy I was surprised at how many newer things are
available. Always new commands to learn, waste of memory cycles and
confusion when switching between projects.

Anyway, you guys asked for some feedback, there you have it from my point
of view, feel free to do with it what you like :-)

-- 
You received this message because you are subscribed to 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/CABrJHW0%2BV8i%3DC2_YK9kwK7bBd36vvziyjVmb2BnGB6nLNNoBxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Question to Windows users

[David]

Sounds like a hasle to require a VM... unless that VM would include
everything to get started.

Just setting up eclipse to be inline with the coding guidelines in GWT and
setting up all the libraries etc are really painful and you need to follow
the steps very carefully (and hopefully no dependency has been changed
since the document was written).

What we do (in an enterprise environment) is to just have a zip or machine
image ready to be installed on a new machine. After 30 minutes or so a new
developer is ready to code.


On Sat, Oct 18, 2014 at 7:25 PM, Brandon Donnelson branflake2...@gmail.com
wrote:

 Setting up an images seems ideal to me to get going with less steps.


 On Friday, October 17, 2014 3:04:05 PM UTC-7, Thomas Broyer wrote:



 On Friday, October 17, 2014 5:11:10 PM UTC+2, Rene Hangstrup Møller wrote:

 I am just going to repeat my reply from google+ here:

 If you want to encourage contributions from the community, you should
 work on lowering the barriers to entry. Pick standard tools that work on a
 variety of platforms.

 What went wrong with the conversion to gradle?


 Nothing went wrong, but handling external dependencies still requires
 that you svn co and svn up the gwt-tools repo, and Gradle will most
 likely impact how we'd later modularize GWT (not necessarily a bad thing,
 but something to be aware of).
 I'll make a comparison matrix of Gradle vs. Buck vs. Pants when I find
 time.


 Why do you need some obscure build system where first sentence on the
 install page is As of September 2014, alas, Pants is not something you can
 just install and use.


 It also says that “Once it’s set up, most folks should be able to use the 
 Pants
 Conceptual Overview https://pantsbuild.github.io/first_concepts.html
 and not worry about these things.”, i.e. “pants goal idea” or “pants goal
 eclipse” to setup your IDE, “pants goal jar” and “pants goal test” for
 everyday use, “pants goal publish” or “pants goal bundle” to build GWT in
 order to use it in your projects (deploy it in a Maven repo, or create a
 ZIP with all needed JARs)
 Note: I haven't tried Pants yet, so this is all from the docs.
 Existing repositories seem to have a bunch of scripts in them so you can
 just “git clone” and run “./pants” and Pants will download itself, just
 like Gradle with ./gradlew. And BUILD files are easy to read and
 self-explanatory.

  --
 You received this message because you are subscribed to 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/5f8f2899-82a2-4b06-aca3-9f2554546d3c%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/5f8f2899-82a2-4b06-aca3-9f2554546d3c%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/CABrJHW3eNQEA5Ne9JY4w4AbvqDUvXWS%3D%2B0L-8k%3D%3DxuThaXPxXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.7 requiring Java7 for development - Action needed

[David]

No problem, we are on Java 7 for quite some time. I would not even object
to Java 8 for the client side only, but I guess that can wait for 3.0.
GWT/GUI development is really screaming for lambda's with all the event
handling and async callbacks.

On Fri, Sep 12, 2014 at 6:23 AM, Mohammed sameen@gmail.com wrote:

 I think its fine we require Java 7 for GWT 2.7

 On Thursday, September 11, 2014 11:20:53 PM UTC+5:30, Daniel Kurka wrote:

 Hi all,

 while bringing GSS support into GWT, I discovered that the closure
 styleheets compiler actually requires Java7.
 This means that we either have to do a back port of the compiler (I
 haven't looked at it seriously) or require Java7 for development with GWT
 (probably only if you are using CssResource).

 I really like your input on this and if I do not hear any strong
 objections, I will go ahead with using the Java7 version of closure
 stylesheets and thus we will require Java7 for GWT development.

 Note: This does not impact deployment of any GWT apps. You can still run
 a GWT app on a Java6 container, this will only affect developers on their
 machines.

 -Daniel

  --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/904f4a86-630c-4d15-bf39-3b146f3db462%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/904f4a86-630c-4d15-bf39-3b146f3db462%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/CABrJHW2mx%3DbAv%3DFbhg-HkZfydFVTJgXcPLSfaPd-%2BooPKfYeBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Bad link in GWT Documentation

[David]

It was in the main navigation panel. But as of this morning (GMT+1)  it
works fine. So I guess it had something to do with caching ?



On Wed, Jun 11, 2014 at 6:01 PM, Thomas Broyer t.bro...@gmail.com wrote:

 Hmm, which link? (on which page)

 (there used to be such a bug, but it was fixed a few weeks ago; maybe
 there's a leftover somewhere)

 On Wednesday, June 11, 2014 3:58:43 PM UTC+2, stuckagain wrote:

 The link to the documentation on Editors is broken.
 It points to: http://www.gwtproject.org/doc/latest/doc/latest/
 DevGuideUiEditors.html
 iso http://www.gwtproject.org/doc/latest/DevGuideUiEditors.html


  --
 You received this message because you are subscribed to 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/ffd7a0e6-eb17-4b31-b372-886f3d18e3ea%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/ffd7a0e6-eb17-4b31-b372-886f3d18e3ea%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/CABrJHW3mTSkEfJwqOHA8i-5a6bsADug_ma_2X1XtLPXkBVr0Ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Emma or JaCoCo support needs some attention

[David]

John,

I try to stick to a MVP design as much as possible even for widgets. But in
some cases I need to create a GWTTestCase for testing event handling or
event widget construction (to see if the right styles or dom structure is
created). Unfortunately that is a slow process and it does not help much
that I don't see coverage reports for those tests (combined with all the
rest of my coverage data).

David


On Tue, May 20, 2014 at 10:54 PM, John A. Tamplin j...@jaet.org wrote:

 On Tue, May 20, 2014 at 1:12 PM, David david.no...@gmail.com wrote:

 No I did not try that one. I tried GWT Mockito which looked promising and
 I actually managed to test a few widgets until someone added CssResources
 and other GWT features and then GWTMockito just exploded with a generic
 error that I should try disabling the classloading cache.

 I am using GIN and I never do a GWT.create directly (GIN does that for
 you). That helps a lot in testing the higher level classes like Activities.
 But it does not really help with widgets. (We have some customisations on
 top of the DataGrid and CellTable and it does not look possible to automate
 the testing of those.


 It isn't clear how much you can do widget tests on the server anyway --
 the only way I see it would be useful is widgets that clearly delineate the
 view from the rest of it, and allow you to test the model/controller.

 If you are talking about testing your own code, then likewise you don't
 test the view on the server.

 --
 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/CAM5k6X9yC%2BSbkdPWwQL6aazdKLDhm3cdHwmUB%2BcZf03vAyKrqQ%40mail.gmail.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X9yC%2BSbkdPWwQL6aazdKLDhm3cdHwmUB%2BcZf03vAyKrqQ%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/CABrJHW0hG3wYVLWgRA0WiZ3Jp9Tj_s-DRxvVnUcmpRPdEKcDHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Emma or JaCoCo support needs some attention

[David]

Hi Jonathan,

Thanks for the pointer, I will certainly look into this.

David


On Tue, May 20, 2014 at 10:46 PM, Jonathan Fuerth fue...@fuerth.ca wrote:

 Hey David,

 Christian Sadilek and I found a working solution to the GWTTestCase vs
 JaCoCo problem. Of course, it doesn't make GWTTestCase any faster, but it
 does give you correct coverage reporting for your test cases.

 Instructions are here:

 https://github.com/errai/jacoco-gwt-maven-plugin

 Don't let the project's short/old history fool you; this project isn't
 dead, it's just been working for us and hasn't needed any changes in 2+
 years.

 Let us know if you run into any problems with it!

 -Jonathan


 On Tue, May 20, 2014 at 1:12 PM, David david.no...@gmail.com wrote:

 Hi Nicolas,

 No I did not try that one. I tried GWT Mockito which looked promising and
 I actually managed to test a few widgets until someone added CssResources
 and other GWT features and then GWTMockito just exploded with a generic
 error that I should try disabling the classloading cache.

 I am using GIN and I never do a GWT.create directly (GIN does that for
 you). That helps a lot in testing the higher level classes like Activities.
 But it does not really help with widgets. (We have some customisations on
 top of the DataGrid and CellTable and it does not look possible to automate
 the testing of those.

 And using GWTTestCases is really painful especially since we can't even
 proof that we are doing decent code coverage in our tests.

 David



 On Tue, May 20, 2014 at 6:19 PM, Nicolas Wetzel wetz...@gmail.comwrote:

 HI !

 did you try gwt-test-utils ?
 it's a very good tool for testing widgets and more without GWTTestCase.




 2014-04-11 21:11 GMT+02:00 David david.no...@gmail.com:

 Any plans to improve unit testing abilities so that we might be able to
 do more unittesting without using GWTTestCase ?

 I've been trying out gwtmockito as an alternative and it is great, but
 for unit testing widgets it has many limitations.

 Sure I am using MVP for the main application logic. But custom widgets
 are hard to implement and even harder to test the way it currently is.

 I think with a little help of GWT changes that maybe it could become
 easier to inject mocks in the right place instead of using class rewriting
 and other nasty tricks like gwtmockito is doing.

 For many things having some server side fake for GWT.create would
 already help a lot (for things like CssResources or Messages it is rather
 easy to just use some dynamic proxy to fake what you normally generate for
 the client. Maybe some basic working DOM class would be great as wel,
 because then most widgets could just be created without much problems.

 Only the JSNI stuff remains a problem, but maybe if the great ideas of
 JsInterop and such might make if feasible to even find a solution there ?
 Or at least putting them in a separate class and using an interface in the
 widgets to make them mockable for test purposes would be great.

 One thing that would make GWT a lot easier to mock for testing purpose
 is if it would embrace an injection framework like GIN or as done in JBoss
 Errai. You can basically get rid of all the GWT.create invocations and
 start using @Inject so that we can replace them with either a generated
 class or a mocked class.

 David



 On Fri, Apr 11, 2014 at 8:08 PM, Goktug Gokdogan gok...@google.comwrote:

 Emma (which is already broken for some cases) is going to go away with
 dev mode. We have been talking about js based alternative but I'm not sure
 when that will be ready.


 On Fri, Apr 11, 2014 at 6:44 AM, David david.no...@gmail.com wrote:

 No feedback from the GWT developers ?


 On Mon, Apr 7, 2014 at 3:09 PM, stuckagain david.no...@gmail.comwrote:

 What is the state for supporting Emma with GWTTestCase ?

 I see that the documentation still refers to a very old version of
 Emma (and EclEmma).
 How can we use JaCoCo to do automated testing with code coverage
 with GWT TestCase ?

 What will happen when moving to Java 8 ? I guess that the old Emma
 as referred to in the documentation will have a problem with this (does 
 it
 even support full Java 7 syntax ?)

 Will GWTTestCase support remain once DevMode goes away ? or do I
 understand that wrongly ?





 --
 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/d/optout.


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

Re: [gwt-contrib] Emma or JaCoCo support needs some attention

[David]

One question: how do I use this on projects that do not use maven ?



On Tue, May 20, 2014 at 10:46 PM, Jonathan Fuerth fue...@fuerth.ca wrote:

 Hey David,

 Christian Sadilek and I found a working solution to the GWTTestCase vs
 JaCoCo problem. Of course, it doesn't make GWTTestCase any faster, but it
 does give you correct coverage reporting for your test cases.

 Instructions are here:

 https://github.com/errai/jacoco-gwt-maven-plugin

 Don't let the project's short/old history fool you; this project isn't
 dead, it's just been working for us and hasn't needed any changes in 2+
 years.

 Let us know if you run into any problems with it!

 -Jonathan


 On Tue, May 20, 2014 at 1:12 PM, David david.no...@gmail.com wrote:

 Hi Nicolas,

 No I did not try that one. I tried GWT Mockito which looked promising and
 I actually managed to test a few widgets until someone added CssResources
 and other GWT features and then GWTMockito just exploded with a generic
 error that I should try disabling the classloading cache.

 I am using GIN and I never do a GWT.create directly (GIN does that for
 you). That helps a lot in testing the higher level classes like Activities.
 But it does not really help with widgets. (We have some customisations on
 top of the DataGrid and CellTable and it does not look possible to automate
 the testing of those.

 And using GWTTestCases is really painful especially since we can't even
 proof that we are doing decent code coverage in our tests.

 David



 On Tue, May 20, 2014 at 6:19 PM, Nicolas Wetzel wetz...@gmail.comwrote:

 HI !

 did you try gwt-test-utils ?
 it's a very good tool for testing widgets and more without GWTTestCase.




 2014-04-11 21:11 GMT+02:00 David david.no...@gmail.com:

 Any plans to improve unit testing abilities so that we might be able to
 do more unittesting without using GWTTestCase ?

 I've been trying out gwtmockito as an alternative and it is great, but
 for unit testing widgets it has many limitations.

 Sure I am using MVP for the main application logic. But custom widgets
 are hard to implement and even harder to test the way it currently is.

 I think with a little help of GWT changes that maybe it could become
 easier to inject mocks in the right place instead of using class rewriting
 and other nasty tricks like gwtmockito is doing.

 For many things having some server side fake for GWT.create would
 already help a lot (for things like CssResources or Messages it is rather
 easy to just use some dynamic proxy to fake what you normally generate for
 the client. Maybe some basic working DOM class would be great as wel,
 because then most widgets could just be created without much problems.

 Only the JSNI stuff remains a problem, but maybe if the great ideas of
 JsInterop and such might make if feasible to even find a solution there ?
 Or at least putting them in a separate class and using an interface in the
 widgets to make them mockable for test purposes would be great.

 One thing that would make GWT a lot easier to mock for testing purpose
 is if it would embrace an injection framework like GIN or as done in JBoss
 Errai. You can basically get rid of all the GWT.create invocations and
 start using @Inject so that we can replace them with either a generated
 class or a mocked class.

 David



 On Fri, Apr 11, 2014 at 8:08 PM, Goktug Gokdogan gok...@google.comwrote:

 Emma (which is already broken for some cases) is going to go away with
 dev mode. We have been talking about js based alternative but I'm not sure
 when that will be ready.


 On Fri, Apr 11, 2014 at 6:44 AM, David david.no...@gmail.com wrote:

 No feedback from the GWT developers ?


 On Mon, Apr 7, 2014 at 3:09 PM, stuckagain david.no...@gmail.comwrote:

 What is the state for supporting Emma with GWTTestCase ?

 I see that the documentation still refers to a very old version of
 Emma (and EclEmma).
 How can we use JaCoCo to do automated testing with code coverage
 with GWT TestCase ?

 What will happen when moving to Java 8 ? I guess that the old Emma
 as referred to in the documentation will have a problem with this (does 
 it
 even support full Java 7 syntax ?)

 Will GWTTestCase support remain once DevMode goes away ? or do I
 understand that wrongly ?





 --
 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/d/optout.


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

Re: [gwt-contrib] Emma or JaCoCo support needs some attention

[David]

Hi Nicolas,

No I did not try that one. I tried GWT Mockito which looked promising and I
actually managed to test a few widgets until someone added CssResources and
other GWT features and then GWTMockito just exploded with a generic error
that I should try disabling the classloading cache.

I am using GIN and I never do a GWT.create directly (GIN does that for
you). That helps a lot in testing the higher level classes like Activities.
But it does not really help with widgets. (We have some customisations on
top of the DataGrid and CellTable and it does not look possible to automate
the testing of those.

And using GWTTestCases is really painful especially since we can't even
proof that we are doing decent code coverage in our tests.

David



On Tue, May 20, 2014 at 6:19 PM, Nicolas Wetzel wetz...@gmail.com wrote:

 HI !

 did you try gwt-test-utils ?
 it's a very good tool for testing widgets and more without GWTTestCase.




 2014-04-11 21:11 GMT+02:00 David david.no...@gmail.com:

 Any plans to improve unit testing abilities so that we might be able to
 do more unittesting without using GWTTestCase ?

 I've been trying out gwtmockito as an alternative and it is great, but
 for unit testing widgets it has many limitations.

 Sure I am using MVP for the main application logic. But custom widgets
 are hard to implement and even harder to test the way it currently is.

 I think with a little help of GWT changes that maybe it could become
 easier to inject mocks in the right place instead of using class rewriting
 and other nasty tricks like gwtmockito is doing.

 For many things having some server side fake for GWT.create would already
 help a lot (for things like CssResources or Messages it is rather easy to
 just use some dynamic proxy to fake what you normally generate for the
 client. Maybe some basic working DOM class would be great as wel, because
 then most widgets could just be created without much problems.

 Only the JSNI stuff remains a problem, but maybe if the great ideas of
 JsInterop and such might make if feasible to even find a solution there ?
 Or at least putting them in a separate class and using an interface in the
 widgets to make them mockable for test purposes would be great.

 One thing that would make GWT a lot easier to mock for testing purpose is
 if it would embrace an injection framework like GIN or as done in JBoss
 Errai. You can basically get rid of all the GWT.create invocations and
 start using @Inject so that we can replace them with either a generated
 class or a mocked class.

 David



 On Fri, Apr 11, 2014 at 8:08 PM, Goktug Gokdogan gok...@google.comwrote:

 Emma (which is already broken for some cases) is going to go away with
 dev mode. We have been talking about js based alternative but I'm not sure
 when that will be ready.


 On Fri, Apr 11, 2014 at 6:44 AM, David david.no...@gmail.com wrote:

 No feedback from the GWT developers ?


 On Mon, Apr 7, 2014 at 3:09 PM, stuckagain david.no...@gmail.comwrote:

 What is the state for supporting Emma with GWTTestCase ?

 I see that the documentation still refers to a very old version of
 Emma (and EclEmma).
 How can we use JaCoCo to do automated testing with code coverage with
 GWT TestCase ?

 What will happen when moving to Java 8 ? I guess that the old Emma as
 referred to in the documentation will have a problem with this (does it
 even support full Java 7 syntax ?)

 Will GWTTestCase support remain once DevMode goes away ? or do I
 understand that wrongly ?





 --
 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/d/optout.


  --
 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/d/optout.


  --
 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/d/optout.


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

Re: [gwt-contrib] Emma or JaCoCo support needs some attention

[David]

No feedback from the GWT developers ?


On Mon, Apr 7, 2014 at 3:09 PM, stuckagain david.no...@gmail.com wrote:

 What is the state for supporting Emma with GWTTestCase ?

 I see that the documentation still refers to a very old version of Emma
 (and EclEmma).
 How can we use JaCoCo to do automated testing with code coverage with GWT
 TestCase ?

 What will happen when moving to Java 8 ? I guess that the old Emma as
 referred to in the documentation will have a problem with this (does it
 even support full Java 7 syntax ?)

 Will GWTTestCase support remain once DevMode goes away ? or do I
 understand that wrongly ?





 --
 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/d/optout.


-- 
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/d/optout.

Re: [gwt-contrib] Emma or JaCoCo support needs some attention

[David]

Any plans to improve unit testing abilities so that we might be able to do
more unittesting without using GWTTestCase ?

I've been trying out gwtmockito as an alternative and it is great, but for
unit testing widgets it has many limitations.

Sure I am using MVP for the main application logic. But custom widgets are
hard to implement and even harder to test the way it currently is.

I think with a little help of GWT changes that maybe it could become easier
to inject mocks in the right place instead of using class rewriting and
other nasty tricks like gwtmockito is doing.

For many things having some server side fake for GWT.create would already
help a lot (for things like CssResources or Messages it is rather easy to
just use some dynamic proxy to fake what you normally generate for the
client. Maybe some basic working DOM class would be great as wel, because
then most widgets could just be created without much problems.

Only the JSNI stuff remains a problem, but maybe if the great ideas of
JsInterop and such might make if feasible to even find a solution there ?
Or at least putting them in a separate class and using an interface in the
widgets to make them mockable for test purposes would be great.

One thing that would make GWT a lot easier to mock for testing purpose is
if it would embrace an injection framework like GIN or as done in JBoss
Errai. You can basically get rid of all the GWT.create invocations and
start using @Inject so that we can replace them with either a generated
class or a mocked class.

David



On Fri, Apr 11, 2014 at 8:08 PM, Goktug Gokdogan gok...@google.com wrote:

 Emma (which is already broken for some cases) is going to go away with dev
 mode. We have been talking about js based alternative but I'm not sure when
 that will be ready.


 On Fri, Apr 11, 2014 at 6:44 AM, David david.no...@gmail.com wrote:

 No feedback from the GWT developers ?


 On Mon, Apr 7, 2014 at 3:09 PM, stuckagain david.no...@gmail.com wrote:

 What is the state for supporting Emma with GWTTestCase ?

 I see that the documentation still refers to a very old version of Emma
 (and EclEmma).
 How can we use JaCoCo to do automated testing with code coverage with
 GWT TestCase ?

 What will happen when moving to Java 8 ? I guess that the old Emma as
 referred to in the documentation will have a problem with this (does it
 even support full Java 7 syntax ?)

 Will GWTTestCase support remain once DevMode goes away ? or do I
 understand that wrongly ?





 --
 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/d/optout.


  --
 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/d/optout.


  --
 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/d/optout.


-- 
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/d/optout.

Re: [gwt-contrib] Issue 8083, needs some input from GWT team

[David]

Hi,

Theoretically you are absolutely right. But practically is another
discussion, I am talking about thousands of lines that need to change just
for the GUI tier limitations. The GUI is just a fraction of the application
because the same Request/Response objects are used internally as well
(command pattern). Redesigning the entire application because of a
limitation of the GUI is nuts. But in the way we use BigInteger, I
understand your point of view.

But the same problem is there with BigDecimal (somebody else filled an
issue so I did not bother to create a duplicate, it is marked as assume
stale).

We show records with BigDecimal in Cell tables. Again RPC is slow here.
While the user will only click on certain records to make modifications.
Again I could refactor to wait with conversion to BigDecimal until the user
changes a value (to validate), but in this case BigDecimal was the right
data-type to use and it is not nice to have to redesign an application
because the RPC system of GWT has limitations.

David

On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky skybr...@google.comwrote:

 I agree; this seems like a workaround for one application that picked the
 wrong datatype. Maybe we should warn about BigDecimal being slow somewhere?
 If someone wants to do some performance tests of GWT-RPC serialization,
 publishing the results would be useful to the community.

 My recommendation in this case would be create a new class named Id or
 Key that simply contains the BigDecimal, then modify the code to use it,
 then change the implementation to store the data in a string field instead.
 In the end you'll have more readable code.

 - Brian


 On Thu, Jun 13, 2013 at 12:03 PM, David david.no...@gmail.com wrote:

 John,

 Well, if I don't have support for this patch then I better stop working
 on it. I can understand that this is not seen as a priority for GWT. Worst
 case I just replace the BigInteger/BigDecimal class in the project itself,
 that is basically what I did right now.

 Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27.
 The Oracle JDBC drivers return
 a BigInteger if you force it to the extremes.

 Changing the application is not feasible, that will be too much work, we
 are talking about many thousands of dependencies in a huge codebase where
 BigIntegers and BigDecimals are used - while handling this optimisation on
 the RPC level can be done in just a few lines of code.

 In many cases we send large lists of objects that contain BigInteger,
 BigDecimals but only a few will actually be interacted with. So in that
 case we only need to convert the Strings to BigInteger (or BigDecimal) when
 really needed.

 David

 On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote:

 On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote:

 The lazy parsing would only happen during deserialisation in the
 client. I think it is safe to assume that a BigInteger created through
 toString on the server will not result in a parse exception in the client
 code - or are there known incompatibilities ?

 I don't want that the regular constructor of BigInteger( String ) or
 BigInteger( String, int) would behave differently than before. Not even in
 the client when those BigInts are created in the client. That's why I was
 asking about the possibility to have different serialisers on client and
 server side.

 As the why, well currently the custom field serializer converts the
 BigInteger to a String, the client side needs to parse the string and
 convert it to an int array, which involves multiple substring,
 Integer.parseInt and multiply and add operations. Somehow IE8 has a problem
 with this. IE9 and other browsers are more efficient, but still that is a
 lot of CPU operations that can be avoided in my use case.

 In my particular use case they used BigInteger to represent a key in
 the database (oracle uses sequence numbers that are bigger than what can be
 represented with long). That might have not been the best idea, but those
 decisions have been made a long time ago, when I was not around. On the
 server side there is a usage of equals and compareTo happening, which would
 be hard to implement without a BigInteger, so there is logic in the choice.
 They obviously don't want to have an extra layer of objects to avoid the
 BigInteger in the GWT client since a lot of code is independent of client
 or server, this would hinder code sharing between the tiers.

 On the client side these id's are only send forth and back between
 client and server, no operation is ever performed, so making the custom
 field serialiser and the BigInteger cooperate gives a big performance
 improvement. They only operation needed on the client-side is equals,
 which can also be optimized to do a String comparison when bother have not
 been parsed after RPC.

 
 I'm beginning to think such a change does not belong in GWT.  In your
 example, wouldn't you be better served by only

Re: [gwt-contrib] Issue 8083, needs some input from GWT team

[David]

Hi,

The lazy parsing would only happen during deserialisation in the client. I
think it is safe to assume that a BigInteger created through toString on
the server will not result in a parse exception in the client code - or are
there known incompatibilities ?

I don't want that the regular constructor of BigInteger( String ) or
BigInteger( String, int) would behave differently than before. Not even in
the client when those BigInts are created in the client. That's why I was
asking about the possibility to have different serialisers on client and
server side.

As the why, well currently the custom field serializer converts the
BigInteger to a String, the client side needs to parse the string and
convert it to an int array, which involves multiple substring,
Integer.parseInt and multiply and add operations. Somehow IE8 has a problem
with this. IE9 and other browsers are more efficient, but still that is a
lot of CPU operations that can be avoided in my use case.

In my particular use case they used BigInteger to represent a key in the
database (oracle uses sequence numbers that are bigger than what can be
represented with long). That might have not been the best idea, but those
decisions have been made a long time ago, when I was not around. On the
server side there is a usage of equals and compareTo happening, which would
be hard to implement without a BigInteger, so there is logic in the choice.
They obviously don't want to have an extra layer of objects to avoid the
BigInteger in the GWT client since a lot of code is independent of client
or server, this would hinder code sharing between the tiers.

On the client side these id's are only send forth and back between client
and server, no operation is ever performed, so making the custom field
serialiser and the BigInteger cooperate gives a big performance
improvement. They only operation needed on the client-side is equals, which
can also be optimized to do a String comparison when bother have not been
parsed after RPC.

David

On Thu, Jun 13, 2013 at 2:30 AM, John A. Tamplin j...@jaet.org wrote:

 Have we evaluated why it is so slow on ie8?  It might be easier to fix
 that.  The one thing it does is heavy use of StringBuffers so that could be
 where the issue is.
 On Jun 12, 2013 8:09 PM, Brian Slesinsky skybr...@google.com wrote:

 Lazy parsing can be a performance win, but it also complicates the API in
 the case of a parse error. Have you thought about how to report errors when
 they happen later?

 It might less confusing to solve this using a separate LazyBigDecimal
 class. People can declare fields of this type in their data transfer
 objects when they're concerned about performance.


 On Tue, Jun 11, 2013 at 1:56 AM, stuckagain david.no...@gmail.comwrote:

 Hi,

 I am working on a fix for this issue:
 https://code.google.com/p/google-web-toolkit/issues/detail?id=8083

 I am avoiding converting from string to the internal format of
 BigInteger because it has a big performance impact on IE8 when sending it
 over RPC. It performs much better in IE9 and other browsers, but still I
 want to optimize this since this is having a major impact in an application
 I am working on (And I saw some other people in the banking industry having
 similar issues with BigDecimal).

 In many cases this data is never modified in the client, so I am
 delaying the actual parsing of the String to the internal format of
 BigInteger.

 Is it feasible to have custom field serializers depending on running in
 the client or server ?

 The question I am asking is because I don't want to break the
 BigInteger(String) constructor that will throw exceptions when you feed it
 a non parseable string. so my solution would be to use a static method or
 custom constructor for BigInteger when deserializing on the client. But
 this method is not available in the real java.math.BigInteger class.

 So is it possible to have different client and server
 serializers/deserializer code for RPC ?

 David

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



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

Re: [gwt-contrib] Issue 8083, needs some input from GWT team

[David]

Forgot to mention this code-snippet I found in the BigInteger class:

  /**
   * The magnitude of this big integer. This array is in little endian
order and
   * each digit is a 32-bit unsigned integer. For example: {@code 13} is
   * represented as [ 13 ] {@code -13} is represented as [ 13 ] {@code 2^32
+
   * 13} is represented as [ 13, 1 ] {@code 2^64 + 13} is represented as [
13,
   * 0, 1 ] {@code 2^31} is represented as [ Integer.MIN_VALUE ] The
magnitude
   * array may be longer than strictly necessary, which results in
additional
   * trailing zeros.
   *
   * pTODO(jat): consider changing to 24-bit integers for better
performance
   * in browsers.
   */
  transient int digits[];
Always nice to have TODO's in code that are not done :-) Who is jat ?


David

On Thu, Jun 13, 2013 at 9:14 AM, David david.no...@gmail.com wrote:

 Hi,

 The lazy parsing would only happen during deserialisation in the client. I
 think it is safe to assume that a BigInteger created through toString on
 the server will not result in a parse exception in the client code - or are
 there known incompatibilities ?

 I don't want that the regular constructor of BigInteger( String ) or
 BigInteger( String, int) would behave differently than before. Not even in
 the client when those BigInts are created in the client. That's why I was
 asking about the possibility to have different serialisers on client and
 server side.

 As the why, well currently the custom field serializer converts the
 BigInteger to a String, the client side needs to parse the string and
 convert it to an int array, which involves multiple substring,
 Integer.parseInt and multiply and add operations. Somehow IE8 has a problem
 with this. IE9 and other browsers are more efficient, but still that is a
 lot of CPU operations that can be avoided in my use case.

 In my particular use case they used BigInteger to represent a key in the
 database (oracle uses sequence numbers that are bigger than what can be
 represented with long). That might have not been the best idea, but those
 decisions have been made a long time ago, when I was not around. On the
 server side there is a usage of equals and compareTo happening, which would
 be hard to implement without a BigInteger, so there is logic in the choice.
 They obviously don't want to have an extra layer of objects to avoid the
 BigInteger in the GWT client since a lot of code is independent of client
 or server, this would hinder code sharing between the tiers.

 On the client side these id's are only send forth and back between client
 and server, no operation is ever performed, so making the custom field
 serialiser and the BigInteger cooperate gives a big performance
 improvement. They only operation needed on the client-side is equals, which
 can also be optimized to do a String comparison when bother have not been
 parsed after RPC.

 David

 On Thu, Jun 13, 2013 at 2:30 AM, John A. Tamplin j...@jaet.org wrote:

 Have we evaluated why it is so slow on ie8?  It might be easier to fix
 that.  The one thing it does is heavy use of StringBuffers so that could be
 where the issue is.
 On Jun 12, 2013 8:09 PM, Brian Slesinsky skybr...@google.com wrote:

 Lazy parsing can be a performance win, but it also complicates the API
 in the case of a parse error. Have you thought about how to report errors
 when they happen later?

 It might less confusing to solve this using a separate LazyBigDecimal
 class. People can declare fields of this type in their data transfer
 objects when they're concerned about performance.


 On Tue, Jun 11, 2013 at 1:56 AM, stuckagain david.no...@gmail.comwrote:

 Hi,

 I am working on a fix for this issue:
 https://code.google.com/p/google-web-toolkit/issues/detail?id=8083

 I am avoiding converting from string to the internal format of
 BigInteger because it has a big performance impact on IE8 when sending it
 over RPC. It performs much better in IE9 and other browsers, but still I
 want to optimize this since this is having a major impact in an application
 I am working on (And I saw some other people in the banking industry having
 similar issues with BigDecimal).

 In many cases this data is never modified in the client, so I am
 delaying the actual parsing of the String to the internal format of
 BigInteger.

 Is it feasible to have custom field serializers depending on running in
 the client or server ?

 The question I am asking is because I don't want to break the
 BigInteger(String) constructor that will throw exceptions when you feed it
 a non parseable string. so my solution would be to use a static method or
 custom constructor for BigInteger when deserializing on the client. But
 this method is not available in the real java.math.BigInteger class.

 So is it possible to have different client and server
 serializers/deserializer code for RPC ?

 David

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

Re: [gwt-contrib] Issue 8083, needs some input from GWT team

[David]

John,

Well, if I don't have support for this patch then I better stop working on
it. I can understand that this is not seen as a priority for GWT. Worst
case I just replace the BigInteger/BigDecimal class in the project itself,
that is basically what I did right now.

Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27.
The Oracle JDBC drivers return
a BigInteger if you force it to the extremes.

Changing the application is not feasible, that will be too much work, we
are talking about many thousands of dependencies in a huge codebase where
BigIntegers and BigDecimals are used - while handling this optimisation on
the RPC level can be done in just a few lines of code.

In many cases we send large lists of objects that contain BigInteger,
BigDecimals but only a few will actually be interacted with. So in that
case we only need to convert the Strings to BigInteger (or BigDecimal) when
really needed.

David

On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote:

 On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote:

 The lazy parsing would only happen during deserialisation in the client.
 I think it is safe to assume that a BigInteger created through toString on
 the server will not result in a parse exception in the client code - or are
 there known incompatibilities ?

 I don't want that the regular constructor of BigInteger( String ) or
 BigInteger( String, int) would behave differently than before. Not even in
 the client when those BigInts are created in the client. That's why I was
 asking about the possibility to have different serialisers on client and
 server side.

 As the why, well currently the custom field serializer converts the
 BigInteger to a String, the client side needs to parse the string and
 convert it to an int array, which involves multiple substring,
 Integer.parseInt and multiply and add operations. Somehow IE8 has a problem
 with this. IE9 and other browsers are more efficient, but still that is a
 lot of CPU operations that can be avoided in my use case.

 In my particular use case they used BigInteger to represent a key in the
 database (oracle uses sequence numbers that are bigger than what can be
 represented with long). That might have not been the best idea, but those
 decisions have been made a long time ago, when I was not around. On the
 server side there is a usage of equals and compareTo happening, which would
 be hard to implement without a BigInteger, so there is logic in the choice.
 They obviously don't want to have an extra layer of objects to avoid the
 BigInteger in the GWT client since a lot of code is independent of client
 or server, this would hinder code sharing between the tiers.

 On the client side these id's are only send forth and back between client
 and server, no operation is ever performed, so making the custom field
 serialiser and the BigInteger cooperate gives a big performance
 improvement. They only operation needed on the client-side is equals,
 which can also be optimized to do a String comparison when bother have not
 been parsed after RPC.

 
 I'm beginning to think such a change does not belong in GWT.  In your
 example, wouldn't you be better served by only sending strings to the
 client rather than BigDecimals, if they client never does anything with
 them but send them back?  I think it is going to be pretty rare in normal
 situations that you instantiate a BigDecimal but never actually use it in
 the client, so it seems the special-case hack for your use-case should be
 performed in your code instead.

 Too often people want to send things to the client that really don't
 belong there, and that includes particular representations of it.  I know
 DTOs are extra work over just shipping your regular objects over the wire
 and GWT RPC makes that easy, but in many cases it is the wrong thing to do.
  Think about if you were building a proto for the communication -- would
 you send the data in the current form?  If not, you shouldn't be sending it
 that way via RPC just because it is easy to do so.

 BTW, I thought Oracle sequence numbers did fit in long (aren't they
 int64?) -- at least all the JDBC code I see for manipulating them stores
 them in a Java long.

 --
 John A. Tamplin

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

Re: [gwt-contrib] serializing final fields

[David]

Hi,

If you ask me, not serializing the final field was more a bug than a
feature. (I know, GWT RPC is not the same as Java serialization)

Do I need to enable something to get warnings on final fields not being
serialized in 2.5.1 or is that standard behaviour.

I am a very active user of the final keyword since it allow my IDE and Java
compiler to warn me when I forget to initialize it. So I am a bit suprised
that I did not see any warnings yet.

David

On Thu, Jun 6, 2013 at 7:36 AM, Stephen Haberman
step...@exigencecorp.comwrote:


  Does having the flag really make it that much more complicated?

 It would not seem like it, but yes. :-)

 Specifically passing the context down through the layers to the right
 spot to say do I serialize final fields? took a bit--one of the first
 patches that went by used a static field to avoid a lot of method
 signatures, but it assumed only one GWT module/setting running at a
 time.

 It was also complicated by having to play nicely with the current warn
 on finalize field flag.

 Both of these are trivial in the big scheme of GWT-RPC, but every
 little simplification helps.

 - Stephen

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




-- 
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: gwt rebranding

[David]

Not that I have anything of authority here, but why not adopt Guice instead
of all the gwt.xml trickery and call it the Guicy Web ToolKit

David

On Wed, Mar 20, 2013 at 1:44 PM, Kerry Wilson ke...@allthingswilson.comwrote:

 I would leave gorgeous out of it.  I would just consider it a recursive
 acronym like PHP.

 GWT: Web Toolkit

 kw


 On Wed, Mar 20, 2013 at 5:28 AM, Jens jens.nehlme...@gmail.com wrote:


 On the note of @Gorgeous Web Toolkit@, my $.02 is nice but isn't quite
 Gorgeous isn't geeky enough. The self referential thing is an option and
 flows nicely when said out loud Gwit Web Toolkit but isn't necessarily
 very descriptive.


 Hehe yeah Gorgeous doesn't really convince me either (feels too
 self-regarding to me). Just treat it as a slogan that can be added to the
 logo. May it be Gorgeous Web Toolkit or a totally different slogan like
 type safe web development. Just having icon + GWT feels a bit too less
 when using the logo at larger dimensions.
 At small dimensions its totally fine to just have icon + GWT like shown
 in my second example.

 -- J.


  --
 --
 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://www.allthingswilson.com

 --
 --
 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] Cleanup: is IE6 JNI really needed?

[David]

We are doing development on machines not connected to the internet and I
bet a lot of other GWT devs are in the same situation. So how can
management depend on such a feature to decide on usage ?

David

On Mon, Sep 3, 2012 at 10:44 AM, Thomas Broyer t.bro...@gmail.com wrote:



 On Monday, September 3, 2012 12:29:22 AM UTC+2, Ray Cromwell wrote:

 The version pings are actually pretty important in terms of showing
 Google management continued interest in GWT as well. Being able to
 have a rough estimate on how many active monthly users we have is a
 good way to argue for continued investment.


 Would you mind sharing the numbers? (at least with the Steering Committee)
 Also, while I understand the usefulness of the pings (I'll rollback my
 changes in the gwt-maven-plugin for the DevMode mojo), that doesn't answer
 the question about the need for the JNI access to WinINet. It looks to me
 like recent versions of Java (at least starting with 1.5, for the
 Sun/Oracle JDK) use the WinINet settings by default (that's what I
 understand from Oracle's documentation). Glancing at the OpenJDK code, it
 looks like they use the settings from the registry, but do not use WinINet
 directly. Does that make a difference in practice? (maybe for corporate
 proxies that require authentication?)

 Oh, and you'd probably want to add the ping to the SuperDevMode then?






 On Sat, Sep 1, 2012 at 10:41 PM, John A. Tamplin j...@jaet.org wrote:
  On Sat, Sep 1, 2012 at 9:57 AM, Thomas Broyer t.br...@gmail.com
 wrote:
 
  As you all know, the we decided to move to Maven as the build system
 for
  GWT. The first step is cleaning up dependencies.
 
  Digging into the code, I stumbled upon a bit of JNI: GWT checks for
  updates every day, and on Windows it tries to use a bit of JNI to glue
 it to
  the IE COM object, and therefore make sure to use the WinINet proxy
  settings.
  For that to work, it requires the gwt-ll.dll inside the install dir
 of
  the GWT SDK.
 
  So, first, it means that it won't work if you use GWT from Maven (or
 Ivy,
  or Gradle, or anything that uses the artifacts from The Central
 Repository
  rather than an SDK bundle downloaded from code.google.com or as an
 Eclipse
  plugin), and will fallback to using plain Java in that case.
  But I wonder if this bit of JNI is at all needed to being with, as
 Java
  seems to be using (or able to use, at least) the WinINet proxy
 settings:
  http://www.java.com/en/**download/help/proxy_setup.xmlhttp://www.java.com/en/download/help/proxy_setup.xml
 
  So, first question: is that bit of JNI really needed after all?
 
 
  IIRC, yes to get proper handling of proxy settings on Windows.
 
 
  Next question: is the version check needed? useful?
  I recently changed the gwt-maven-plugin to unconditionally pass the
  -XdisableUpdateCheck, as you generally don't want that check to be
 done on
  your CI server, and there are other means to check for updates (e.g.
 mvn
  versions:display-dependency-**updates to stay in the Maven world,
 but there's
  also an RSS feed for the downloads, and Sonatype's Insight –e.g.
  http://www.sonatype.com/**Products/Insight-App-Health-**Check–http://www.sonatype.com/Products/Insight-App-Health-Check%E2%80%93,
 and probably
  other means as well).
 
  Doing away with the update check would also mean losing the ability to
 tell
  what versions are active from the pings.
 
  --
  John A. Tamplin
 
  --
  http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://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

Re: [gwt-contrib] Re: gwt issues marked as patcheswelcome don't show up under open issues

[David]

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

Re: [gwt-contrib] Re: Any interest in having css3pie integrated with GWT?

[David]

I hope IE7 will not be dropped in short term. That would be dramatic
for GWT apps that are used in the enterprise environments.
In our case our customers are already very annoyed that we can not
support IE6 decently enough.

David

On Thu, Sep 29, 2011 at 6:21 PM, Jens jens.nehlme...@gmail.com wrote:
 -1
 I would not pull this into GWT. I think its better when you create a custom
 project like gwt-pie or something that developers can use or not use.
 In my opinion GWT should drop IE6 (and IE7) support in the near future.
 These browsers are so old (10 and 5 years) and their JavaScript engines are
 really slow. It really doesn't make sense to build a complex web application
 which supports IE6 and IE7, it will cost too much developer ressources. If
 you pull in PIE into GWT you will have an additional reason to support both
 browsers for years.
 I mean.. can you watch a full HD movie on 10 years old hardware? I don't
 think so. On 5 years old hardware? Probably but maybe stuttering. Its the
 same with browsers and web applications. People/Companies should definitely
 upgrade to at least IE8. If they don't they just can't use/enjoy new
 technologies.
 So before using CSS PIE I think its just better to not use CSS3 for old
 browsers at all, only use it for browsers that support CSS3 natively (and I
 think thats the same way the new clean style of GWT works). That way
 customers actually see the difference in design between old and new browsers
 and actually see a reason to upgrade their old browsers.
 -- J.

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

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

Re: [gwt-contrib] maven source jars

[David Chandler]

Maven push scripts are up for review, still making small tweaks:

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

On Wed, Aug 31, 2011 at 3:37 PM, Stephen Haberman 
stephen.haber...@gmail.com wrote:


  so renaming it without regenerating or stripping the JarIndex
  (META-INF/INDEX.LIST) generates spurious exceptions in DevMode

 So that's what been causing that for me--I never would have thought
 renaming the jar file would be a problem. Thanks for pointing that
 out!

 - Stephen


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




-- 
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

Re: [gwt-contrib] maven source jars

[David Chandler]

Thanks, Daniel, it's an interesting idea toward Mavenizing GWT, but I don't
think we're ready to bite off much more than simple deployment to Central
just yet. I plan to post the current script and POMs for code review this
week. The script does a bit of custom packaging since we include Java
sources needed by the GWT compiler in the gwt-user jar itself. Let's
continue the discussion once the script is available for review.

/dmc

On Mon, Aug 29, 2011 at 11:03 AM, Daniel Bell daniel.r.b...@gmail.comwrote:

 Hey Guys,

 I just noticed this thread, and wanted to suggest Maven Ant Tasks (
 http://maven.apache.org/ant-tasks/index.html). It includes Ant tasks for
 installing build artifacts to local Maven repositories, or deploying them to
 remote Maven repositories, both with arbitrary POMs. It can also generate
 POMs with given dependencies, and download/manage dependencies using Maven.

 It seems like a good road to take, given that it integrates better than
 tools/scripts/maven_script.sh with the existing build (Ant scripts), and
 means that you wouldn't have to store your dependencies in source control
 (apart from the patched/rebased ones, though you could deploy them to
 Central too). It could also replace your script that deploys to the remote
 Maven repository (I haven't seen that one, but I'm assuming it's a shell
 script too:
 http://code.google.com/p/google-web-toolkit/issues/detail?id=4853#c12),
 and allow you to automate the deployment to Sonatype's repo (and
 consequently to Central). If the plan was to eventually try to remove the
 dependencies and manage them with Maven, this would be a step in that
 direction too.

 Cheers,
 Daniel

 On 29 August 2011 20:00, Thomas Broyer t.bro...@gmail.com wrote:

 It's actually just a slight improvement over the already existing
 maven_script.shhttp://code.google.com/p/google-web-toolkit/source/browse/trunk/tools/scripts/maven_script.sh
  (using
 pre-written POMs rather than generating them)

 That's actually not enough though, because GWT jars are created with a
 JarIndex, and a JarIndex contains the name of the JAR, so renaming it
 without regenerating or stripping the JarIndex (META-INF/INDEX.LIST)
 generates spurious exceptions in DevMode (caught internally, but very
 annoying if you suspend executions on unhandled exceptions when launching
 DevMode with a debugger attached: the CompilingClassLoader looks up classes
 in a gwt-user.jar instead of the gwt-user-2.4-SNAPSHOT.jar).
 Removing the JarIndex, or regenerating it, is easy, but still.

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


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




-- 
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

Re: [gwt-contrib] maven source jars

[David Chandler]

Hi Stephen,

We have a script that creates the jars from the ZIP distro. I'll get it
checked in along with the POMs.

/dmc

On Thu, Aug 18, 2011 at 4:17 PM, Stephen Haberman 
stephen.haber...@gmail.com wrote:


  Is there a script/ant target I'm missing, or is this done with some
  script that isn't published? If so, could it be published?

 (To create the gwt-servlet-X-sources.jar that ends up in maven repos.)

 Ping?

 - Stephen

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




-- 
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

Re: [gwt-contrib] GWT Activities and places - French translation.

[David Chandler]

Hi Vincent,

Thanks very much for your inquiry. The Activities and Places doc is
published under the CC Attribution 3.0 license as noted in the footer, so
you're welcome to publish your translation provided you note that Google is
the original author. Also please link to the English source (translated
from
http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.htmlby
Google)

In addition, would you be willing to license your translation to Google for
the French version of the GWT docs? Please contact me about this off list at
your convenience.

Thanks,
/dmc

On Fri, Jun 24, 2011 at 7:42 PM, Vincent François 
vincentfrancois@gmail.com wrote:

 Hello,

 For reasons of convenience I made a French translation of the document
 Activities and places.

 My question is simple, do I have the right to publish this
 translation? If yes, what legal form should I use ?

 ---

 Vincent François vincentfrancois@gmail.com, France.

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




-- 
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

Re: [gwt-contrib] Was the lack of server side templating in GWT one of the reasons why Google+ team did not choose GWT ?

[David Chandler]

Thanks for pointing it out. I've already answered this in the best way
I know how, so I'm happy to let the community hash this one out.

https://groups.google.com/d/msg/google-web-toolkit/-/eSqUVQ8gKEMJ

/dmc

On Mon, Jul 18, 2011 at 10:13 AM, karthik reddy
karthik.ele...@gmail.com wrote:
 Note: I am cross-posting this on  GWT-contributors group to solicit the
 responses of the GWT team. The original post on the GWT group is at :
 https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/CnjBcJsknS0
 The following were two direct quotes from Joseph Smarr (tech lead of google
 plus -- plus.google.com):
 (FYI: The full Q  A with the Google+  Tech Lead can be found
 at: http://anyasq.com/79-im-a-technical-lead-on-the-google+-team)
 we often render our Closure templates server-side so the page renders
 before any JavaScript is loaded, then the JavaScript finds the right DOM
 nodes and hooks up event handlers, etc. to make it responsive (as a result,
 if you're on a slow connection and you click on stuff really fast, you may
 notice a lag before it does anything, but luckily most people don't run into
 this in practice).
 The cool thing about Closure templates is they can be compiled into both
 Java and JavaScript. So we use Java server-side to turn the templates into
 HTML, but we can also do the same in JavaScript client-side for dynamic
 rendering. For instance, if you type in a profile page URL directly, we'll
 render it server-side, but if you go to the stream say and navigate to
 someone's profile page, we do it with AJAX and render it client-side using
 the same exact template. 

 Going from the tone of the above two quotes, it seems to me that the lack of
 server-side templating  system in GWT (GWT has client-side templating in the
 form of UiBinder but not server-side templating) , could have been one of
 the reasons for  not choosing GWT for  the Google+ project.
 What do you guys think??
 Was the lack of server side templating  in GWT one of the reasons why
 Google+ team did not choose GWT ??

 PS: If you guys haven't tried Google+ yet, I would recommend you try it.
 Setting aside how good of a social network/social collaboration tool it is,
 I suggest you guys try it just to get a feel of its UI architecture. Every
 once in a while, an application comes along and raises the bar(eg., Gmail in
 2004) in the area of UI design/UI development and I think Google plus has
 done it this time around.
 Also, I really appreciate the fact that GWT is an exceptional work of
 engineering.  My desire is to just provoke discussion in a direction that
 hopefully leads to making the product even more better and increases its
 technological moat (Warren Buffet
 lingo: http://37signals.com/svn/posts/333-warren-buffett-on-castles-and-moats)

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



-- 
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

[gwt-contrib] GPE 2.3 live on Indigo

[David Chandler]

For those who might have missed it in other threads, Google Plugin for
Eclipse 2.3 is now available for Eclipse Indigo (3.7). See instructions
here:

http://code.google.com/eclipse/docs/getting_started.html

GPE 2.4 is currently in beta, release coming shortly.

/dmc

-- 
David Chandler
Developer Programs Engineer, Google Web Toolkit
w: http://code.google.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

Re: [gwt-contrib] Earn $1000-$2500 per month

[David Chandler]

Nope, and I reject several spammers daily. On the GWT group, some have
gotten smarter and are now posting legit-sounding messages in advance.

/dmc

On Tue, Jun 7, 2011 at 4:49 AM, roseanje...@rediffmail.com 
roseanje...@rediffmail.com wrote:

 Earn $1000-$2500 per month
 If you Register your name
 You Get Sign-up bonus $5
   AND
 Get $.20 cent for each referral.
 Further details
 
 http://www.earnbyforex.com/index.php?id=35678365
 

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




-- 
David Chandler
Developer Programs Engineer, Google Web Toolkit
w: http://code.google.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

[gwt-contrib] Re: Fix issue 5807 on server side. Previously reviewed at 1370803. (issue1384802)

[David Chandler]

I removed the latest patch set since the latest diffs were broken. I used
the rietveld script so SVN base path was correct, but the internal rollback
and reapply seems to have confused rietveld. I may have to create a new
issue.

On Wed, Mar 16, 2011 at 7:30 PM, drfibona...@google.com wrote:

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




-- 
David Chandler
Developer Programs Engineer, Google Web Toolkit
w: http://code.google.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

[gwt-contrib] GWT 2.2.0 broke binary compatibility for code generation

[David Chandler]

Dear GWT community,

The recent release of GWT 2.2.0 inadvertently broke binary (but not source)
compatibility with any third party library that does code generation,
including GIN. This was the result of an architectural change to the GWT
compiler to support future improvements such as caching of generated
artifacts.

To resolve the issue, each jar that uses code generation must be recompiled
with GWT 2.2.0. A new version of GIN (1.5) which works with 2.2.0 and
earlier is now available at
http://code.google.com/p/google-gin/downloads/list. If you're using other
3rd-party jars that use code generation, please update them also.

If you are getting an error like the following, you are probably using a jar
that needs to be recompiled with GWT 2.2.

Caused by: java.lang.IncompatibleClassChangeError: Found interface
com.google.gwt.core.ext.typeinfo.JClassType, but class was expected

We apologize for the inconvenience, and for not informing you at the time of
the release.

/dmc

-- 
David Chandler
Developer Programs Engineer, Google Web Toolkit
w: http://code.google.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

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

Re: [gwt-contrib] Re: GWT 2.1 / gwt-incubator tables

[David]

a customer is a broad concept :-)


On Wed, Nov 17, 2010 at 10:04 PM, Stephen Haberman
stephen.haber...@gmail.com wrote:

 I complained about the same subject when 2.1 was released. After 2
 years of waiting very little functionality in the new table was
 released. I can understand the motivation of the GWT team, but they do
 not  seem to understand their customers very well.

 Wow, tough crowd. I would have reserved the term customers for
 commercial software. :-)

 - Stephen

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

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

Re: [gwt-contrib] Re: GWT 2.1 / gwt-incubator tables

[David]

Hi,

Glad to hear that I am not the only one disappointed with the CellTable.

I complained about the same subject when 2.1 was released. After 2
years of waiting very little functionality in the new table was
released. I can understand the motivation of the GWT team, but they do
not  seem to understand their customers very well. Or, well maybe we
are trying to use a tool that is not fit for our purpose ?

The GWT compiler is great but the widgets remain minimalistic and very
hard or even impossible to extend.

In our projects I already moved away from most of the core GWT widgets
because they are so restrictive. As a result the risk is very high
that we do not handle all browser as it should be, and we actually
lose the core promise that GWT was given us: browser independence!

Since browsers are becoming faster every day, thanks to Google, you
might also question if the GWT compiler optimisations will remain a
huge selling point ?

David

On Wed, Nov 17, 2010 at 6:45 PM, Thomas Broyer t.bro...@gmail.com wrote:


 On 17 nov, 16:12, dflorey daniel.flo...@gmail.com wrote:
 Hi,
 as stated in this thread

 http://groups.google.com/group/google-web-toolkit/browse_thread/threa...

 GWT 2.1 will replace the incubator table framework.

 I may be blind but after looking at the sources I cannot find
 - Fixed table header (ScrollTable)
 - Resizable columns
 - Built in sorting/filtering
 - TreeTable

 Unfortunately the gwt-incubator will not work with 2.1 mainly because
 of the event stuff and the new logging.

 It looks like it's not true: 
 http://twitter.com/salvadordiaz/status/581058928050176
 (haven't tried it myself though)

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

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

Re: [gwt-contrib] JsonRequestProcessor and multiple findEntity calls

[David Chandler]

Hi Alexei, sorry for the slow response. I confirmed this with bobv and
was working on a reply but got sidetracked.

The behavior you're seeing is expected in the current implementation.
This will be reduced slightly by the server-side refactoring in
progress. In the 2.1.1
codebase, all incoming objects will trigger two finds.  The first is
to load the domain object to process the request.  The second will be
to determine if the object has been deleted.  A hook will be available
to inject more efficient logic to determine if an object has become
irretrievable.

HTH,
/dmc

On Wed, Nov 3, 2010 at 12:26 PM, Alexei a.sam...@googlemail.com wrote:
 Hello,

 I sent the question below to the general GWT discussion group first,
 but unfortunately I didn't get any reply. So it's my second try here.
 Thank's in advance!


 I've just created a small test GWT 2.1 application to play a bit with
 the request factory. It works cool on the client side but I cannot
 figure how it should work on the server side. I have an entity that
 is
 decraled as @Service

 @ProxyFor(PropertyType.class)
 public interface PropertyTypeProxy extends EntityProxy{
 
 }

 @PersistenceCapable
 public class PropertyType {
 
        public static PropertyType findPropertyType(Long id){
                PersistenceManager pm =
 PMF.get().getPersistenceManager();
                PropertyType pt = null;
                try {
                        pt = pm.getObjectById(PropertyType.class,
 id);
                        pt = pm.detachCopy(pt);
                } catch (Exception e) {
                        e.printStackTrace();
                }finally{
                        pm.close();
                }
                return pt ;
        }
 }

 When I just call in the client:
        PropertyTypeProxy a = req.edit(p);
        a.setTitle(event.getValue());
        req.persist().using(a).fire();

 the function PropertyType.findPropertyType is called three times.
 They
 all are called from JsonRequestProcessor.processJsonRequest(String
 jsonRequestString):

 
   // Construct beforeDataMap
   constructBeforeDataMap(); // 1st
   // Construct afterDvsDataMap.
   constructAfterDvsDataMapAfterCallingSetters(); // 2nd
 ...
   JSONObject sideEffects = getSideEffects(); // 3rd

 So, in order to persist an entity, it executes 3 times DB select.
 What's the reason of that? I would expect that I have a possibility
 to
 persist an entity in a single transaction and in a single call. Am I
 missing anything or it's really designed so?

 Regards,

 Alexei

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




-- 
David Chandler
Developer Programs Engineer, Google Web Toolkit
http://googlewebtoolkit.blogspot.com/

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

Re: [gwt-contrib] JsonRequestProcessor and multiple findEntity calls

[David Chandler]

PS The refactoring I mentioned is available for review at
http://gwt-code-reviews.appspot.com/1062801/show

On Wed, Nov 3, 2010 at 5:35 PM, David Chandler drfibona...@google.com wrote:
 Hi Alexei, sorry for the slow response. I confirmed this with bobv and
 was working on a reply but got sidetracked.

 The behavior you're seeing is expected in the current implementation.
 This will be reduced slightly by the server-side refactoring in
 progress. In the 2.1.1
 codebase, all incoming objects will trigger two finds.  The first is
 to load the domain object to process the request.  The second will be
 to determine if the object has been deleted.  A hook will be available
 to inject more efficient logic to determine if an object has become
 irretrievable.

 HTH,
 /dmc

 On Wed, Nov 3, 2010 at 12:26 PM, Alexei a.sam...@googlemail.com wrote:
 Hello,

 I sent the question below to the general GWT discussion group first,
 but unfortunately I didn't get any reply. So it's my second try here.
 Thank's in advance!


 I've just created a small test GWT 2.1 application to play a bit with
 the request factory. It works cool on the client side but I cannot
 figure how it should work on the server side. I have an entity that
 is
 decraled as @Service

 @ProxyFor(PropertyType.class)
 public interface PropertyTypeProxy extends EntityProxy{
 
 }

 @PersistenceCapable
 public class PropertyType {
 
        public static PropertyType findPropertyType(Long id){
                PersistenceManager pm =
 PMF.get().getPersistenceManager();
                PropertyType pt = null;
                try {
                        pt = pm.getObjectById(PropertyType.class,
 id);
                        pt = pm.detachCopy(pt);
                } catch (Exception e) {
                        e.printStackTrace();
                }finally{
                        pm.close();
                }
                return pt ;
        }
 }

 When I just call in the client:
        PropertyTypeProxy a = req.edit(p);
        a.setTitle(event.getValue());
        req.persist().using(a).fire();

 the function PropertyType.findPropertyType is called three times.
 They
 all are called from JsonRequestProcessor.processJsonRequest(String
 jsonRequestString):

 
   // Construct beforeDataMap
   constructBeforeDataMap(); // 1st
   // Construct afterDvsDataMap.
   constructAfterDvsDataMapAfterCallingSetters(); // 2nd
 ...
   JSONObject sideEffects = getSideEffects(); // 3rd

 So, in order to persist an entity, it executes 3 times DB select.
 What's the reason of that? I would expect that I have a possibility
 to
 persist an entity in a single transaction and in a single call. Am I
 missing anything or it's really designed so?

 Regards,

 Alexei

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




 --
 David Chandler
 Developer Programs Engineer, Google Web Toolkit
 http://googlewebtoolkit.blogspot.com/




-- 
David Chandler
Developer Programs Engineer, Google Web Toolkit
http://googlewebtoolkit.blogspot.com/

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

Re: [gwt-contrib] Re: GWT 2.1 MVP with GIN

[David Chandler]

Hmmm, I see my comments about GIN in the ActivityMapper have caught up
with me. I haven't worked this out fully yet, but was thinking of
something along the lines of gwt-presenter's a
href=http://code.google.com/p/gwt-presenter/source/browse/src/main/java/net/customware/gwt/presenter/client/place/PresenterPlace.java;PresenterPlace/a.
My thought is to use GIN in place of the ClientFactory, and to write
ActivityMapper.getActivity() like this:

public Activity getActivity(Place place) {
if (place instanceof ActivityPlace)
{
return ((ActivityPlace) place).getActivity();
}
}

where an ActivityPlace would be obtained from a GIN-aware
PlaceHistoryMapperWithFactory implementation so it can be injected
with the EventBus, etc.


On Wed, Oct 20, 2010 at 8:54 AM, Aigeec aodhag...@gmail.com wrote:
 Hey Guys,

 I am also interested in an implementation of GWT 2.1 MVP using GIN.

 I have made some head way with it.

 This has been done mostly by extending the ActivityManager,
 PlaceController and PlaceHistoryHandler classes and overriding their
 constructors to use GIN injection. I don't know if this is the correct
 implementation and if anyone has comments please let me know. But I
 have been able to remove the need for the ClientFactory and use GIN
 injection to instantiate everything but the Activity classes.

 However, I do not know how to tackle the ActivityMapper class.

 As Tolga says how do we replace the nested if statement with a GIN
 module?

 I would much prefer to be able to instantiate the Activity Class this
 way as I am using the SecureDispatchAsync as would like to use DI to
 pass it to the Activity.

 Regards,

 Aigeec

 On Oct 20, 1:31 am, Tolga Tarhan ttar...@gmail.com wrote:
 Folks,

 I'm trying to make GWT 2.1 MVP work nicely with GIN. It looks like this use
 case was specifically considered when
 creating PlaceHistoryMapperWithFactory, but no such thing seems to exist for
 ActivityMapper. There is a passing reference to using Gin in
 DevGuideMvpActivitiesAndPlaces.html , where it says ... ClientFactory is
 used by HelloActivity to obtain a reference to the HelloView as well as the
 EventBus and PlaceController. Any of these could alternatively be injected
 via GIN. and also when it says A better way to implement the chain of
 nested ifs would be with a GIN module, in reference to ActivityMapper.

 The problem, however, is that we cannot both inject application-level
 objects (EventBus, PlaceController, etc) and also pass the Place as
 constructor arguments to the Activity. We could have all of the dependencies
 for every Activity (like all the views) injected into our ActivityMapper and
 pass them thru, but this leaks a lot of details into what should be a very
 simple mapper class. If done incorrectly, it would also cause code-splitting
 issues.

 One way around this is to inject a ProviderMyActivity or
 AsyncProviderMyActivity in the ActivityMapper and then do something like
 myActivityProvider.get().initPlace(place) - which is like the assisted
 injection that's discussed in the Guice docs. I'm wondering if there's a
 more elegant way that was considered?

 Additionally, I'm not sure I understand how to implement the chain of
 nested ifs in a GIN module. This sounds like a great idea, but what did you
 have in mind to make GIN do this for us? We can have GIN differentiate on a
 bunch of things (annotations, generics, interfaces, etc), but I don't know
 how you could replace the if-block with GIN. Could someone point me in the
 right direction here?

 Thanks,
 Tolga

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


-- 
David Chandler
Developer Programs Engineer, Google Web Toolkit
http://googlewebtoolkit.blogspot.com/

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

Re: [gwt-contrib] Re: GWT 2.1 MVP with GIN

[David]

Why not include Gin in GWT 2.1 ? It could maybe be useful inside the
GWT codebase as well ?

On Wed, Oct 20, 2010 at 5:32 PM, David Chandler drfibona...@google.com wrote:
 Hmmm, I see my comments about GIN in the ActivityMapper have caught up
 with me. I haven't worked this out fully yet, but was thinking of
 something along the lines of gwt-presenter's a
 href=http://code.google.com/p/gwt-presenter/source/browse/src/main/java/net/customware/gwt/presenter/client/place/PresenterPlace.java;PresenterPlace/a.
 My thought is to use GIN in place of the ClientFactory, and to write
 ActivityMapper.getActivity() like this:

        public Activity getActivity(Place place) {
                if (place instanceof ActivityPlace)
                {
                        return ((ActivityPlace) place).getActivity();
                }
        }

 where an ActivityPlace would be obtained from a GIN-aware
 PlaceHistoryMapperWithFactory implementation so it can be injected
 with the EventBus, etc.


 On Wed, Oct 20, 2010 at 8:54 AM, Aigeec aodhag...@gmail.com wrote:
 Hey Guys,

 I am also interested in an implementation of GWT 2.1 MVP using GIN.

 I have made some head way with it.

 This has been done mostly by extending the ActivityManager,
 PlaceController and PlaceHistoryHandler classes and overriding their
 constructors to use GIN injection. I don't know if this is the correct
 implementation and if anyone has comments please let me know. But I
 have been able to remove the need for the ClientFactory and use GIN
 injection to instantiate everything but the Activity classes.

 However, I do not know how to tackle the ActivityMapper class.

 As Tolga says how do we replace the nested if statement with a GIN
 module?

 I would much prefer to be able to instantiate the Activity Class this
 way as I am using the SecureDispatchAsync as would like to use DI to
 pass it to the Activity.

 Regards,

 Aigeec

 On Oct 20, 1:31 am, Tolga Tarhan ttar...@gmail.com wrote:
 Folks,

 I'm trying to make GWT 2.1 MVP work nicely with GIN. It looks like this use
 case was specifically considered when
 creating PlaceHistoryMapperWithFactory, but no such thing seems to exist for
 ActivityMapper. There is a passing reference to using Gin in
 DevGuideMvpActivitiesAndPlaces.html , where it says ... ClientFactory is
 used by HelloActivity to obtain a reference to the HelloView as well as the
 EventBus and PlaceController. Any of these could alternatively be injected
 via GIN. and also when it says A better way to implement the chain of
 nested ifs would be with a GIN module, in reference to ActivityMapper.

 The problem, however, is that we cannot both inject application-level
 objects (EventBus, PlaceController, etc) and also pass the Place as
 constructor arguments to the Activity. We could have all of the dependencies
 for every Activity (like all the views) injected into our ActivityMapper and
 pass them thru, but this leaks a lot of details into what should be a very
 simple mapper class. If done incorrectly, it would also cause code-splitting
 issues.

 One way around this is to inject a ProviderMyActivity or
 AsyncProviderMyActivity in the ActivityMapper and then do something like
 myActivityProvider.get().initPlace(place) - which is like the assisted
 injection that's discussed in the Guice docs. I'm wondering if there's a
 more elegant way that was considered?

 Additionally, I'm not sure I understand how to implement the chain of
 nested ifs in a GIN module. This sounds like a great idea, but what did you
 have in mind to make GIN do this for us? We can have GIN differentiate on a
 bunch of things (annotations, generics, interfaces, etc), but I don't know
 how you could replace the if-block with GIN. Could someone point me in the
 right direction here?

 Thanks,
 Tolga

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


 --
 David Chandler
 Developer Programs Engineer, Google Web Toolkit
 http://googlewebtoolkit.blogspot.com/

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

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

Re: [gwt-contrib] Re: RPC vs DeRPC in 2.1

[David]

Hi,

Sounds fantastic!

I hope that it will be easy to use it with something else than
SpringRoo on the server side.

We are mostly using JAXB/SOAP generated objects on the server side. We
have our own conversion code to create GWT compatible DTOs, I guess we
can accomodate there to generate the needed interfaces to use the
RequestFactory approach.

David

On Wed, Sep 22, 2010 at 4:07 PM, BobV b...@google.com wrote:
 RequestFactory is good for any kind of bean-like-object.  If you look
 at the DynaTableRf sample, the backing store is a trivial list of
 in-memory objects.  There is a simplistic transaction model in the app
 to demonstrate JSR 303 validation.

 The most important design aspect of RequestFactory is that it does
 RPC by interface instead of by concrete type, so you don't have to
 worry about your server-side domain objects not being GWT-compatible
 or having to hand-roll DTOs.

 --
 Bob Vawter
 Google Web Toolkit Team

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

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

Re: [gwt-contrib] Re: RPC vs DeRPC in 2.1

[David]

Ok,

I'll keep my fingers crossed!

David

On Tue, Sep 21, 2010 at 2:59 PM, Thomas Broyer t.bro...@gmail.com wrote:


 On Sep 21, 11:44 am, stuckagain david.no...@gmail.com wrote:
 GWT contributors,

 Will there be a production quality RPC mechanism available in GWT 2.1
 as part of the RequestFactory stuff ? Or do we still have to suffer
 the stackoverflow inducing RPC implementation ?

 I'm currently fighting to get RPC to work with a tree structure that
 is not that big in bytesize, but it has about 20 levels of nesting in
 my example. RPC on IE6/7/8 just shokes on it, but no warning is shown.
 I just don't get all the data - which is very disturbing.

 When I run in DevMode I get a stackoverflow popup during the RPC
 handling.

 I tried to use the experimental DeRPC (according to the docs) but it
 fails, I assume it has to do with the fact that we have custom field
 serializers... but I find no documentation on how to implement them
 for DeRPC.

 I guess for now I will have to move away from RPC and do it myself
 using json or another encoding.

 GWT advocacy articles all talk about RPC as one of the big reasons to
 move to GWT ... so I'm sure there will finally be a decent solution
 that is working fast, has no stack dependency and allows us to add
 hooks to dispatch the method calls somewhere outside the servlet class
 without the need to declare them in the servlet (so that I can
 dispatch to a POJO that is agnostic of web tier technology) - right ?

 AFAICT, RequestFactory (as it will be in 2.1, as it should be in M4)
 seems to be what you're looking for:
  - fast: pure JSON (will use native JSON if available, falling back
 to json2.js otherwise)
  - no stack dependency: your entity proxies are JavaScriptObjects
 directly parsed from/stringified to JSON (there currently are
 wrappers, but they are created on the fly)
  - dispatch methods outside the servlet: this is part of
 RequestFactory's design

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

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

Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?

[David]

Hi,

We are not allowed to bring in software on some external media. All
software we use must be downloaded by a department so that they can
track all software being used and the lawyers can check if the license
agreements are acceptable.

In order to download something I need a URL.

But anyway, indeed if this is not deemed important to the GWT team I
can understand.

What is important is that we can have the eclipse plugin/browser
plugins without the need for an active internet connection.

David

On Mon, Sep 13, 2010 at 6:25 PM, John Tamplin j...@google.com wrote:
 On Mon, Sep 13, 2010 at 9:11 AM, David david.no...@gmail.com wrote:
 It would be acceptable for testing purpose only. releases to
 production have to be official versions. But it would make it soo much
 easier to already start using features that should normally be
 available by the time we go to production.

 So if the issue is simply having network connectivity, couldn't you
 just checkout GWT on your own machine, build it there, and bring in
 the zip the same way as if there were a nightly build?  It would have
 just as much testing as the nightly build would.

 I am not saying we shouldn't do a nightly build anyway (it is just the
 opportunity cost of what else we could be doing with that effort), but
 I am not sure why not having it means you can't use GWT trunk for the
 same testing purposes already.

 --
 John A. Tamplin
 Software Engineer (GWT), Google

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

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

Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?

[David]

 What is important is that we can have the eclipse plugin/browser
 plugins without the need for an active internet connection.

 You can do that, though it takes a bit of work -- basically mirror the
 directory off the server and unpack it, then point the Eclipse update
 site at the unpacked folder.  I did that to install it on my home
 machine before it was available via any public URL.  I don't know if
 your department that tracks software would find that acceptable or
 not.

how can I mirror the website for the eclipse update site ? I can not
get a directory listing there.
Additionally the IE plugin is actually just an empty shell that needs
to go to the internet to download the latest version.

There are some very old versions of the browser plugins available in
the trunk but I guess it was put there one day and totally forgotten
afterwards ?

David

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

Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?

[David]

Hi Eric,

It would be acceptable for testing purpose only. releases to
production have to be official versions. But it would make it soo much
easier to already start using features that should normally be
available by the time we go to production.

David

On Mon, Sep 13, 2010 at 3:02 PM, Joel Webber j...@google.com wrote:
 This is slightly off-topic, but I'm curious -- would having a formal nightly
 build actually be acceptable for use within your locked-down environment?
 And would the same go for offline dev-mode plugin installers?
 Le 12 septembre 2010 08:43, David david.no...@gmail.com a écrit :

 Eric,

 No I'm not using the draftCompile option, I will see if it improves even
 more.

 And yes, after removing the incubator from my project the whole
 project compile process only took 1/3rd of the time (7 minutes instead
 of 22 minutes). I guess the main reason is probably because we had to
 import both gen2 and widgetideas in.

 I am not able/allowed to get the trunk downloaded due to corporate
 policies. That's why in the past I asked if the GWT team did not want
 to consider daily builds/dev builds. So I will have to wait until 2.1
 is out.

 And when it is, I guess I will again have to ask for non installers
 for the IE/Firefox/Chrome plugins that do not mandate an internet
 connection :-S. So maybe for the poor corporate developers in very
 secure environments that fight to get GWT accepted: think about us!
 ;-)

 David

 On Fri, Sep 10, 2010 at 8:48 PM, Eric Ayers zun...@google.com wrote:
  Hi David,
 
  Are you using the -draftCompile option? The reason I ask is that using
  this
  option cuts out the optimization steps to make the compile run faster.
   The
  end result i that running the JDT compiler takes dominates the compile
  time
  when using it.   Everything on the sourcepath is compiled at least once
  to
  build the TypeOracle.  Every class that is actually used is run through
  the
  JDT compile library twice.  So, removing even unreferenced files from
  the
  source path should have a significant impact.
 
  We are considering all kinds of performance improvements, but keeping
  modules small and independent and referencing the smallest number needed
  is
  going to always give the best compilation performance.  In the future,
  if
  you need one widget from a module that is full of unreferenced code, you
  could define a custom one that includes just the paths you need to
  minimize
  compile time.
 
  If you like, run your build with a tip of trunk GWT and add
  -Dgwt.speedtracerlog=/tmp/speedtracer.html both with and without the
  incubator dependencies and I can tell more about why your compile time
  improved so dramatically.
 
  -Eric.
 
  On Fri, Sep 10, 2010 at 11:02 AM, stuckagain david.no...@gmail.com
  wrote:
 
  Hi,
 
  I managed to finally factor our the incubator widgets from my medium
  sized application and now that I have no dependencies left I saw the
  compile time decrease with 66%. Which is an amazing.
 
  We were only using 2 widgets yet this library had such a huge impact.
 
  Are there any plans to improve on this in the future ?
 
  David
 
  --
  http://groups.google.com/group/Google-Web-Toolkit-Contributors
 
 
 
  --
  Eric Z. Ayers
  Google Web Toolkit, Atlanta, GA USA
 
  --
  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

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

Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?

[David]

Eric,

No I'm not using the draftCompile option, I will see if it improves even more.

And yes, after removing the incubator from my project the whole
project compile process only took 1/3rd of the time (7 minutes instead
of 22 minutes). I guess the main reason is probably because we had to
import both gen2 and widgetideas in.

I am not able/allowed to get the trunk downloaded due to corporate
policies. That's why in the past I asked if the GWT team did not want
to consider daily builds/dev builds. So I will have to wait until 2.1
is out.

And when it is, I guess I will again have to ask for non installers
for the IE/Firefox/Chrome plugins that do not mandate an internet
connection :-S. So maybe for the poor corporate developers in very
secure environments that fight to get GWT accepted: think about us!
;-)

David

On Fri, Sep 10, 2010 at 8:48 PM, Eric Ayers zun...@google.com wrote:
 Hi David,

 Are you using the -draftCompile option? The reason I ask is that using this
 option cuts out the optimization steps to make the compile run faster.  The
 end result i that running the JDT compiler takes dominates the compile time
 when using it.   Everything on the sourcepath is compiled at least once to
 build the TypeOracle.  Every class that is actually used is run through the
 JDT compile library twice.  So, removing even unreferenced files from the
 source path should have a significant impact.

 We are considering all kinds of performance improvements, but keeping
 modules small and independent and referencing the smallest number needed is
 going to always give the best compilation performance.  In the future, if
 you need one widget from a module that is full of unreferenced code, you
 could define a custom one that includes just the paths you need to minimize
 compile time.

 If you like, run your build with a tip of trunk GWT and add
 -Dgwt.speedtracerlog=/tmp/speedtracer.html both with and without the
 incubator dependencies and I can tell more about why your compile time
 improved so dramatically.

 -Eric.

 On Fri, Sep 10, 2010 at 11:02 AM, stuckagain david.no...@gmail.com wrote:

 Hi,

 I managed to finally factor our the incubator widgets from my medium
 sized application and now that I have no dependencies left I saw the
 compile time decrease with 66%. Which is an amazing.

 We were only using 2 widgets yet this library had such a huge impact.

 Are there any plans to improve on this in the future ?

 David

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



 --
 Eric Z. Ayers
 Google Web Toolkit, Atlanta, GA USA

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

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

Re: [gwt-contrib] ImageResource to html

[David]

Miroslav,

Thomas already gave me a workable solution.

I want to use ImageResources in widgets that expose a setHTML(...)
method to put something more complex in there (for example in the
ComplexButton/ToggleButton). They do not support widgets in thos
locations so I can not put an Image widget. I do not want to loose the
advantage of an ImageResource.

David

On Fri, Aug 13, 2010 at 2:23 PM, Miroslav Pokorny
miroslav.poko...@gmail.com wrote:
 Hi David

 What do you mean by IMG tag, do you mean IMG with a src=/somefile on the
 server ?

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

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

Re: [gwt-contrib] Command pattern and GWT.runAsync

[David]

Less maintenance on the async, declarative transaction management,
undo, batching, less web.xml tweeking, ... there are many reasons why
we also use a command pattern.


On Thu, Jun 3, 2010 at 3:11 PM, Miroslav Pokorny
miroslav.poko...@gmail.com wrote:
 Why use a uber command pattern for all services. This only leads to some
 controller code to dispatch the command on the server which means everything
 gets funneled thru a single point with no real gain. Keep the services
 separate each w/ their own respective end points and service interfaces.
 That way the exact problem described below is also avoided as an added
 benefit. Command pattern for browser apps is so struts and imho not needed
 for GWT RPC. After all what do you gain ?

 On Sun, May 30, 2010 at 10:35 PM, Julio Faerman jfaer...@gmail.com wrote:

 Hi,

 I am trying to split a GWT app that uses the command (action) pattern.
 The problem is that  GWT.create(ActionService.class) causes every
 subclass of the return and parameter types to be included in the
 initial fragment.

 For instance, my action interface is:

 public interface ActionService extends RemoteService {
        T extends Response, V extends Request T execute(V req) throws
 ActionFailedException;
 }

 the problem is that module1.SomeRequest and module2.OtherRequest
 gets included in the initial fragment.
 Do you see a way around this?

 Thanks,
 Julio Faerman

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


 --
 mP

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

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

Re: [gwt-contrib] Tabless

[David]

OMG,

That will severly impact existing applications. We have a rule that
states that we should not use deprecated methods or types ...
This means rewriting hundred thousands of lines of GUI code... I'm not
sure how I will sell this to my development manager!

And do the new Layout widgets actually fix all issues we had with the
old widgets ?

David

On Thu, Jun 3, 2010 at 7:55 PM, Lex Spoon sp...@google.com wrote:
 On Thu, Jun 3, 2010 at 12:56 PM, Ray Ryan rj...@google.com wrote:

 No argument. And since we've never, ever managed to actually delete a
 deprecated class so far as I know, the issue may not come up for a while…

 There are some counterexamples. For example:
 http://gwt-code-reviews.appspot.com/139804/show
 To get deprecated things removed, it's key that users have something to
 switch to.
 Lex

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

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

Re: [gwt-contrib] Command pattern and GWT.runAsync

[David]

Miroslav,

There are plenty of solutions to avoid a big switch statement. I'm
using a combination of inheritance and the visitor pattern to group
things.
By using annotations I can even build a repository of CommandHandlers
at startup time with 0 configuration.

So why not ? Every application has the right for their design choices,
no ? Or can you give the ultimate approach that we all should be using
?

David


On Fri, Jun 4, 2010 at 2:25 PM, Miroslav Pokorny
miroslav.poko...@gmail.com wrote:
 Does it really make sense to give all serivices the same intf. Im sure
 because everything comes back to a big switch of some sort to dispatch the
 different types of command results. With different end points this problem
 does not exist.

 If you really must batch pick the ones that actually belong to each other,
 as they are a logical unit and sharing an intf makes sense.

 The command pattern is for operations that are related its not intended for
 each and every type of operation no matter how unrelated they are. GWT buys
 you great type safety something one loses with Javascript and this uber
 command pattern throws all that out.

 On Fri, Jun 4, 2010 at 7:13 PM, David david.no...@gmail.com wrote:

 Less maintenance on the async, declarative transaction management,
 undo, batching, less web.xml tweeking, ... there are many reasons why
 we also use a command pattern.


 On Thu, Jun 3, 2010 at 3:11 PM, Miroslav Pokorny
 miroslav.poko...@gmail.com wrote:
  Why use a uber command pattern for all services. This only leads to some
  controller code to dispatch the command on the server which means
  everything
  gets funneled thru a single point with no real gain. Keep the services
  separate each w/ their own respective end points and service interfaces.
  That way the exact problem described below is also avoided as an added
  benefit. Command pattern for browser apps is so struts and imho not
  needed
  for GWT RPC. After all what do you gain ?
 
  On Sun, May 30, 2010 at 10:35 PM, Julio Faerman jfaer...@gmail.com
  wrote:
 
  Hi,
 
  I am trying to split a GWT app that uses the command (action) pattern.
  The problem is that  GWT.create(ActionService.class) causes every
  subclass of the return and parameter types to be included in the
  initial fragment.
 
  For instance, my action interface is:
 
  public interface ActionService extends RemoteService {
         T extends Response, V extends Request T execute(V req) throws
  ActionFailedException;
  }
 
  the problem is that module1.SomeRequest and module2.OtherRequest
  gets included in the initial fragment.
  Do you see a way around this?
 
  Thanks,
  Julio Faerman
 
  --
  http://groups.google.com/group/Google-Web-Toolkit-Contributors
 
 
  --
  mP
 
  --
  http://groups.google.com/group/Google-Web-Toolkit-Contributors

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


 --
 mP

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

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

Re: [gwt-contrib] Re: GWT 2.0.1 breaks incubator 2.0 ... is a new release emminent ?

[David]

I didn't get the chance to test it out, due to corporate red tape :-(

David

On Tue, Feb 9, 2010 at 3:51 PM, John LaBanca jlaba...@google.com wrote:
 I'll take a look and make sure we can use the incubator jar with GWT 2.0.
 Thanks,
 John LaBanca
 jlaba...@google.com


 On Tue, Feb 9, 2010 at 8:35 AM, newnoise tommmuel...@googlemail.com wrote:

 acutally i get the errors in the version downloaded today also.


 On 8 Feb., 16:09, John LaBanca jlaba...@google.com wrote:
  Wow, 2010 already.  Fixed.
 
  Thanks,
  John LaBanca
  jlaba...@google.com
 
  On Sat, Feb 6, 2010 at 8:52 AM, jim n northrup.ja...@gmail.com wrote:
   can you name it 2010x please?
 
   On Feb 4, 8:19 am, Ray Ryan rj...@google.com wrote:
And the jar is posted. All better?
 
On Thu, Feb 4, 2010 at 7:15 AM, Ray Ryan rj...@google.com wrote:
 Sorry, we'll get a 2.0.1 incubator jar up today.
 
 On Thu, Feb 4, 2010 at 7:04 AM, stuckagain david.no...@gmail.com
   wrote:
 
 Hi,
 
 The changes to CurrencyData and CurrencyList as described in the
 release note of GWT 2.0.1 has impact on the current GWT incubator
 CurrencyWidget. Is there a new release planned ? It seems to be
 fixed
 in the trunk of incubator.
 
 This is the compilation error.
 
  [ERROR] Errors in
 'jar:file:/W:/rlsCOTS/gwtincubator/JAVA/lib/gwt-

 incubator.jar!/com/google/gwt/widgetideas/client/CurrencyWidget.java'
     [java]          [ERROR] Line 46: The import
 com.google.gwt.i18n.client.impl.CurrencyData cannot be resolved
     [java]          [ERROR] Line 47: The import
 com.google.gwt.i18n.client.impl.CurrencyList cannot be resolved
     [java]          [ERROR] Line 107: CurrencyData cannot be
 resolved
 to a type
     [java]          [ERROR] Line 122: CurrencyData cannot be
 resolved
 to a type
     [java]          [ERROR] Line 122: CurrencyList cannot be
 resolved
     [java]          [ERROR] Line 123: CurrencyData cannot be
 resolved
 to a type
     [java]          [ERROR] Line 124: CurrencyData cannot be
 resolved
 to a type
     [java]          [ERROR] Line 181: CurrencyData cannot be
 resolved
 to a type
 
 David
 
 --
http://groups.google.com/group/Google-Web-Toolkit-Contributors
 
 --
 I wish this were a Wave
 
--
I wish this were a Wave
 
   --
  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

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

Re: [gwt-contrib] GWT 2.0.1: is the history support iframe now mandatory ?

[David]

Hi,

No as far as I know I have not referenced it anywhere. It used to work
with 2.0, I was trying out the 2.0.1 build to see if the bugs I
reported where correctly fixed, but I seem to stumble on multiple
issues. I am not the only person poking around the codebase (we are
forced to use a ClearCase dynamic view) so it might just be that
someone did some nasty checkin while I was testing.

I'll double check tomorrow.

David

On Thu, Feb 4, 2010 at 4:36 PM, Joel Webber j...@google.com wrote:
 It shouldn't be -- if you kick off History's static initializer, it will
 GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I
 believe it's been this way for a long time. Are you sure you're not
 referencing History somewhere?

 On Thu, Feb 4, 2010 at 10:34 AM, stuckagain david.no...@gmail.com wrote:

 Hi,

 I rebuild my apps with 2.0.1 and noticed that they no longer start.
 In DevMode is see an error about the History Support that fails to
 initialize.

 My apps do not support history, so I did not include the IFrame... has
 this become mandatory or is this a little oops ?

 David

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

Re: [gwt-contrib] Re: r7517 committed - Adding RegExp to public GWT (native version, pure Java version, tests)

[David]

Hi,

The subject of roadmap ... when will we see a 2.0.1 ? We currently
need to run with a patch gwt-servlet) due to a classloading issue
which is now in fixed state in the issue database.

Moving to a Wave would be great! I'm always waving alone :-S... maybe
I can then finally grasp why it is supposed to be so great.

David

On Tue, Feb 2, 2010 at 12:46 AM, Bruce Johnson br...@google.com wrote:
 On Mon, Feb 1, 2010 at 4:05 PM, Sami Jaber sami.ja...@gmail.com wrote:

 I'm agree with Thomas. RegExp integration should have been discussed in
 the list. It is landing into the trunk from nowhere for us...

 I mentioned a couple of weeks ago that we were switching to a different
 version control system -- and this is the first example of the sorts of
 hiccups we thought could happen. A Googler, a GWT user but who is not on the
 GWT team proper, has been working on this as a potential contribution, and
 submitted this patch for a code review. We accidentally approved it for
 commit rather than just giving some positive feedback on the code review.
 Thus, a work in progress got dumped on svn.
 We're still working out what sort of approval process makes sense for these
 sorts of contributions, but for a large change like this involving new API
 surface area, we definitely do want and need open, public discussion.


 Since the 2.0 release, I feel that there is less interaction with the
 contrib list (btw what have been decided for the roadmap ?) and what we are
 supposed to see in the coming releases.

 I think more than anything, you're seeing the effects of a lot of us being
 tired from the GWT 2.0 push. An updated roadmap is still forthcoming, but I
 can summarize a lot of the ad hoc design discussions starting to take place
 like this: we need to fill a lot of gaps in the libraries, especially
 widgets and app framewpork sorts of library code. GWT is powerful at
 present, but it doesn't make it especially easy to create traditional
 business apps quickly. We'd like to change that.


 We can understand that you prefer to use internal waves/lists but please
 let's not forget the openess nature of GWT that contribute to make this
 framework so popular

 It's true that Wave is fantastic for design docs, and it's hard not to want
 to use that instead of email. Maybe the right answer is to get everyone on
 this list to move to Wave :-)

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

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

Re: [gwt-contrib] Re: GWT Incubator Status Update and Schedule

[David]

Hi,

It would be nice that the GWT team would release some development
builds once in a while. That would be very usefull at the point where
new things are added to the trunk. This way you can get a lot more
input from the community, since it makes it much easier to use a more
experimental version of GWT. Compiling from the sources means that we
need direct access to the internet, but not all companies allow that.

As long as we have some indication of what is mostly stable and what
not, we can choose at what point we whish to start using a development
build.

David

On Wed, Jan 20, 2010 at 6:19 PM, monkeyboy dilbert.elbo...@gmail.com wrote:
 Thank you John for your explanation. Now I understand the reason why
 you are shutting down the incubator. What I am suggesting is that
 developers should have a place where they can see what new features
 (libraries,...) are being developed and not to stumble upon this new
 features by chance (like I stumbled upon the doc for
 DataBackedWidgetsDesign for example). You mentioned that you send
 emails when you start a new project. What do I need to do to receive
 such an email?
 I think you guys at Google develop great libraries that are perhaps
 underused because they are hard to find. Let's take Gin for example
 (http://code.google.com/p/google-gin/). I think that more people would
 use it if you had a link to Gin from the GWT Tools and Libraries page.

 Regards.

 On Jan 20, 5:29 pm, John LaBanca jlaba...@google.com wrote:
 Libraries and widgets that we want to incubate will be moved into separate
 projects.  Instead of downloading one incubator jar, you'll be able to (have
 to) download each project individually.  Like Ray said, we're going to
 commit most new features directly to trunk, but we may still want to
 incubate some features if they are highly experimental.  We often setup a
 design doc and send out an email when we start a new project, such as the
 data backed widgets, so the community can be involved.  I'm sure we'll keep
 doing that.

 The advantage of separate projects is that each project can move along at
 its own pace.  The incubator currently has some very stable features, some
 highly experimental ones, and some deprecated code, and it isn't obvious
 which is which (well, except the deprecated stuff).  With individual
 projects, it should be more obvious what the state of the project is.

 Thanks,
 John LaBanca
 jlaba...@google.com

 On Wed, Jan 20, 2010 at 10:57 AM, monkeyboy dilbert.elbo...@gmail.comwrote:

  Then, how about a list of new features in the trunk since the last
  release. That way developers would know if they should become involved
  in the nontrivial (but not too hard) task of compiling GWT from
  source. I take the last comment back if such a list exists. I could
  not find it.

  Regards.

  On Jan 20, 4:26 pm, Ray Ryan rj...@google.com wrote:
   On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy dilbert.elbo...@gmail.com
  wrote:

Hello John.

I'm glad to see that PagingScrollTable will make it to the GWT trunk.
Even now it is a useful widget but I can't wait to see the final
version. I would like to ask a few questions. I am sorry to hear that
the incubator will be shut down. I was wandering what (if anything)
will replace it. With the incubator I as a developer had access to
some tools and widgets that had a great chance to end up in the GWT
trunk so I knew that they had a bigger chance to be supported and I
dared to include them in my projects (eg. PagingScrollTable). I was
burnt a few times with third party gwt libraries found on Google code
for which the developer lost interest after a few months and I was
left with a buggy library without support.

If the incubator is shut down how will we developers be able to find
the new widgets and tools that are being incubated by Google
developers? It is a bit hard to find them browsing trough Google code.
I suggest that You put a couple of links in the Tools and Libraries
section of gwt (http://code.google.com/webtoolkit/tools.html). It
would be very helpful.

   Our intention is to be less bashful about developing things right in the
   trunk.

Regards.

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

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

Re: [gwt-contrib] Re: CssResource unable to handle IE6 AlphaImageLoader

[David]

The bigest problem with the DirectX filter was that it caused a
massive memory leak.

David

On Thu, Jan 14, 2010 at 3:35 PM,  j...@google.com wrote:
 I didn't say it was resolved. The memory-usage issues don't come up
 simply as a function of the number of images -- it's a function of the
 total amount of space consumed by each image. AlphaImageLoader is a
 DirectX filter that allocates a new offscreen buffer for each copy of
 each image displayed, which under some relatively common circumstances
 can get *very* large. This has become a huge problem for some users of
 ImageBundle, because it allocates enough memory for the *entire* image
 strip, over and over again. I've seen apps easily blowing 1G of memory
 this way on IE.

 I'm not suggesting that we shouldn't consider using this hack for
 ImageResources; simply that these are important issues we need to
 consider before committing anything. If we can't find a tradeoff that
 avoids wasting huge amounts of memory, then we need to at least consider
 downgraded images on IE6 (note that this *only* affects IE6, not IE7+).
 While we remain committed to IE6 support, we can't let it hamstring
 every other case.

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

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

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

Re: [gwt-contrib] Re: Failing to find custom field serilializers in Oracle OC4J 10.1.3.5

[David]

I did not file a bug report yet. Do I need to do this or is it already done ?

On Thu, Jan 7, 2010 at 12:20 AM, John Tamplin j...@google.com wrote:
 On Wed, Jan 6, 2010 at 6:01 PM, Lex Spoon sp...@google.com wrote:

 I don't know what the real problem is, but I'm sure that custom
 serializers are not broken in general.  There must be something more
 specific going wrong.  -Lex

 Yes, the problem is that if it isn't on the classpath used to find the GWT
 classes it won't be found.  That can be the case depending on how the
 servlet classpaths are setup.
 We are triaging the bugs to fix in 2.0.1 in the next few days, and I expect
 this one will be included.
 --
 John A. Tamplin
 Software Engineer (GWT), Google

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

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

Re: [gwt-contrib] Re: wrong DTD generated for modules in GEP

[David]

Hi,

Small question:
Is there a reason why GWT is still using a DTD instead of a schema ?
In Schema's you can put a lot extra information (inline docs) and
eclipse also supports completions with schemas if you put the schema
in the XML repository.

David

On Thu, Dec 17, 2009 at 11:59 PM, Fushion menno.van.gange...@gmail.com wrote:
 This one is better:
 http://google-web-toolkit.googlecode.com/svn/releases/2.0/distro-source/core/src/gwt-module.dtd


 On 17 dec, 16:56, Arthur Kalmenson arthur.k...@gmail.com wrote:
 Hey everyone,

 I just noticed that the DTD used in the GWT modules generated by the
 GEP is incorrect. It points 
 tohttp://google-web-toolkit.googlecode.com/svn/tags/2.0.0/distro-source...
 which doesn't exist. Looks like the fix would be pretty easy though,
 just create a 2.0.0 tag in the repo, 
 becausehttp://google-web-toolkit.googlecode.com/svn/tags/2.0.0-rc1/distro-so...
 works.

 All the best,
 --
 Arthur Kalmenson

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

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

Re: [gwt-contrib] now.. afetr GWT 2.0?

[David Clément]

 3) DataBinding  Validation (btw see this post from Ray announcing something
 for Q1 2009 ;-)

For me, it's the main feature GWT should have.
Next would be pretty widgets, Drag'n Drop (in the framework, GWT DnD
is very good, but DnD deserve to be in the framework by itself).
And on top of it, yes, the WYSIWYG Eclipse plugin (with databing and
validation, it could make people more easily start with GWT!)

Thank you for the usefull features of 2.0 (just devMode in Firefox is worth it)!

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

Re: [gwt-contrib] Making command pattern RPC look like traditional GWT RPC

[David]

Hi,

I follow what you are trying to do, it would solve some complexity on
the server side.

But one of the main benefits of using the command pattern is that you
only need one client API call. In case of GWT it means that you write
onesync and async interface with one method... and from there on you
can add commands without having to update these interfaces. On the
server side you have one servlet that can use Guice to inject the
handlers so you can implement handlers as POJOs. That is easier for
testing and you don't need to extend the RPC servlet class everywhere.

You should maybe look at something like gwt-dispatcher that implements
the command pattern. I don't like the fact that I need to define that
many classes (request,result, handler and registere the handler), but
I guess there can be solutions to improve upon that design as well
(introspection to find the handler automatically for example).


David

On Thu, Nov 19, 2009 at 6:52 AM, Jamie Gennis jgen...@gmail.com wrote:
 Hi all,
 I've been writing a GWT library to implement the command pattern for GWT RPC
 calls using the same interfaces that traditional GWT RPC uses.  Basically,
 when an app calls a method of the FooAsync action service interface, an
 action object is created from the method arguments, processed by some action
 filters on the client, then passed to the server.  The server then pulls the
 method arguments out of the action object and passes them as arguments to
 the appropriate method of the Foo interface implementation class.  The
 return value (or thrown Throwable) from that method then gets put into an
 action result object on the server and sent back to the client, where it
 gets processed by filters and eventually has the return value or throwable
 pulled out and passed to the onSuccess or onFailure methods of the async
 callback.
 I have a working (albeit not extensively tested)
 google-web-toolkit-contribut...@googlegroups.comimplementation
 at http://code.google.com/p/gwt-remote-action/, but the implementation
 relies on some GWT internals, so it's rather brittle at the moment. I'd like
 to get some feedback on how I can change my implementation to be more
 future-proof (or correct if it isn't), and which (if any) of the GWT
 internals that I'm using might be candidates for becoming a part of GWT's
 public interface.
 The tricky part of the implementation is the action result.  The purpose of
 an action result object is to encapsulate the result of executing an action
 in such a way that action filters can manipulate it without having any
 knowledge of what the action was.  It needs to contain an arbitrary return
 value object or an arbitrary Throwable object (as well as an indication that
 the Throwable was thrown rather than returned).  These objects are exposed
 via the ActionResult interface.  Simply having a general action result class
 that contains a return value field of type Object and an exception field of
 type Throwable is not desirable because it would cause deserialization code
 for every class that GWT knows about to be included in the compiled
 javascript.
 The current implementation works by generating one action result class for
 each RPC method.  Identical action result classes are generated by a GWT
 Generator at gwtc-time (for the client) and via Java byte code generation at
 run-time (for the server).  My original idea was that this method-specific
 action result class could have a result field of the specific return type of
 the method along with a field for each type in the method's throws list.
  This turned out not to be necessary (at least for the cases I've tested),
 because when GWT calls the Generator for the ActionExecutionService (the
 traditional GWT RPC that sends the action objects to the server) it doesn't
 find any of the generated method-specific action result classes.  Because of
 this I simplified the action result classes to just have one field of type
 Throwable, and I verified that not all the Throwable classes get included in
 the deserializable classes list in the *.rpc.log files.  I'm not sure that
 this behavior doesn't depend on GWT.create being called in a specific order
 or something else I'm not aware of, but that should be solvable by splitting
 the throwables into multiple fields if needed.
 Generating the action result classes after the ActionExecutionService gets
 generated means that none of the deserializers for the return values and
 throwables of the action methods get generated or rescued.  To get around
 this I:

 Make the ActionExecutionService use the new deRPC implementation rather than
 the previous RPC implementation
 Use the RpcProxyCreator class to generate a dummy implementation of a deRPC
 proxy for the action service (this proxy doesn't get used)
 Add an @ArtificialRescue to the generated action service proxy to rescue the
 _TypeOverridesFactory class that the RpcProxyCreator generated.  This
 _TypeOverridesFactory class has all

[gwt-contrib] Re: will deRPC ship with GWT 2.0 ?

[David]

Hi,

Just my opinion, so take my strong statements with a grain of salt as
I have a tendency to see my problems as being the most important in
the world :-) But you were asking for input, right ?

GWT is being pushed as THE tool for AJAX development. The RPC part is
fundamental to the AJAX experience yet it does not scale very well
beyond a Hello World or Twitter client. And for the Twitter client one
could argue that you really need a standard implementation for push
messaging instead.

RPC is really bad with object graphs. If you have a tree or linked
list you don't need a lot of nodes to see it crash with a stack
overflow. Sending larger payloads is also the best way to make the app
stall.

The current RPC is just fundamentally broken in the implementation
that maybe it does not deserve to be in GWT 2.0 either.

I do not see any need to move my code to GWT 2.0 if the RPC is not
fixed. The new UI features are nice to have but not critical to the
applications. The JS optimisations do not make a lot of difference
since our UI's are not really CPU bound. The new widgets or declartive
UI part is nice, but we can do without - a faster table/tree
implementation in the trunk would be very usefull (the incubator seems
to be dead ?) since it is the main reason why people select ExtGWT or
other GWT widget sets (which do not really use GWT the way they
should).

The only thing that is really missing in GWT is a decent RPC that can
be trusted to just work.

David

On Mon, Oct 19, 2009 at 9:49 PM, Bruce Johnson br...@google.com wrote:
 So, here's the deal on deRPC. It doesn't yet have the miles on it that we'd
 like, so we're pretty much on the fence as to whether to really ship it in
 GWT 2.0 or not.
 It has been included in MS1 and will be in MS2, but we may still make a no
 go decision before the GWT 2.0 RC comes out.
 If you (as in, anyone reading this email) have tried the new RPC stuff and
 have feedback, now would be the right time to give it a thumbs up or thumbs
 down. At the moment, we're leaning thumbs down -- mainly to be conservative.
 -- Bruce
 On Mon, Oct 19, 2009 at 3:45 PM, Sami Jaber sami.ja...@gmail.com wrote:

 Following a question I asked privately to Bruce and Amit.
 Thanks for your response gwitters

 Sami

 On Mon, Oct 19, 2009 at 9:38 PM, Bruce Johnson br...@google.com wrote:

 Sami, would you mind asking this question directly on the Contributors
 list? We can answer it so that everyone has a chance to comment.
 Thanks.


 On Sat, Oct 17, 2009 at 1:46 AM, Sami Jaber sami.ja...@gmail.com
 wrote:

 Bruce,

 What is the status of deRPC API in GWT 2. The code is in the trunk, it
 seems to be work very well (at least with my test cases) but nothing in 
 GWT
 MS1 Amit announce and very few gwtc posts regarding the API/issue.
 Are you planning to ship deRPC with GWT 2 (I would love to regarding
 all the JDO/AppEngine integration) ? Similarly, are you planning to 
 update
 GPE to conform to the new interfaces, RpcService, RpcServlet, etc ...
 (http://code.google.com/eclipse/docs/gwt_rpc.html) ?

 Thanks for you response,

 Sami





 


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