Russel Winder

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

Java 8 is closing over references not values, so yes there is a requirement of final and that irritates.

Without an example, your point about curly brace parameter lists is a bit vacuous I'm afraid.

Scala is a lot better than Java in so many ways, but it is becoming the Algol68 of the JVM. Algol68 was by far the best programming language of the 1960s, but it was too complex and so had little take up. Scala risks this position by trying to bring Type Theory mentality to programming. Certainly not wrong, but not populist. Hence Kotlin and Ceylon. The 1960s gave us C instead of Algol68, I suspect the 2010s will give us a language other than Scala. It's not about quality, it's about what the average programmer is prepared to use.

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

I wonder if you meant to update the first line to:

Your Java example is not compilable: the ArrayList object cannot be constructed like that. You probably meant to use Arrays.asList. Of course even with Arrays.asList(1, 2, 3, 4, 5) being used the example fails because Iterator.remove is an optional method and throws java.lang.UnsupportedOperationException.

Move forward to Java 8 and you get to write something like:

Arrays.asList(1,2,3,4,5).filter(x -> x > 3)

So then Scala has zero win over Java.

It strikes me as ironic that in an article on YAML instead of JSON or whatever as a configuration notation for Java systems, no comment is made on how hugely verbose the use of XML in Maven is. Why doesn't Maven use YAML for its specification?

Raoul,

It is bizarre how much disinformation gets promulgated via the Web isn't it! It is a great pity more programmers do not read these great books. e.g Cormen et al.

It is perhaps worth noting that I maintain artefacts in the Maven and Codehaus repositories for all the JSR166 artefacts based on Doug's CVS repository. This saves people having to download and install.

A version 1.7.0 was released some time ago and is in the Maven repository groupId=org.codehaus.jsr166-mirror, artefacts are jsr166, jsr166tck, jsr166x, jsr166y, extra166y, version=1.7.0.

Artefacts from CVS HEAD are published more or less as they are committed to CVS to the Codehaus snapshots repository (http://snapshots.repository.codehaus.org) groupId=org.codehaus.jsr166-mirror, artefacts are jsr166, jsr166tck, jsr166x, jsr166y, extra166y, and jsr166r, version=1.7.0.1-SNAPSHOT.

Clojure is not a new language, it is a dialect of Lisp running on a JVM -- with access to the installed Java etc. libraries. Lisp is as old as Fortran and Cobol. Yet Lisp (and hence Clojure) remains unique amongst programming languages in that there is no syntactic distinction between code and data. This makes for some seriously interesting programming techniques -- notwithstanding the old prejudice against self-modifying code.

It would be sad if Lisp died simply because it was old.

Re Java: The sooner the JVM is fixed to support parameterized types, and type erasure is removed, the sooner Java will be a language it is possible to use. CLR got this issue right. Arguments about backward compatibility do not wash since the JVM changed anyway to support annotations.

Yes, these systems have value and can work as part of a build system, but they're no Holy Grail. That's all we were trying to mention, giving arguments as to why such is the case.

[/quote]

This is the crucial point, and one I fully agree with. Competant and good programmers know the value of CI and use it effectively and well. No amount of pushing CI (or any other "Silver Bullet" for that matter) on bad programmers will help them climb out of the morass of their lives. Sadly.

Yes, these systems have value and can work as part of a build system, but they're no Holy Grail. That's all we were trying to mention, giving arguments as to why such is the case.

[/quote]

This is the crucial point, and one I fully agree with. Competant and good programmers know the value of CI and use it effectively and well. No amount of pushing CI (or any other "Silver Bullet" for that matter) on bad programmers will help them climb out of the morass of their lives. Sadly.

Jeroen,

I think you need to take a reality check: to try and claim "hardly anyone uses" Bazaar, Mercurial or Git indicates a serious lack of observation of the real world. Moreover they all have plugins for Eclipse, IntelliJ IDEA and NetBeans, so even people incapable of using a command line have access to the tools.

Oh and Gant and Gradle have plugins for Hudson. So whilst it may be true that there are currently fewer users of these systems than Ant or Maven, the tools do exist and they are not poor.

I think the image and blurb need a bit of an update:

Version control should surely emphasize Bazaar, Mercurial and Git which in all cases are superior to CVS and Subversion.

Build should surely emphasize Gradle and Gant rather than Ant and Nant :-)

