I just thought I'd throw some weight behind Gradle (and GradleFx) as an excellent build platform. Just this week I moved 90% of our build from Ant, and it has been a breath of fresh air. We have an AIR app with 10+ libraries, Flex monkey patches, compiled CSS swfs, reliance on lots of 3rd party libraries, etc. It is a pretty good real-world test.
I have found Ant to be verbose and difficult to read, whereas many of my Gradle scripts to compile my sub-projects were about 6 lines long, including braces. If my sub-projects follow convention, the scripts are literally 0 lines long. Here were the pros as I saw them: * Access to a real language (including if statements). No more "coding" in XML to do trivial things. "If" statements are naturally supported and don't require a 3rd-party add-in. ;) * Build server and fellow developers don't even need Gradle installed. Gradle knows how to bootstrap itself. * I don't know the first thing about Maven, but it was easy tell my script, "Hey, you need these plugins to run this script," and it took care of the rest. * I could *easily* change the "convention" in the "convention over configuration". Since my 10+ projects use conventions that were slightly different than GradleFx, it was easy to say things like "source lives here unless you're told otherwise." or "Use these common compile parameters for most builds." * Gradle is naturally structured the way that I already thought about my builds: I've got one main master project I'm trying to build, and then lots of sub-projects that depend on each other and that generally look alike. If a sub-project doesn't break convention, it doesn't even need its own build script! * Native integration with Ant for tasks you don't want to rewrite. Just tell it to "import build.xml" and it exposes all of your ant tasks natively. We had a few Ant tasks that I haven't moved over yet, so this was perfect. If the only thing we use Gradle for is running the legacy ant build, I think it would be worth it! :) * Easy integration with TeamCity (our CI server), or your build server of choice. * Excellent documentation * The GradleFx guys were responsive when I filed a couple of minor issues in GitHub. Cons: * Maybe I'd spent too long in the Ant world, but when I wanted an easy way to have different properties files that were used in different contexts (dev machine overrides, build server, etc), I had to turn to a plugin: http://wiki.gradle.org/display/GRADLE/Plugins#Plugins-JavaPropFilePlugin (Not a huge con: This plugin worked great, and it downloads and installs itself as part of my build) * There were a few times where the cleverness of the syntax/DSL was too clever for me. Most of the time it's unnoticed, but sometimes I found myself wanting/needing to know when certain closures were going to be evaluated. *When debugging my build, I had a choice between "Just tell me the error, but don't give me enough info to fix it." (default) or "run in debug mode and give me a LOT to read through." I didn't find the switch for "Tell me what Ant is trying to execute here, but don't tell me about the Gradle internals". It wasn't too bad. Just meant a lot of scrolling through debug statements. In short, even if we don't use Gradle and GradleFx for building the FlexSDK, you should check it out for your own projects. Cheers, Taylor Brown On Sat, Feb 11, 2012 at 10:26 AM, Yennick Trevels <yennick.trev...@gmail.com > wrote: > Hi, I'm the Co-founder of the GradleFx project, a plugin for the Gradle > build system to compile Flex projects. > I'm also interested in evaluating Gradle/GradleFx to build the Flex SDK, > because I think Gradle will benefit us in the long term. Gradle has > basically all the good things from Ant and Maven, without most of the > disadvantages. > These are some of its features: > > - Convention-over-configuration > - Advanced multi-project support > - Dependency Management (better handling of transitive dependencies) > - Groovy scripting instead of xml > - Support for Maven and Ivy repositories > - Source file change detection (only recompiles the projects which have > changed) > - Very easy to add custom build logic > > All this leads to a much shorter build script which is easier to customize > and understand. > > Gradle can be found here: http://www.gradle.org > GradleFx can be found here: http://gradlefx.github.com > Some GradleFx sample projects can be found here: > https://github.com/GradleFx/GradleFx-Examples > On Sat, Feb 11, 2012 at 12:18 PM, Yennick Trevels <yennick.trev...@gmail.com > wrote: > > *) The SDK (and some applications) has code that is timezone specific > > (different output in a different timezone): > > Does Gradle support to run the same tests in different environments > > and eventually compiler settings? > > > > There are two ways to do this: > > - init scripts: > http://gradle.org/docs/current/userguide/init_scripts.html > - configuration file: > > http://mrhaki.blogspot.com/2009/11/gradle-goodness-using-properties-for.html > > > > > *) Some of the functionality might require to be tested against the adl > > and not the flash player, does that work? > > > > GradleFx has support for FlexUnit, which supports running tests against > ADL. We support all the properties exposed by FlexUnit, so you configure > FlexUnit the way you like. > For more information about those options see the GradleFx properties > documentation: > https://github.com/GradleFx/GradleFx/wiki/Properties-conventions > More information about testing with FlexUnit in GradleFx can be found here: > https://github.com/GradleFx/GradleFx/wiki/Flexunit >
