Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v753)
To: ivy-user@ant.apache.org
Message-Id: <6F586926-0D16-4A05-A47A-1A39619D991C@dockter.biz>
Content-Type: multipart/alternative; boundary=Apple-Mail-13-777724981
From: Hans Dockter <mail@dockter.biz>
Subject: [ANN] Gradle, a new build system, which uses Ivy
Date: Tue, 22 Apr 2008 14:01:15 +0200

--Apple-Mail-13-777724981
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

We are very excited to announce Gradle, a new build system.

We announce it on this list, as Gradle uses Ivy for its dependency  
management.

To learn more about Gradle, have a look at http://www.gradle.org

or its 50+ pages userguide: http://gradle.org/userguide/release/ 
userguide.pdf

The rest of this posting is dedicated to Ivy and dependency  
management in general.

Before I've started to develop Gradle I had only a faint idea about  
Ivy. I had been using Maven for years, and I had started to develop a  
new build system out of this not very satisfying experience. When I  
was starting to develop the dependency management, I had a closer  
look at Ivy and I decided to give it a try. I'm so happy that this  
turned out to be a very good decision.
- Gradle integrates deeply with Ivy via its API. Although I guess not  
many projects use Ivy via the API, the API has been almost perfect to  
our needs. There was not a single ugly hack necessary, to make Ivy do  
what Gradle needs. It was possible to introduce new concepts for  
dependency management by using Ivy as a low level API. This says a  
lot of the quality of Ivy's code base (and I guess about the virtues  
of test driven development). I'm very impressed.
- Ivy has taught me a lot about the problem space of dependency  
management (although I have considered myself as  an experienced  
build master for enterprise projects). The unit for measuring the  
differences to Maven in solving this problem space is light-years :).

I'm still overwhelmed by the complexity of Ivy. Although I've worked  
a lot with Ivy in the last 6 months I still consider myself being  
just on the intermediate level. I'm still confused or unknowing about  
the role of an IvyNode in the resolve process, the resolve process  
details themselves,  the usage of IvyContext, and many more things.  
It would be terrific if an Ivy code expert would join me for a code  
review on Gradle's usage of Ivy.

Ivy is so tremendously superior to the Maven2 dependency management,  
and yet it seems Maven2 is taking up more and more of the market  
share. Ivy scales up extremely well. What I think is missing is an  
EasyIvy which does pretty much what Maven does. But without locking  
you in, into this simplified approach. Gradle is offering exactly  
this (and many other things).

Another thing that Gradle adds on top of Ivy are Client Modules. They  
enable support for transitive dependency management without the need  
for pom.xml  or ivy.xml files. Thanks to Ivy's flexible repository  
layout patterns, you can thus easily use a flat project folder (under  
version control) containing the libraries and do something like:

dependencies {
	clientModule('compile', ":groovy-all:1.5.5") {
		dependency(":commons-cli:1.0")
                 clientModule(":ant:1.7.0") {
                      dependencies(":ant-junit:1.7.0:", ":ant- 
launcher:1.7.0")
                 }
         }
}

No ivy.xml necessary. No organisation id. No remote repositories. You  
can check out the project and build it without the need to download  
anything and yet have support for transitive dependency management.  
It is a choice we give to our users. It is another part of the  
EasyIvy idea.

There have been only a few things I was missing. The Ivy API does not  
provide functionality for getting a list of files pointing to the  
local location of the resolved libraries. I had to do a copy'n'paste  
from Ivy's Ant cachepath task. On first sight, the same seems to be  
true for doing reports. I need to have a close look on this topic.

I think it is an exciting time for build systems. Gradle is written  
in Groovy and the build scripts are in Groovy. We think internal  
DSL's based on a general purpose language like Groovy are better  
suited for writing build scripts than XML. This is a different  
discussion though.

Thanks a lot for Ivy

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org


--Apple-Mail-13-777724981--