One small point on the Gant code: Ant is deprecated and ant should be used in code such as

ant.echo ( message : "hello" )

Also inside targets you don't actually need the ant. at all, you can just use echo and the Ant echo task will be called, unless you have defined a function called echo or a closure referred to by a variable called echo.

One small point on the Gant code: Ant is deprecated and ant should be used in code such as

ant.echo ( message : "hello" )

Also inside targets you don't actually need the ant. at all, you can just use echo and the Ant echo task will be called, unless you have defined a function called echo or a closure referred to by a variable called echo.

Thanks to Meera for the article, and thanks to everyone who has commented for commenting.

First let me deal with the "build specification is data" vs "build specification is program" issue. Ant XML tried to be a pure functional language so as to make build specifications declarative. This works for small projects but fails for even medium sized projects since even selection is clumsy in Ant XML. As soon as you need some form of variation in the build, Ant XML becomes awkward. Maven attempted to go to the next stage of declarative expression by applying convention over configuration and trying to remove all process from the build specification. Again for simple projects it succeeds, but for complex projects, much hacking (in the less than best sense) is needed. Experience shows us that for medium sized and large projects, the build process has to be specified with a program that has to have easy decision making. Yes things should be as declarative as possible, so avoiding explicit looping is a good guideline, but build is a process and so needs a program.

Second let me deal with the "Why Groovy not Java?" issue? I was aware of Gosling and now I see there is PJMake, there are probably others as well. There are two issues here a) the projects are not building on the Ant or Maven infrastructures and so are a revolution rather than an evolution to switch to; and b) Java is a verbose language not easily suited to creating domain specific languages (DSLs) -- not having a metaobject protocol is a barrier to some of the techniques that make writing DSLs easy and straightforward.

For good or ill Ant and Maven are the de facto standard build systems in the Java milieu. In the Ruby milieu there is Rake and in the C, C++, Fortran, and LaTeX milieux there is (the venerable) Make, (the almost mandatory) Autotools, and (the very much better than either of these) SCons. What is sadly lacking is a build system that caters for all these. C, C++ and LaTeX support in Ant and Maven is poor. Moreover C, C++ and LaTeX builds generally require more process information than Java builds.

So here is the pain: Ant has some great infrastructure but could do with more in certain areas, and XML is not the right notation for specifying process. So what is the language for writing process? In the Java milieu, the choices are Java, Groovy, Jython, JRuby, BeanShell. For me Java is too static for this task, a dynamic language is needed. For me the choice is Groovy, others have taken an alternative approach. Buildr is a Maven replacement using JRuby and Rake, Gradle is a Maven and Ant replacement written in Groovy and Java based on Ivy.

So the way of reducing the pain induced by Ant was to replace the XML processing with Groovy processing with as light a weight front end as possible. Gant is literally just a way of scripting Ant tasks with the added extra of being able to define new add-ons in Groovy.

It seems this evolution of just replacing the XML processing with Groovy processing has hit a chord. I am daily getting emails saying something along the lines of "Hey this is great, I don't need to learn a new infrastructure, but now I can express my build so much more easily." So using Groovy scripting instead of XML hacking appears to have solved a problem for many, many people.

On the question of why a dynamic language? The core issue here is the ability to synthesize dependencies. With Make you must specify explicitly all the dependencies. What SCons and then Rake brought to the game was the ability to program dependencies. This is a revolution in build specification, and one that cannot be achieved with XML without some serious hacking. Dynamic languages are thus the natural tool for specifying dependency.

So what of the future? Well Ant and Maven will continue to dominate but slowly I think Gant is expanding as Ant users see that Groovy beats XML for build specification and that they can evolve their build system bit by bit from Ant XML to Gant Groovy.

