Re: [gwt-contrib] Re: In the Chrome plugin, rename src to java for compatibility with (issue1834803)
On Tuesday, September 18, 2012 7:43:25 AM UTC+2, Brian Slesinsky wrote: On Mon, Sep 17, 2012 at 10:37 PM, Stephen Haberman stephen@gmail.com javascript: 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. At least Ray has expressed his willingness that we go that far. Well, that's just an assumption - I don't really know what the plan is. Maybe it's easier with Maven? It requires (well, it doesn't strictly *require* it actually) moving files around (one subdir per JAR to be built, with its own src/main/java and src/test/java) but dependency management is much easier (similar to BUILD: you declare dependency on an artifact/JAR and bam, you have it in your buildpath/classpath; and the build can trigger cascading rebuilds of dependent modules) -- 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 Tue, Sep 18, 2012 at 3:30 AM, Ray Cromwell cromwell...@google.comwrote: I favor splitting things up into reasonable chunks that have coherence. e.g. Logging, RPC, RequestFactory, Editors, UI Widgets, ClientBundle, Core, Events, Dom, etc. For example, I should be able to get away with consuming Core + Logging (in reality, I probably can't because of the Widget based debug panel), or Core + Logging + Dom + Events (pure DOM based app, no Widget framework, no RPC, etc) One reason for doing this is faster builds. The fewer classpath entries, the better. Secondly, I think it gives people a better idea of what you're using. IMHO, inheriting User.gwt.xml is the GWT equivalent of import com.google.gwt.user.client.ui.*, it's a star import. We can still have a uberjar gwt-user module, but other people can start have fewer dependencies if they want. Plus, when hacking on GWT itself, if I modify say, ClientBundle, I don't end up rebuilding everything if my app doesn't depend on it. The only caveat there is if you break it up into smaller chunks you can't have circular dependencies between the chunks. I think that means that some things will have to get promoted to core that otherwise wouldn't, unless some effort is made at refactoring things (which might be a breaking change). -- John A. Tamplin -- 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
[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
