Java Power Tools which will be released around Match 2008, covers 30
open source tools designed to improve the development practices of Java
developers. As per O'Reilly each chapter includes a series of short
articles about one particular tool -- whether it's for build systems,
version control, or other aspects of the development process -- giving
you the equivalent of 30 short reference books in one package.
Javalobby had the opportunity to talk to John and find out more about
1. John, can you tell us a bit about yourself and your work?
a freelance consultant specialising in Enterprise Java and Open Source
Java technologies. I've been programming since I convinced my father to
buy me a TI-99/4A back in 1982. On the academic front, I have a PhD in
Maths and Computer Science. I've worked in many companies over the
years, as a developer, project manager, trainer and solutions
architect, on a wide range of projects. I started off with C++, and
have been working with Java since 1999. I'm a strong proponent of
development best practices, such as coding standards, automated
testing, continuous integration, and version control. Currently, I can
usually be found helping large companies or government organisations on
Enterprise Java projects, and in particular using open source
technologies such as Spring and Hibernate. In the process, clients
often ask me to help them optimize their development practices and
infrastructure, to set up a continous integration environments, and to
provide coaching, mentoring and training in open source technologies
and agile development methods.
2. Why did you decide to write a book on open source tools?
are tools I use every day, and in my experience, knowing about them and
using them well is a great way to improve the quality of your code, and
also to make your life as a developer much more satisfying. Once you
introduce a well-tuned set of SDLC tools in a project, there's no
turning back. It is really a revolutionary change in the way you work.
It's like moving from snail-mail and faxes to email, IM and
video-conferences. Or from fighting a war with swords and shields to
using tanks and jets.
And the best thing is that often, the tools are free!
Don't get me wrong, there are some good commercial tools out there. But nowadays, you don't have to spend a lot of money to get a good set of development tools.
So I thought other people might be able to benefit from my experience in this area.
3. Who is your target audience?
of all Java developers who want to improve their skills by adding new
tools and techniques to their repertoire. Also, team leaders, project
managers, solutions architects and the like, who need to come up with a
good set of tools and recommended practices for their project or
4. What are
the open source tools you are covering in this book?
are quite a few. The book covers most of the software development
lifecycle, at least from a developer's perspective. It starts off with
a section on build scripting tools, where I cover the two big players,
Ant and Maven 2. Then I move on to version control software, with CVS
and Subversion. With these two bases covered, we come to Continous
Integration. This is a big section, and one of my favorites, with four
of the more interesting open source CI tools: CruiseControl, Continuum,
LuntBuild and Hudson. And since team communication is important, we
also look at how to set up an IM server with Openfire.
we look at testing, and cover JUnit 4 and TestNG for unit testing,
Cobertura for test coverage, as well as a swath integration and
performance testing tools, including StrutsTestCase, DBUnit, JUnitPerf,
JMeter, JConsole, the Eclipse profiling tools, SoapUI, Selenium and
We also look at two issue management tools: Bugzilla and Trac.
is also a section dedicated to improving code quality. This section
discusses static analysis tools like Checkstyle, PMD and FindBugs, but
also covers Jupiter, a tool that facilitates code reviews, and Mylyn,
which help you work more efficiently in Eclipse. Another chapter looks
at Qalab and StatSVN, which help keep track of project metrics over
time. Another section looks at how to generate decent technical
documentation, both using Maven and using other tools such as
SchemaSpy, Doxygen, and UmlGraph.
In all, the book looks at 30 or so tools.
5. Why did you decide to include these tools?
is good, and there is no one-size-fits-all solution for software
development. So, in each section, I try to give an overview of the best
open source products around for a particular job, so that readers can
decide for themselves what stack suits them best. And I try to cover
all of the main areas in the development process where open source
tools can help your average developer. Version control, build
scripting, automated testing, continous integration, issue tracking,
coding standards and best practices, automated code documentation: you
need to take care of all of these areas well so that the developers can
get on with their main job: coding.
you set up a development environment, it's also important to have
products that integrate well. In the book, I spend a fair bit of time
discussing how to get the various tools to work smoothly with each
other. For example, one nice trick is using Subversion triggers to
integrate Trac with Subversion, so that when you mention a Trac issue
number in a Subversion commit message, the issue is automatically
updated in Trac with a reference to the modified files. Then, taking
this one step further, you can use Mylyn change sets to keep track of
exactly what files have been modified for a particular bug fix.
6. Are these the most popular ones?
yes. One of my selection criteria was that tools should have a large
enough user community to be sustainable in the long term.
7. Is each of these open source tools covered in great detail?
do tend to go into a fair bit of detail, yes. At around 880 pages, it's
certainly not just an overview! Of course, some are more detailed than
others. Maven 2, Ant, and Subversion get around 100 pages each. Other
tools typically get about 30 pages each. Each chapter is much more in
the spirit of a practical reference manual, rather than just a short
overview of the tool.
8. How long did it take you to write this book?
lot more than I thought it would! I only kept roughly on schedule by
working lots of very late nights and sacrificing weekends. Equinox, and
in particular Roger Dalgleish and Paul Ramsey, also helped enormously,
who gave me time and material support for the book when it was really
needed. The whole thing took a little over a year, plus another 6
months or so for the corrections and publication process.
9. Which is your favorite tool and why?
just one? At the moment, I'm pretty impressed with Hudson. It is very
easy to use, has a slick user interface, and you can set up a very
usable Continuous Integration environment fast and with a minimum of
effort. And all the plugins make reporting a breeze!
10. Can you give us some useful tips and tricks?
an old Maori saying which goes "He aha te mea nui? He tangata, He
tangata, He tangata." Which translates to something like "What is the
most important thing? It is people, it is people, it is people". I
think this is true when you try to improve the software development
process in an organisation. You really need to get team buy-in when you
choose tools, especially ones that impacts the way developpers work on
a daily basis. Make it a collaborative process, and make sure everyone
involved understands what the tools are for and how they should be
used. It's usually a slow process, since people are often reluctant to
change their old habits, but it pays off in the long run.
11. Are you using each of the tools you have mentioned above in your projects?
much. A big part of my day job is to help organisations improve their
software development process, and this involves proposing and
installing tools, and teaching people how to use them. Of course, I
have my preferences, and you have to make choices at some stage. For
example, I've used CruiseControl, Continuum and Hudson in real projects
for different clients over the last few years, but for a particular
client, you only need one Continuous Integration tool.
We even used some of the tools
while writing the book. The book was written directly in docbook
format, and stored on a Subversion repository. The editor, some of the
braver technical reviewers and (not leastly!) myself also used Trac to
keep tabs on changes being made to the manuscript, to plan the review
process, to let reviewers know when a chapter was ready for review, and
so on. So we were eating our own dog food, so to speak!