69 messages in org.codehaus.groovy.devRe: [groovy-dev] Building Groovy
FromSent OnAttachments
Russel WinderOct 6, 2008 4:36 am 
MingfaiOct 6, 2008 4:47 am 
Hans DockterOct 6, 2008 4:50 am 
Hans DockterOct 6, 2008 4:55 am 
Jochen TheodorouOct 6, 2008 4:56 am 
Guillaume LaforgeOct 6, 2008 7:17 am 
Hans DockterOct 6, 2008 7:51 am 
Russel WinderOct 6, 2008 7:59 am 
Guillaume LaforgeOct 6, 2008 8:19 am 
Guillaume LaforgeOct 6, 2008 8:25 am 
MingfaiOct 6, 2008 8:28 am 
Guillaume LaforgeOct 6, 2008 8:36 am 
Hans DockterOct 6, 2008 1:46 pm 
Guillaume LaforgeOct 6, 2008 1:54 pm 
Hans DockterOct 6, 2008 1:54 pm 
Jochen TheodorouOct 6, 2008 2:03 pm 
Guillaume LaforgeOct 6, 2008 2:09 pm 
Paul DuffyOct 6, 2008 7:06 pm 
Luke DaleyOct 6, 2008 8:47 pm 
Guillaume LaforgeOct 6, 2008 9:44 pm 
Russel WinderOct 6, 2008 11:25 pm 
Russel WinderOct 6, 2008 11:54 pm 
Russel WinderOct 7, 2008 12:03 am 
Jason DillonOct 7, 2008 12:23 am 
Russel WinderOct 7, 2008 12:24 am 
Guillaume LaforgeOct 7, 2008 12:30 am 
Hans DockterOct 7, 2008 12:35 am 
Jason DillonOct 7, 2008 12:35 am 
Hans DockterOct 7, 2008 12:36 am 
Jason DillonOct 7, 2008 12:41 am 
Guillaume LaforgeOct 7, 2008 12:54 am 
Jason DillonOct 7, 2008 1:40 am 
Guillaume LaforgeOct 7, 2008 1:50 am 
Jason DillonOct 7, 2008 1:55 am 
Guillaume LaforgeOct 7, 2008 2:25 am 
Guillaume LaforgeOct 7, 2008 2:35 am 
Jason DillonOct 7, 2008 3:09 am 
Guillaume LaforgeOct 7, 2008 3:12 am 
Russel WinderOct 7, 2008 3:17 am 
Jason DillonOct 7, 2008 3:24 am 
Paul KingOct 7, 2008 4:04 am 
ma...@dockter.bizOct 7, 2008 4:19 am 
ma...@dockter.bizOct 7, 2008 4:25 am 
Jason DillonOct 7, 2008 4:36 am 
Jason DillonOct 7, 2008 4:39 am 
Jochen TheodorouOct 7, 2008 5:20 am 
Jason DillonOct 7, 2008 8:19 am 
Jochen TheodorouOct 7, 2008 9:51 am 
Jason DillonOct 7, 2008 10:49 am 
Jochen TheodorouOct 7, 2008 12:03 pm 
Hans DockterOct 7, 2008 2:34 pm 
Luke DaleyOct 7, 2008 3:52 pm 
Jason DillonOct 8, 2008 1:28 am 
Jason DillonOct 8, 2008 1:35 am 
Hans DockterOct 8, 2008 3:11 am 
Hans DockterOct 8, 2008 3:49 am 
Hans DockterOct 8, 2008 4:30 am 
Hans DockterOct 8, 2008 4:40 am 
Jason DillonOct 8, 2008 4:52 am 
Jason DillonOct 8, 2008 5:21 am 
Jochen TheodorouOct 8, 2008 6:23 am 
Jochen TheodorouOct 8, 2008 6:47 am 
Jochen TheodorouOct 8, 2008 6:59 am 
Hans DockterOct 8, 2008 8:33 am 
Hans DockterOct 8, 2008 8:43 am 
Paul DuffyOct 9, 2008 8:58 am 
Paul KingOct 9, 2008 1:15 pm 
Danno FerrinOct 9, 2008 1:27 pm 
Paul KingOct 10, 2008 2:31 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [groovy-dev] Building GroovyActions...
From:Hans Dockter (ma@dockter.biz)
Date:Oct 7, 2008 12:35:37 am
List:org.codehaus.groovy.dev

Hi Guillaume,

On Oct 6, 2008, at 10:54 PM, Guillaume Laforge wrote:

Great, have a good night.

What I'd like to see tomorrow when you wake up, is a list of the good / bad sides of our current Ant-based build, and how Gradle improves on those things or solve problems we may have.

Unfortunately I have no time in the next days to dive into the details of the Groovy build. Instead, for now, I will share my general view on Ant.

I have always liked the flexibility of Ant and its wealth of helpful task. With Ivy it has a much better dependency management than Maven. I also think dependency based programming [1], which is the base of Ant, is very suitable for the needs of the build system. But Ant has its fundamental problems:

- It has no build-by-convention support which makes a build harder to maintain. - Together with Ivy it has some support for modularization. But not a very good one. - It is hard to avoid redundancy in your build code, specially if you have a multi-project build. Ant's approach to improve this has been to introduce general purpose elements (e.g. Mixins, Macrodefs, ...) into its external XML DSL. This is better than nothing but those elements have a steep learning curve. They make a build extremely hard to understand for the non-initiated. And of course they are still a pale imitation of what you can do with a real programming language like Groovy. - The XML approach makes it very verbose. - Ant allows only for an anemic interaction with Java/Groovy. You have to wrap any Java/Groovy code into a task. You can only pass String arguments to this task. What about return values, doing something with return values like looping. I guess I don't have to go into details about this on the Groovy list. This is a serious limitation for customizing your build. Ant somehow tries to alleviate this by introducing its own general purpose elements like its famous if statement. The limitations are obvious.

How does this compare to Gradle?

- Gradle offers you all the flexibility that is offered by Ant. Gradle also has dependency based programming as its base. In fact Gradle offers you more flexibility as it is based on an internal Groovy DSL and its language for dependency based programming is richer and provides an API. On top of this flexible base, Gradle provides plugins which constitute highly configurable, small build-by- convention frameworks. - Gradle's support for modularization (multi-project builds) is very strong. Far better than what is possible with Ant (and by the way with Maven). - Gradle uses Ivy under the hood and thus provides the same excellent dependency manager as Ant does. But Ivy is integrated in Gradle's build-by-convention approach and thus easier to use for the normal use cases. - The fact that Gradle uses and internal Groovy DSL obviously solves many of Ant's problems mentioned above.

If you just want to build a jar than all this might be not much of a problem. But if you are serious about project automation Ant makes your life very hard and unproductive. In fact, I have seen many projects not harnessing the power of project automation because Ant or Maven made this too hard to achieve. And although the Groovy build is not the most complex one in the universe it applies to it as well I think.

With Ant your build will also have a lot of redundancies and/or Ant specific general purpose elements. Both make the build hard to understand and make the build very intransparent to people who are not build master. This will be a serious problem if you go for modularization.

- Hans

[1] Dependency based programming is a term I think coined by Martin Fowler. It is about creating a graph of actions which have a depends relation to each other (a directed acyclic graph (DAG)). The build system makes sure that every action gets only executed once. Every popular build system I know is using this approach (Make, Ant, SCons, Rake, Gradle :)). Maven 2 thought it is a good idea not to be based on this. I'm not sure if this was a good idea.