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
It really depends on what Thomas or contributors are going to do, I don't
think we have any bandwidth on the GWT team to work on this right now ;-)
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
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
I have been in favor of Buck because that is what most contributors are
already familiar with and can bring their expertise. It is already proved
to work well with gwt.
Also the compiler speed optimizations are done and experimented based on
the architecture of Buck; especially new stuff that John
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
On Thursday, September 26, 2013 3:35:15 AM UTC+2, Ray Cromwell wrote:
Thomas,
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
On Thursday, September 26, 2013 7:26:45 PM UTC+2, Jens 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
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
At Google our BUILD files are distributed throughout the source directories
as we try to make them as simple as possible with as strict dependencies as
possible. I'd love to have a Buck file that could compile
gwt-dev/user/servlet, but it would be even better if there was one for each
and every
For reference, here are my gripes with Maven:
http://blog.ltgt.net/maven-is-broken-by-design/
Yes I've seen, I'm preparing a reply ;-)
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Wow, colin you're on fire recently with your contributions. ;-)
On Tue, Sep 24, 2013 at 6:48 PM, Colin Alworth niloc...@gmail.com wrote:
Done, change is at https://gwt-review.googlesource.com/4680.
Concern about breaking WindowImpl#initWindowCloseHandler was my guess as
well - after
On Friday, September 27, 2013 1:33:10 AM UTC+2, Ray Cromwell wrote:
At Google our BUILD files are distributed throughout the source
directories as we try to make them as simple as possible with as strict
dependencies as possible. I'd love to have a Buck file that could compile
Il giorno venerdì 27 settembre 2013, Goktug Gokdogan ha scritto:
I have been in favor of Buck because that is what most contributors are
already familiar with and can bring their expertise.
This is a good point which need to be taken into account.
But I've found frustrating buck cannot be
I finally manage to come back to this; sorry for the delay.
@Jens: What you are suggesting (i.e. plugins) makes sense. But right now
compiler doesn't really have a real understanding of user agents and that
is a much bigger change than what I'm am planning here.
@Colin: If CssResource generator
I skimmed the Gradle manual and it looks pretty decent. While the syntax
and terminology is different, it looks like the concepts map back to stuff
I'm already comfortable with.
It has tasks which are basically build rules which are configured via
Groovy (instead of Python macros). The tool
15 matches
Mail list logo
