Russel Winder: Revamp your builds with Gant
Russel Winder: Revamp your builds with Gant
Join the DZone community and get the full member experience.Join For Free
Russel Winder has been Professor at UCL and KCL, analyst, consultant, trainer and author. Among other things he has done research on parallel object-oriented programming (Solve, UC++, EuropaC++, etc.), after all he has a very strong Math background as a theoretical physicist. He is the creator of Gant, a build system that leverages Groovy and Ant. Enjoy!
Q. Russel, you are the creator of Gant, what can you tell us about it ?
A. Gant is a build tool where the specification of the build is written using a programming language (Groovy) instead of XML as used by Ant and Maven. To avoid reinventing things that work perfectly well, Gant uses all the Ant tasks via Groovy's AntBuilder. In essence, Gant provides tools, shortcuts, and general infrastructure over the AntBuilder. But it is more than just that. Groovy is a dynamic programming language, so you get all the rule synthesis and action programming that people using SCons, Rake, Rant, etc. are used to, and that is essentially impossible when using XML as the build specification language.
Q. How does Gant relate to other build tools ?
A. I consider Gant to be a sibling to Ant and cousin to Maven. I haven't tried creating a Groovy builder to use the Maven tasks, but it must be possible. So far the Ant tasks used in a Groovy context have provided all the capabilities I need and that others have asked for.
More and more people are writing emails to me saying Gant is exactly what they need -- programming Ant task-based builds in Groovy makes things so much easier that specifying the builds with XML. Gant doesn't replace Ant, it just makes it easier to work with non-trivial build algorithms using the Ant tasks. Hence my view that Gant and Ant are siblings not rivals.
Q. What motivated you to write Gant in the first place ?
A. Two things mainly:
- I really, really don't like Ant XML (nor Maven XML come to that), but I do like what the Ant tasks (and Maven plugins) can do.
- Using Groovy's AntBuilder directly requires infrastructure that is fundamentally the same in all cases, and I really do not like replicating code.
So Gant came about to provide the boilerplate infrastructure required for using Groovy's AntBuilder in order to program my builds in a programming language rather than using XML. Did I mention I am not keen on writing XML?
Q. What can you share about Gant's future features ?
A. This is a difficult question -- all crystal ball gazing is difficult. There are a few things that obviously need doing:
- Eclipse plugin, NetBeans plugin, IntelliJ IDEA plugin, so that Gant can be used with those IDEs.
- Getting support for Gant in CruiseControl, Bamboo, TeamCity -- Hudson already has it. I know all that is needed is a Gant Ant task (which already exists), but it is the principle of being able to use Gant directly.
- Various bug need fixing like trapping circular dependencies.
Creating a future strategy though is a bit more complicated. What is really needed is some feedback from people about what is right and what is wrong about Gant. This can be used as input to a planning activity and a roadmap.
Q. How did you get involved with Groovy ?
A. At the end of 2004 I found myself with some free time: the startup I was CTO of had to be put into liquidation, and I decided to focus on authoring books again for a while. Graham Roberts and myself set about creating the third edition of "Developing Java Software" and Sarah Mount, James Shuttleworth and myself started writing "Python for Rookies". Juxtaposing Java and Python in this way had me thinking about dynamic languages on the JVM, which naturally had me looking at Jython, JRuby and Groovy. At that time Jython appeared to be a dead project, JRuby was not in as good a state vis a vis the JVM as it is now, and the Groovy team seemed to be imploding -- very publicly.
The whole idea of a symbiotic, dynamic sibling to Java struck me as a superb idea, and Groovy epitomized this in ways that Jython and JRuby cannot ever do. Perhaps more importantly for my authoring, Groovy seemed like an ideal candidate for teaching people programming -- first year undergraduate type teaching. Java had become the de facto standard for teaching, a situation I had helped create. In 1996-7 I introduced Java as the first programming language at KCL (King's College London) where I was Professor of Computing Science. At the same time Graham Roberts was introducing Java as the first programming language at UCL (University College London) -- it is probably important to note that I moved from UCL to KCL in 1996! It was natural for the two of us to work together to create a textbook. The result was "Developing Java Software", which became one of the standard textbooks for Java teaching. However, Java has a lot of issues as a first programming language, issues that Python, Ruby, Haskell, etc. do not have. None of these lead naturally to a second course using Java though. Groovy on the other hand is an almost ideal candidate for teaching programming in a Java/JVM context.
A couple of publishers approached me about writing a Groovy textbook towards the end of 2004. As I was investigating the technology, I got drawn in to helping to develop it. Guillaume Laforge made me a committer and I got appointed to the expert group for JSR 241. It became clear to me that the technology needed at least two years before being viable for use in teaching, so I came to an agreement with one of the publishers to start writing a Groovy textbook in 2008. It was also agreed that the authoring team would be Graham Roberts and myself. Graham decided that 2007-8 would be the year he used Groovy instead of Java for the introductory programming course for computer science students at UCL. We created a curriculum and a pedagogy, and Graham gave the course. The results have surpassed expectations: the students learn Java better by starting with Groovy. Now all we have to do is turn all the material into a textbook!
[Andres: that is truly amazing!]
Q. Is there a feature from other languages you wish was available in Groovy ?
A. Nothing I can thing of at the minute. There may well be lots of things, but nothing is irritating me about Groovy just now.
Q. Do you use Groovy at work ?
A. All the time, but my focus is probably fairly specialized since I am primarily an author of documents.
I use Gant (which is just Groovy) for all my Java and Groovy builds, website construction (all template-based, static sites -- i.e. small stuff, nothing that needs Grails!), and LaTeX document builds.
I am also starting to use Groovy to investigate parallelism. I have been interested in parallel systems since 1986, and ran research projects on parallel, object-oriented languages (Solve, UC++, KC++) for 15 years at both UCL and KCL before leaving academia. With the arrival of multicore processors, parallelism is now the norm rather than preserve of HPC (as in high performance computing, though it is more and more being used as high productivity computing). Almost all HCP currently uses Fortran, C or C++, though JVM-based servers have been parallel for years, so parallelism has been an issue with Java for a while. The interesting questions are what are the right languages for expressing parallel algorithms, and do dynamic programming languages such as Python, Ruby and Groovy have a role. I am a founding partner of Concertant LLP which does analysis, training, consultancy, and project management on all things parallel and multicore in computer-based systems. So looking at languages like Groovy is an integral part of our work investigating many of the issues of the brave new parallel world in which we find ourselves. Hopefully that didn't sound too much like marketing hype :-)
Q. Are there any plans to contributing HPC related code to Groovy?
A. I am not sure Groovy will ever be used for HPC calculations per se. Dynamic languages such as Groovy, Ruby, Python etc. are not suitable for the calculations themselves -- these languages just do not execute enough operations per second to be considered. Fortran, C and C++ will likely remain the languages for writing the number crunching code for the foreseeable future. The question is whether OpenMP and MPI are the best tools for managing parallelism. Is there perhaps a new role for the dynamic languages as parallelism management and calculation configuration languages?
The interesting question is whether Java (or the latest IBM variant X10) can execute fast enough to compete viably with Fortran, C and C++. Indications are that JITs are now good enough that this may be so. This could lead to some HPC code being written in Java. This leads to the possibility that mixed Groovy / Java might become a player in the HPC game. Of course the inertia is currently with Fortran, C and C++ using OpenMP and MPI, but if people can shift their mindset from always using one language for all their code to having a mixed language approach, then new possibilities open up.
Of course this is speculation just now. What will be interesting will be to see what directions IBM, Sun Microsystems, Microsoft, Intel, and AMD take over the next year to 18 months.
Thanks for the interview Russel!
I started as a theoretical physicist (lots of QCD calculations and Fortran programming in the 1970s). I then shifted to Unix systems programming (lots of C programming, tape drivers, etc.). All the time though I was more interested in the programming process and how humans do it. Starting in 1983, I spend 13 years at UCL teaching programming (C++, Miranda, Scheme), software engineering, and human--computer interaction. My research was into parallel object-oriented programming (Solve, UC++, EuropaC++, etc.) and psychological and socio-technical aspects of programming. I then moved to KCL to be Professor of Computing Science. Teaching was Java, research was as at UCL (though now the languages was KC++), but also I started a medical informatics research programme. In 2001 I moved out of academia to run a startup with a novel virtual machine technology for embedded systems, but unfortunately there were financial problems and it had to be liquidated -- the technology got buried and nothing I can do about it. Since then I have been analyst, consultant, trainer and author. I have recently started a new consultancy practice, Concertant LLP, doing analysis, consultancy, training, etc. on all aspects of parallelism and multicore technology
Opinions expressed by DZone contributors are their own.