[gwt-contrib] Re: Update Maven sample pom.xml files to use maven-compiler-plugin's annotation processing functiona... (issue1828803)
LGTM Note that Mac users may have to refresh the project after first import in order to force APT to run. http://gwt-code-reviews.appspot.com/1828803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Update Maven sample pom.xml files to use maven-compiler-plugin's annotation processing functiona... (issue1828803)
Thanks David - when I tested on the mac, I didn't have to refresh the project after first import provided that I actually did an Update Project after enabling Maven Annotation Processing on the project. I noted this in bold on the Wiki page. On Mon, Sep 17, 2012 at 9:15 AM, drfibona...@google.com wrote: LGTM Note that Mac users may have to refresh the project after first import in order to force APT to run. http://gwt-code-reviews.**appspot.com/1828803/http://gwt-code-reviews.appspot.com/1828803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Update Maven sample pom.xml files to use maven-compiler-plugin's annotation processing functiona... (issue1828803)
http://gwt-code-reviews.appspot.com/1828803/diff/9001/samples/dynatablerf/pom.xml File samples/dynatablerf/pom.xml (right): http://gwt-code-reviews.appspot.com/1828803/diff/9001/samples/dynatablerf/pom.xml#newcode120 samples/dynatablerf/pom.xml:120: version2.3.0-1/version Oh, I'm really sorry I let it slip through: the plugin should be updated to 2.5.0-rc1 here, or the (unfortunate) gwt-servlet dependency has to be reintroduced (and possibly the plugin updated to 2.4.0). And the validation sample should also benefit from this change (it too apparently needs a bit of love: https://groups.google.com/d/topic/google-web-toolkit/D2nrOqJeMmA/discussion) http://gwt-code-reviews.appspot.com/1828803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] submit chrome dev mode plugin to chrome web store?
+[skybrian] Ok, so it looks like we'll have to go ahead and rebuild the crx on our side. I've added Brian, who has been playing around with the crx build process. On Wed, Sep 12, 2012 at 7:33 PM, Daniel Kurka kurka.dan...@gmail.comwrote: Hi Rajeev, I just gave it a try and it seems that we need to do some actual changes to make this work. The chrome web store is complaining about the manifest version of the plugin: An error occurred: Manifest version 1 is unsupported. Please upgrade to manifest version 2. I will give this another look tomorrow. It`s getting too late in Germany right now. -Daniel Am 13.09.2012 um 01:09 schrieb Rajeev Dayal rda...@google.com: Sorry, this totally fell off the plate. Daniel, would you be able to submit it to the Chrome Webstore? On Wed, Sep 12, 2012 at 7:07 PM, Daniel Kurka kurka.dan...@gmail.comwrote: Hi Rajeev, what is the status here? Can I help? -Daniel Am 19.08.2012 um 17:10 schrieb Robert Hanson iamroberthan...@gmail.com: @Rajeev, you mentioned that you were going to post the plugin to the Chrome store. Is that still the plan, or did you run into some issues there? I'm working on some documentation that is about to go to press, and just want to make sure I have the right instructions in there. Thanks. Rob On Tue, Aug 7, 2012 at 11:39 AM, Rajeev Dayal rda...@google.com wrote: Hey Daniel, We do need to post the chrome devmode plugin to the webstore. I'll take care of that this week. I also need to rebuild the devmode plugin, as there were some fixes that went into it a while back that were never put into a distributable binary. Rajeev On Mon, Aug 6, 2012 at 6:53 PM, Istvan Soos is...@google.com wrote: Hi, A quick fix that might help: 1. right click on the chrome iconPropertiesShortcut 2. add in target: --enable-easy-off-store-extension-install 3. open chrome and navitage to extensions ( chrome://chrome/extensions/) 4. drag and drop on it the plugin (should be in your download folder if you tried to install it before and didn't succeed) Regards, Istvan On Mon, Aug 6, 2012 at 12:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Hi everyone, today at work I was setting up a GWT installation on windows for a new coworker and noticed that with chrome 21 we can not install extension anymore. (They need to be in the chrome web store). I also noticed an issue popping up on the issue tracker on the exact same thing: http://code.google.com/p/google-web-toolkit/issues/detail?id=7569 Does anyone have this covered or are we just hearing about this change to chrome right now? -Daniel -- 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 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] submit chrome dev mode plugin to chrome web store?
Yep, back on the Chrome plugin this week. On Mon, Sep 17, 2012 at 9:26 AM, Rajeev Dayal rda...@google.com wrote: +[skybrian] Ok, so it looks like we'll have to go ahead and rebuild the crx on our side. I've added Brian, who has been playing around with the crx build process. On Wed, Sep 12, 2012 at 7:33 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Hi Rajeev, I just gave it a try and it seems that we need to do some actual changes to make this work. The chrome web store is complaining about the manifest version of the plugin: An error occurred: Manifest version 1 is unsupported. Please upgrade to manifest version 2. I will give this another look tomorrow. It`s getting too late in Germany right now. -Daniel Am 13.09.2012 um 01:09 schrieb Rajeev Dayal rda...@google.com: Sorry, this totally fell off the plate. Daniel, would you be able to submit it to the Chrome Webstore? On Wed, Sep 12, 2012 at 7:07 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Hi Rajeev, what is the status here? Can I help? -Daniel Am 19.08.2012 um 17:10 schrieb Robert Hanson iamroberthan...@gmail.com: @Rajeev, you mentioned that you were going to post the plugin to the Chrome store. Is that still the plan, or did you run into some issues there? I'm working on some documentation that is about to go to press, and just want to make sure I have the right instructions in there. Thanks. Rob On Tue, Aug 7, 2012 at 11:39 AM, Rajeev Dayal rda...@google.com wrote: Hey Daniel, We do need to post the chrome devmode plugin to the webstore. I'll take care of that this week. I also need to rebuild the devmode plugin, as there were some fixes that went into it a while back that were never put into a distributable binary. Rajeev On Mon, Aug 6, 2012 at 6:53 PM, Istvan Soos is...@google.com wrote: Hi, A quick fix that might help: 1. right click on the chrome iconPropertiesShortcut 2. add in target: --enable-easy-off-store-extension-install 3. open chrome and navitage to extensions ( chrome://chrome/extensions/ ) 4. drag and drop on it the plugin (should be in your download folder if you tried to install it before and didn't succeed) Regards, Istvan On Mon, Aug 6, 2012 at 12:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Hi everyone, today at work I was setting up a GWT installation on windows for a new coworker and noticed that with chrome 21 we can not install extension anymore. (They need to be in the chrome web store). I also noticed an issue popping up on the issue tracker on the exact same thing: http://code.google.com/p/google-web-toolkit/issues/detail?id=7569 Does anyone have this covered or are we just hearing about this change to chrome right now? -Daniel -- 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 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
Do you think it would be possible to share the BUILD file(s), or a stripped-down version of it, even privately? I'd love to see how it compares to Maven and other build systems. Now back to the CL: given the move to Git soon, which will require some changes on your side, is it wise to make such a change now? I mean, MOE [1][2] for instance can very well sync external src to internal java (transmogrify as they call it). On the other hand, given that the new Git repos will be populated from Google's internal repo, maybe the answer to the above is yes, and take advantage of the repo move to transmogrify them back to src (along with rollbacking the changes to the Ant files) outside Google. [1] http://code.google.com/p/make-open-easy/ [2] http://code.google.com/p/moe-java/ On 2012/09/17 19:13:46, skybrian wrote: This is a good place for an experiment, since in practice, very few people build the plugins. The bigger picture is that we don't particularly like BUILD files that call ant, since they slow down builds for everyone at Google. There's no reason to rebuild every GWT app and run all the tests because one Java file in gwt.user changed that most people don't even use. Outside Google, people seem to prefer Maven, and I expect we won't want to use that internally either. So I'd like to see if we can just build GWT code directly. If Google can move away from ant and open source moves to Maven, we'll end up with two independent build systems instead of three that are intertwined. (Or four, if you count the plugin Makefiles. But I doubt we can get rid of those.) - Brian On Mon, Sep 17, 2012 at 11:45 AM, mailto:j...@jaet.org wrote: So why not do it in the BUILD file the same way the rest of GWT does, which also doesn't have a java directory? http://gwt-code-reviews.appspot.com/1834803/ http://gwt-code-reviews.appspot.com/1834803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
On 2012/09/17 20:43:56, tbroyer wrote: Do you think it would be possible to share the BUILD file(s), or a stripped-down version of it, even privately? There's a high-level overview here: http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.html It doesn't explain the GWT-specific rules, but conceptually they're not that different from the cc_library rules, or a Makefile for that matter. Since you name the files you want to include (often using globs), anything not named isn't a build dependency, so the compiler won't see it and changes don't force a recompile. We normally have separate build rules for each GWT module and apps can declare what they use. is it wise to make such a change now? I'm not suggesting doing the larger changes any time soon. As I said, this is an experiment. But I'm wary of using remapping to make open source and internal directory structures look different. I think it will make things like applying patches more complicated; we won't be able to just use the patch command. It seems like we should be able to find a compromise that lets us keep the directory structures identical, and that's one less thing for maintainers to worry about. I know ant is very flexible when it comes to directory structure; can Maven be configured as well? http://gwt-code-reviews.appspot.com/1834803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] In the Chrome plugin, rename src to java for compatibility with (issue1834803)
LGTM. I mean, ideally it would be src/main/java :), but Maven can cope with any directory name for this. On Mon, Sep 17, 2012 at 11:36 AM, skybr...@google.com wrote: Reviewers: cromwellian, Description: In the Chrome plugin, rename src to java for compatibility with Google's internal build system. Please review this at http://gwt-code-reviews.appspot.com/1834803/ Affected files: M plugins/npapi/DevModeOptions/build.xml A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/DevModeOptions.extra.xml A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/client/DevModeOptions.java A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/client/DevModeOptions.ui.xml A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/client/DevModeOptionsResources.java A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/client/HostEntry.java A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/client/HostEntryStorage.java A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/client/LocalStorage.java A plugins/npapi/DevModeOptions/java/com/google/gwt/devmodeoptions/client/resources/DevModeOptions.css D plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml D plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/client/DevModeOptions.java D plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/client/DevModeOptions.ui.xml D plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/client/DevModeOptionsResources.java D plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/client/HostEntry.java D plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/client/HostEntryStorage.java D plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/client/LocalStorage.java D plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/client/resources/DevModeOptions.css -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Regarding Issue 1601804: Fix leak in LayoutImplIE6
(I seem to be unable to post this comment to the code review...) In regards to the code review posted at http://gwt-code-reviews.appspot.com/1601804, I would love to see this land in 2.5, as we have some large customers who are still using IE7. And, no surprise, we're having some memory issues... Unfortunately, when I applied this patch to our code base, part of our app failed to render. The problem seems to be in the LayoutImplIE6 class, though I'm not sure exactly what's going wrong. Clearly the DOM is generated differently, and that's expected. If someone can provide a pointer or some more details on how the layers are supposed to be used in the onAttach now vs. previously, I will try to take a look and get a better understanding of what's going wrong. Thanks, jay -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
http://gwt-code-reviews.appspot.com/1834803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
There's no reason to rebuild every GWT app and run all the tests because one Java file in gwt.user changed that most people don't even use. Just to understand more, how does avoiding ant solve the problem? If RarelyUsedFile.java in gwt-user changes, then from my reading of the blog post, the gwt-user input/digest would have changed, so the gwt-user label would be considered dirty, so it seems like all downstream projects would have to rebuild it anyway. Regardless of ant being used or not. Unless ant's output is not deterministic? Just curious. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
It doesn't explain the GWT-specific rules, but conceptually they're not that different from the cc_library rules, or a Makefile for that matter. Just curious, but would stealing Lex Spoon's scala-gwt approach (writing .jribble ASTs to disk, like .class files), allow the Google build system to do more incremental analysis and so less recompilation? E.g.: 1. IDE or CLI compiles .java - .jribble (resolved AST) 2. PrecompileModule bundles .jribble - .gwtars 3. Compiler uses .jribble+.gwtars to generate .js output I guess the unit cache/gwtars were supposed to already solve this (avoiding reparsing of the AST), by caching ASTs. But then why do we still have the slow startup? E.g. why is not everything like primed superdevmode refreshes (which I, sigh, have still not played with yet)? - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
On Mon, Sep 17, 2012 at 8:22 PM, Stephen Haberman stephen.haber...@gmail.com wrote: Just to understand more, how does avoiding ant solve the problem? If RarelyUsedFile.java in gwt-user changes, then from my reading of the blog post, the gwt-user input/digest would have changed, so the gwt-user label would be considered dirty, so it seems like all downstream projects would have to rebuild it anyway. Yes, that's true, nothing changes if there's one build target for gwt-user.jar and every project uses it and it includes everything. But if we split things up into separate build targets (and associated jars) for different GWT modules, downstream projects can declare what they use. (For example, it seems reasonable to require projects to declare where they're using GWT-RPC or RequestFactory or GWTTestCase.) Ideally there would be a jar for each GWT module, though I doubt we'll get that far. I'm assuming we don't want to duplicate the dependency tree in three places (GWT modules and Ant and Google's build), nor do we want to divide up the open source build into that many jars. - Brian -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
But if we split things up into separate build targets (and associated jars) for different GWT modules, downstream projects can declare what they use. Cool, makes sense, thanks for the sanity check. nor do we want to divide up the open source build into that many jars. I dunno, I assumed we were headed towards 1 module == 1 jar, but would defer to others/Thomas since he's been working on it. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
On Mon, Sep 17, 2012 at 10:37 PM, Stephen Haberman stephen.haber...@gmail.com wrote: nor do we want to divide up the open source build into that many jars. I dunno, I assumed we were headed towards 1 module == 1 jar, but would defer to others/Thomas since he's been working on it. Well, that's just an assumption - I don't really know what the plan is. Maybe it's easier with Maven? - Brian -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