What about Gradle (and Buildr, Gosling, PJMake, etc.) well where there are new projects this is clearly an option since there is no extant build infrastructure. Where Gant wins is where there is extant build infrastructure that needs evolving. Gant is a stepping stone from Ant XML to the easier world of Groovy programming. Gant brings to the Java milieu the approach that SCons and Rake have established elsewhere. If this then leads people onto Gradle fine, but I think both Gant and Gradle will be increasingly used for different aspects of things.

Apologies for going on so long, and thanks again to Meera for the article.

Footnote: Gradle was originally going to be built on top of Gant, but Hans Dockter found he was unable to cleanly express the things he needed, so he started again from scratch. In a sense Gradle can subsume Gant since everything you can do in Gant you can do in Gradle. However I suspect the two will have take up since Gant can be sneaked in to an extant Ant build more easily than Gradle, whereas for new projects Gradle has a more "whole project management" aspect that means it is the system of choice over Maven. Gant is lightweight Ant task scripting and Groovy programming, Gradle is full on project control.

Thanks to Meera for the article, and thanks to everyone who has commented for commenting.

First let me deal with the "build specification is data" vs "build specification is program" issue. Ant XML tried to be a pure functional language so as to make build specifications declarative. This works for small projects but fails for even medium sized projects since even selection is clumsy in Ant XML. As soon as you need some form of variation in the build, Ant XML becomes awkward. Maven attempted to go to the next stage of declarative expression by applying convention over configuration and trying to remove all process from the build specification. Again for simple projects it succeeds, but for complex projects, much hacking (in the less than best sense) is needed. Experience shows us that for medium sized and large projects, the build process has to be specified with a program that has to have easy decision making. Yes things should be as declarative as possible, so avoiding explicit looping is a good guideline, but build is a process and so needs a program.

Second let me deal with the "Why Groovy not Java?" issue? I was aware of Gosling and now I see there is PJMake, there are probably others as well. There are two issues here a) the projects are not building on the Ant or Maven infrastructures and so are a revolution rather than an evolution to switch to; and b) Java is a verbose language not easily suited to creating domain specific languages (DSLs) -- not having a metaobject protocol is a barrier to some of the techniques that make writing DSLs easy and straightforward.

For good or ill Ant and Maven are the de facto standard build systems in the Java milieu. In the Ruby milieu there is Rake and in the C, C++, Fortran, and LaTeX milieux there is (the venerable) Make, (the almost mandatory) Autotools, and (the very much better than either of these) SCons. What is sadly lacking is a build system that caters for all these. C, C++ and LaTeX support in Ant and Maven is poor. Moreover C, C++ and LaTeX builds generally require more process information than Java builds.

So here is the pain: Ant has some great infrastructure but could do with more in certain areas, and XML is not the right notation for specifying process. So what is the language for writing process? In the Java milieu, the choices are Java, Groovy, Jython, JRuby, BeanShell. For me Java is too static for this task, a dynamic language is needed. For me the choice is Groovy, others have taken an alternative approach. Buildr is a Maven replacement using JRuby and Rake, Gradle is a Maven and Ant replacement written in Groovy and Java based on Ivy.

So the way of reducing the pain induced by Ant was to replace the XML processing with Groovy processing with as light a weight front end as possible. Gant is literally just a way of scripting Ant tasks with the added extra of being able to define new add-ons in Groovy.

It seems this evolution of just replacing the XML processing with Groovy processing has hit a chord. I am daily getting emails saying something along the lines of "Hey this is great, I don't need to learn a new infrastructure, but now I can express my build so much more easily." So using Groovy scripting instead of XML hacking appears to have solved a problem for many, many people.

On the question of why a dynamic language? The core issue here is the ability to synthesize dependencies. With Make you must specify explicitly all the dependencies. What SCons and then Rake brought to the game was the ability to program dependencies. This is a revolution in build specification, and one that cannot be achieved with XML without some serious hacking. Dynamic languages are thus the natural tool for specifying dependency.

So what of the future? Well Ant and Maven will continue to dominate but slowly I think Gant is expanding as Ant users see that Groovy beats XML for build specification and that they can evolve their build system bit by bit from Ant XML to Gant Groovy.

