Build is hard
Development is hard. While build is even harder.

It is always there as a big obstacle. From my experience, optimistically, 30% of development effort are wasted in build and environment configuration, at least for a junior developer.

Your eclipse installation fail, a plugin not working, EOL is of windows instead of linux. SVN wrongly cached.
Class path of build and test are different, Spring application context file cannot be loaded…

Ant is a great tool. Maven is another one, together with tool like brew, easy_install, all great tools.
However those stuff never worked seamlessly for me in most scenarios. Dependencies can’t be resolved, version conflict, proxies…etc

Forget about environment config, we all understand the important of a quick build. Faster build also implies faster test.

Jenkins is the best open source framework for automated continuous integration. There are lots of features and possibility besides build.
Still, there is a need for build language.

Ant & Maven could be better
For Ant & Maven, both of them are great but they have their own problems. Therefore I am glad to introduce a new one, below, Gradle.

1) Both Ant and maven use XML

Although schema validation is good, XML is hard to read or configure, also heavy weight.

2) Maven lifecycle is complicated

Maven features

Differ from Ant that maven has several important features, including dependency management with repository library and lifecycle.

Firstly, there is a learning curve for this, and secondly this limited the expressiveness of the language as maven enforce its life cycle rules to its project. Some tasks are tedious & procedural and they are. With maven syntax it will be hard to express them.

Here is a nice post on Maven Alternatives.


Back to the topic, Let’s talk about Gradle then.

To be honest I am not expert in Ant nor Maven. However I can say Gradle is at least more intuitive to me.

As people put it, it can be considered as Groovy, Ant , Maven, Ivy combined
Gradle features

1) Nice DSL

Gradle is written in Groovy and borrowed a lot from groovy.
However user are neither required to be a groovy developer or required to run it in platform with groovy dependency.
Basically all features can be expressed well in the Domain Specified Language (DSL) itself.
You are essentially writing groovy but you required only to write about the domain, which are those build tasks, dependencies, specification, without need of knowledge in groovy.
I would say compared to XML, DSL is a much  better choice.

2) Really good documentation
Really clean and clear documentation for such a new tool. I encountered some gotchas, but still that is minimized.
Cool enough, the documentation itself is build using gradle. (I just remember coffeescript is compiled by coffeescript)

3) Dependency Management

I never use Ivy, in Gradle dependencies will be formed a DAG (Directed acyclic graph) and resolved accordingly.

4) Ant & Maven features with maven Convention

It is possible to execute ant task. It is also possible to fetch artifacts from maven repository. Not possible to execute maven command though.For maven convention, this is the right decision. Most projects are using Maven layout. Most developers are used to maven layout. Yes, convention over configuration helps.

5) Active development 

I consider this an important factor when I was picking any framework
Active Developing most of the times implies an active community, which then imply you get help easier.
It also means bugs will get fixed, features will be added right there.

6) Wrapper to build in places even gradle not installed.
The wrapper will resolve all the dependencies, installing gradle to the target. No problem to take the artifact to build in windows or linux.

There are more. Nice API, profiling, numerous plugins including OSGI. The biggest drawback is perhaps there is no eclipse plugin yet.
Syntax validation using groovy editor is error prone.

After all, this is build tool for tomorrow, and,  today.

I also see the potential for writing integration test scripts with this tool.

There exist a integration testing framework, GINT which used GANT , another build alternative writing in Groovy, as test scripts.
It turns out that Gradle & GANT are quite similar in this context, while GANT focused on scripting with no dependency management or extra features. Gradle could  be a much more powerful replacement.
will talk about some real code with gradle and some gotchas later


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s