[gwt-contrib] Disabling patches on code.google.com?

2013-09-24 Thread Thomas Broyer
Can someone with admin rights on the code.google.com/p/google-web-toolkit disable submitting patches? We're starting to receive spam through patches: https://code.google.com/p/google-web-toolkit/issues/detail?id=8362 Now that we moved to googlesource.com, we don't need comments on source code

Re: [gwt-contrib] Disabling patches on code.google.com?

2013-09-24 Thread Daniel Kurka
Should be turned off now. -Daniel On Tue, Sep 24, 2013 at 10:19 AM, Thomas Broyer t.bro...@gmail.com wrote: Can someone with admin rights on the code.google.com/p/google-web-toolkitdisable submitting patches? We're starting to receive spam through patches:

Re: [gwt-contrib] Disabling patches on code.google.com?

2013-09-24 Thread Thomas Broyer
On Tuesday, September 24, 2013 11:56:29 AM UTC+2, Daniel Kurka wrote: Should be turned off now. Thanks. BTW, I just noticed the home page links to the /source/checkout page, bypassing our custom Source tab page. That would explain why some people don't see that page (which explains the

[gwt-contrib] Bad news for GWT DevMode!

2013-09-24 Thread Thomas Broyer
Just saw this passing on Twitter: http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html This is really bad for DevMode in Chrome (maybe also in Firefox, which was already a nightmare). Means we really need to improve SuperDevMode, or find a non-NPAPI way to plug into the

Re: [gwt-contrib] Disabling patches on code.google.com?

2013-09-24 Thread Daniel Kurka
I think there is no way to modify that page (I think we need to remove the svn in order to get rid of it). Maybe we should revisit take the whole svn down (maybe after we completely switched to maven) -Daniel On Tue, Sep 24, 2013 at 1:01 PM, Thomas Broyer t.bro...@gmail.com wrote: On

Re: [gwt-contrib] Disabling patches on code.google.com?

2013-09-24 Thread Thomas Broyer
On Tuesday, September 24, 2013 1:32:54 PM UTC+2, Daniel Kurka wrote: I think there is no way to modify that page (I think we need to remove the svn in order to get rid of it). I was rather talking about fixing the link ;-) Maybe we should revisit take the whole svn down (maybe after we

[gwt-contrib] Re: Maven-ization Status

2013-09-24 Thread Cristiano
Hi folks, I read and hear about the Maven-ization of GWT, which is something I would love because I love maven. However I've found it difficult to understand what does it means... I've checked out the latest source code and I see it is still based on ant build... On the repo there is only a

[gwt-contrib] Re: Maven-ization Status

2013-09-24 Thread Thomas Broyer
On Tuesday, September 24, 2013 2:41:10 PM UTC+2, Cristiano wrote: Hi folks, I read and hear about the Maven-ization of GWT, which is something I would love because I love maven. I used to really like it; not so sure nowadays, therefore exploring Buck and Gradle. However I've found it

Re: [gwt-contrib] Re: Maven-ization Status

2013-09-24 Thread Cristiano Costantini
I used to really like it; not so sure nowadays, therefore exploring Buck and Gradle. wow, I know it could cause issues if not used in the proper way, I have now addressed multiple issues and I'm very satisfied with maven even if I continue to improve it day after day. Apache Camel and Apache

Re: [gwt-contrib] Re: Maven-ization Status

2013-09-24 Thread John A. Tamplin
On Tue, Sep 24, 2013 at 10:37 AM, Thomas Broyer t.bro...@gmail.com wrote: It means two things: - replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build tools) Yeah, I guess that is why I spent half of yesterday getting a build to work in

Re: [gwt-contrib] Re: Maven-ization Status

2013-09-24 Thread Thomas Broyer
On Tuesday, September 24, 2013 5:48:03 PM UTC+2, Cristiano wrote: I used to really like it; not so sure nowadays, therefore exploring Buck and Gradle. wow, I know it could cause issues if not used in the proper way, I have now addressed multiple issues and I'm very satisfied with

Re: [gwt-contrib] Re: Maven-ization Status

2013-09-24 Thread Thomas Broyer
On Tuesday, September 24, 2013 5:51:33 PM UTC+2, John A. Tamplin wrote: On Tue, Sep 24, 2013 at 10:37 AM, Thomas Broyer t.br...@gmail.comjavascript: wrote: It means two things: - replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build

[gwt-contrib] Possible firefox leak fix

2013-09-24 Thread Colin Alworth
I spent a little time this weekend learning how to build firefox plugins, and a little time spilled out into this week, but I think I'm at a point where I can share what I've done, what I'm seeing, and start asking for help to finalize this (if it is as meaningful as I hope it is). First, the

Re: [gwt-contrib] Possible firefox leak fix

2013-09-24 Thread Colin Alworth
The patch I provided only tweaks the normal source, and leaves the generated sources and binaries alone - I think that is already what you are after. Note that this does *not* stop the leak by itself - we need to decide what to do about hosted.html/devmode.js. One (ugly) option is to try to

Re: [gwt-contrib] Possible firefox leak fix

2013-09-24 Thread Brian Slesinsky
+cromwellian since he did unload support. Oops, I see now that you attached it. Could you upload it to Gerrit? I looked pretty hard for a reason why it's window.onUnload and not window.onload and I can't find any. It dates back to 2010 at least and was copied from hosted.html, whether

Re: [gwt-contrib] Possible firefox leak fix

2013-09-24 Thread Colin Alworth
Done, change is at https://gwt-review.googlesource.com/4680. Concern about breaking WindowImpl#initWindowCloseHandler was my guess as well - after connect() is called and the app starts up, the app has already wired up its own close handler, so it is too late when connect is successful to