What about Gradle (and Buildr, Gosling, PJMake, etc.) well where there are new projects this is clearly an option since there is no extant build infrastructure. Where Gant wins is where there is extant build infrastructure that needs evolving. Gant is a stepping stone from Ant XML to the easier world of Groovy programming. Gant brings to the Java milieu the approach that SCons and Rake have established elsewhere. If this then leads people onto Gradle fine, but I think both Gant and Gradle will be increasingly used for different aspects of things.

Apologies for going on so long, and thanks again to Meera for the article.

Footnote: Gradle was originally going to be built on top of Gant, but Hans Dockter found he was unable to cleanly express the things he needed, so he started again from scratch. In a sense Gradle can subsume Gant since everything you can do in Gant you can do in Gradle. However I suspect the two will have take up since Gant can be sneaked in to an extant Ant build more easily than Gradle, whereas for new projects Gradle has a more "whole project management" aspect that means it is the system of choice over Maven. Gant is lightweight Ant task scripting and Groovy programming, Gradle is full on project control.

Using Groovy and AntBuilder is great but there is a lot of infrastructure that everyone will replicate. Enter Gant (http://gant.codehaus.org). The whole point of Gant is to allow build specifications to be written in Groovy using the AntBuilder but with all the core boilerplate code already done for you.

I like Maven though, well for projects that fit the Maven model anyway. So Gant has the Maven target set. I have a project for which the Gant script is:

includeTargets ** gant.targets.Maven * [
groupId : 'org.devjavasoft' ,
artifactId : 'ads' ,
version : '3.1.0' ,
javaCompileProperties : [ source : '1.6' , target : '1.6' , debug : 'true' ] ,
testFramework : 'testng'
]

cleanPattern << '**/*~'

setDefaultTarget ( test )

I like Ant and the Ant tasks as well, especially where flexibility is required, but I hate writing specifications in XML, especially when the build algorithm cannot be specified as a purely functional program. So Gant is ideal for me in this context; it uses all the Ant tasks (include the Maven Ant Task and the Ivy Ant task) but scripted using a dynamic language, Groovy.

Using Groovy and AntBuilder is great but there is a lot of infrastructure that everyone will replicate. Enter Gant (http://gant.codehaus.org). The whole point of Gant is to allow build specifications to be written in Groovy using the AntBuilder but with all the core boilerplate code already done for you.

I like Maven though, well for projects that fit the Maven model anyway. So Gant has the Maven target set. I have a project for which the Gant script is:

includeTargets ** gant.targets.Maven * [
groupId : 'org.devjavasoft' ,
artifactId : 'ads' ,
version : '3.1.0' ,
javaCompileProperties : [ source : '1.6' , target : '1.6' , debug : 'true' ] ,
testFramework : 'testng'
]

cleanPattern << '**/*~'

setDefaultTarget ( test )

I like Ant and the Ant tasks as well, especially where flexibility is required, but I hate writing specifications in XML, especially when the build algorithm cannot be specified as a purely functional program. So Gant is ideal for me in this context; it uses all the Ant tasks (include the Maven Ant Task and the Ivy Ant task) but scripted using a dynamic language, Groovy.

Using Groovy and AntBuilder is great but there is a lot of infrastructure that everyone will replicate. Enter Gant (http://gant.codehaus.org). The whole point of Gant is to allow build specifications to be written in Groovy using the AntBuilder but with all the core boilerplate code already done for you.

I like Maven though, well for projects that fit the Maven model anyway. So Gant has the Maven target set. I have a project for which the Gant script is:

includeTargets ** gant.targets.Maven * [
groupId : 'org.devjavasoft' ,
artifactId : 'ads' ,
version : '3.1.0' ,
javaCompileProperties : [ source : '1.6' , target : '1.6' , debug : 'true' ] ,
testFramework : 'testng'
]

cleanPattern << '**/*~'

setDefaultTarget ( test )

I like Ant and the Ant tasks as well, especially where flexibility is required, but I hate writing specifications in XML, especially when the build algorithm cannot be specified as a purely functional program. So Gant is ideal for me in this context; it uses all the Ant tasks (include the Maven Ant Task and the Ivy Ant task) but scripted using a dynamic language, Groovy.

Using Groovy and AntBuilder is great but there is a lot of infrastructure that everyone will replicate. Enter Gant (http://gant.codehaus.org). The whole point of Gant is to allow build specifications to be written in Groovy using the AntBuilder but with all the core boilerplate code already done for you.

I like Maven though, well for projects that fit the Maven model anyway. So Gant has the Maven target set. I have a project for which the Gant script is:

includeTargets ** gant.targets.Maven * [
groupId : 'org.devjavasoft' ,
artifactId : 'ads' ,
version : '3.1.0' ,
javaCompileProperties : [ source : '1.6' , target : '1.6' , debug : 'true' ] ,
testFramework : 'testng'
]

cleanPattern << '**/*~'

setDefaultTarget ( test )

I like Ant and the Ant tasks as well, especially where flexibility is required, but I hate writing specifications in XML, especially when the build algorithm cannot be specified as a purely functional program. So Gant is ideal for me in this context; it uses all the Ant tasks (include the Maven Ant Task and the Ivy Ant task) but scripted using a dynamic language, Groovy.

Using Groovy and AntBuilder is great but there is a lot of infrastructure that everyone will replicate. Enter Gant (http://gant.codehaus.org). The whole point of Gant is to allow build specifications to be written in Groovy using the AntBuilder but with all the core boilerplate code already done for you.

I like Maven though, well for projects that fit the Maven model anyway. So Gant has the Maven target set. I have a project for which the Gant script is:

includeTargets ** gant.targets.Maven * [
groupId : 'org.devjavasoft' ,
artifactId : 'ads' ,
version : '3.1.0' ,
javaCompileProperties : [ source : '1.6' , target : '1.6' , debug : 'true' ] ,
testFramework : 'testng'
]

cleanPattern << '**/*~'

setDefaultTarget ( test )

I like Ant and the Ant tasks as well, especially where flexibility is required, but I hate writing specifications in XML, especially when the build algorithm cannot be specified as a purely functional program. So Gant is ideal for me in this context; it uses all the Ant tasks (include the Maven Ant Task and the Ivy Ant task) but scripted using a dynamic language, Groovy.

Using Groovy and AntBuilder is great but there is a lot of infrastructure that everyone will replicate. Enter Gant (http://gant.codehaus.org). The whole point of Gant is to allow build specifications to be written in Groovy using the AntBuilder but with all the core boilerplate code already done for you.

I like Maven though, well for projects that fit the Maven model anyway. So Gant has the Maven target set. I have a project for which the Gant script is:

includeTargets ** gant.targets.Maven * [
groupId : 'org.devjavasoft' ,
artifactId : 'ads' ,
version : '3.1.0' ,
javaCompileProperties : [ source : '1.6' , target : '1.6' , debug : 'true' ] ,
testFramework : 'testng'
]

cleanPattern << '**/*~'

setDefaultTarget ( test )

I like Ant and the Ant tasks as well, especially where flexibility is required, but I hate writing specifications in XML, especially when the build algorithm cannot be specified as a purely functional program. So Gant is ideal for me in this context; it uses all the Ant tasks (include the Maven Ant Task and the Ivy Ant task) but scripted using a dynamic language, Groovy.

Using Groovy and AntBuilder is great but there is a lot of infrastructure that everyone will replicate. Enter Gant (http://gant.codehaus.org). The whole point of Gant is to allow build specifications to be written in Groovy using the AntBuilder but with all the core boilerplate code already done for you.

I like Maven though, well for projects that fit the Maven model anyway. So Gant has the Maven target set. I have a project for which the Gant script is:

includeTargets ** gant.targets.Maven * [
groupId : 'org.devjavasoft' ,
artifactId : 'ads' ,
version : '3.1.0' ,
javaCompileProperties : [ source : '1.6' , target : '1.6' , debug : 'true' ] ,
testFramework : 'testng'
]

cleanPattern << '**/*~'

setDefaultTarget ( test )

I like Ant and the Ant tasks as well, especially where flexibility is required, but I hate writing specifications in XML, especially when the build algorithm cannot be specified as a purely functional program. So Gant is ideal for me in this context; it uses all the Ant tasks (include the Maven Ant Task and the Ivy Ant task) but scripted using a dynamic language, Groovy.