Direct IDE still has benefits. Anytime a change is made to the build file that requires regenerating the project, you run the risk of not preserving project settings by overwriting stuff that is stored in those files that is not part of the build, unless your generator has surgical capabiltiy (like the IDE does).
IntelliJ has surgical Maven capability. If you import some dependency, it can automatically offer to add it to a pom file, and if you edit the pom file, it can automatically update the build dependencies in the IDE file. It's just faster roundtripping. That said, I am not opposed to writing a plugin or genrule for Buck to do this. I would only say that if we are going to move to Buck, a prerequisite is that we restructure the code the way Thomas has been moving to work more like it does in Google3. Instead of one 'dev' dir and one 'user' dir, each subdirectory that houses a major component should have a build file in it. I should be able to rebuild say, the javac/jdt stuff without rebuilding all of gwt-dev while developing. Things need to be more modular. On Thu, Sep 26, 2013 at 3:35 PM, Brian Slesinsky <skybr...@google.com>wrote: > > On Thu, Sep 26, 2013 at 10:26 AM, Jens <jens.nehlme...@gmail.com> wrote: > >> >>> In terms of Gradle vs Buck models, is there any possibility of writing >>> a tool that takes a Buck build file and produces Gradle files? That would >>> seem like a good option in lieu of waiting for Buck support in IntelliJ and >>> Eclipse. This isn't to say I have anything against Buck, it is literally a >>> clone of Google's BUILD system, and so that would actually help us to have >>> just one set of build files for internal vs external. However, it would be >>> nice not to have to hack the IDE stuff manually. >>> >>> If Buck is like Google's BUILD, then a genrule could be used to download >>> dependencies from Maven repos. ;-) >>> >> >> Shouldn't it be the other way around? A Gradle plugin that generates >> Google build files sounds more logical to me as you have more freedom to >> adjust the generated files to your internal system. Outside Google no one >> will really use these buck/internal build scripts anyways (lack of IDE >> support). >> > > I don't think direct IDE support for the build system is necessary so long > as we can generate correct IDEA and Eclipse projects via commands that > everyone can run, sort of like the webAppCreator command. The real question > is what language we want the project definitions to be in; it should be > something easy to understand, edit, and generate other representations from. > > -- > 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.
