ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: [ANN] Gradle, a new build system, which uses Ivy
Date Tue, 22 Apr 2008 14:02:00 GMT
Hans Dockter wrote:
> Hi Steve,
> 
> On Apr 22, 2008, at 2:41 PM, Steve Loughran wrote:
> 
>> Hans Dockter wrote:
>>> 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
>>
>>
>> Nice to see such detailed docs.
>>
>>> 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).
>>
>> To be honest, I think its eclipse that is taking up more and more 
>> market share. We no longer have a java world of non-standard IDEs and 
>> console only development. Some
> 
> My focus is project automation. For example Gradle is being build by 
> Gradle. The actual Java/Groovy stuff (producing the jar) is a tiny part 
> of the build and is provided out of the box by Gradle. The interesting 
> thing are for example:
> 
> Automatic Release Management: We just execute gradle release: Our build 
> knows the version of the last release. Then it checks the svn path of 
> the working copy. If we are in a release branch and there has been a 
> release before, the build does a revision release (including tagging). 
> If we are in trunk it does a major/minor release, creates the branch and 
> tags the release.
> Userguide: The userguide is generated. Most of the examples in the 
> userguide are also integration tests. Our build executes these 
> integration tests, and if they pass, the output and the sources of the 
> tests are included in the userguide.
> Upload: We have the task uploadDists. Gradle allows a build to check the 
> execution graph and do further configuration before anything is 
> executed. If the 'release' is in the graph, we upload the distributions 
> to the release destination. If the 'release' task is not in the graph, 
> the version number gets an additional snapshot id and is uploaded to the 
> snapshot repository.
> 
> I could list more things we do for project automation. And after all 
> Gradle is a rather simple project from a build perspective. No question, 
> I love good IDEs'.  But this is all stuff an IDE can't offer. We could 
> add many more things why build tools are so important.  But I guess I 
> don't have to tell you :) And Gradle claims that these things can be 
> implemented much easier as with the current tools.

oh, I dont disagree. As I type an xubuntu vmware image is running the 
tests and is then about to <scp> up the RPMs for remote installation in 
a test RHEL4 vmware image. Try doing that in the IDE without some helper 
apps.

> 
> I'm working on a paper comparing the approaches of Ant and Maven vs. 
> using an internal DSL  (e..g. Gradle's Groovy DSL). I've taken a few 
> quotes from your book to underline my points :) When the first draft is 
> ready, I can send it to you, if you like.


That's cool. I could send you a link to something I'm just writing in my 
spare time too.

-- 
Steve Loughran                  http://www.1060.org/blogxter/publish/5
Author: Ant in Action           http://antbook.org/

Mime
View raw message