incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taylor Brown <tay...@taytay.com>
Subject Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
Date Sat, 11 Feb 2012 11:31:18 GMT
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.trevels@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.trevels@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message