1/3rd getting builds out

1/3rd improving the build process, writing scripts to reduce #1,
telling developers where to stick their code.

1/3rd chasing the developers who didn't follow #2 with my clueiron
http://codesmiths.com/shed/things/clueiron/

1/3rd generally being sworn at over the phone

Yes.  You also use Bugzilla to request your PC to be fixed, or to
recruit a new developer.

Usually, but not always. The usual culprit is brand new work, where it
hasn't yet been added to our Fitnesse tests. Even when it has been
"added", it needs an active inspection by me to ensure that everything
is as it should be. The process isn't watertight, particularly when
timescales are pressured.

The "Agile" malarkey is great, but it's not very agile. Works a _lot_
better when you're doing incremental work on an established project,
rather than creating new projects.

I considered that too, but it seemed too much like my previous
experience of embedding Java snippets inside my Ant, when what I really
needed was a wrapper around it.

Make is a scripting language interpreter in itself, and uses conventional
shell scripting languages as the basis both for its macros and for its
actions.

They clearly didn't!

There are (at least) three levels here: Make, Ant and procedural
scripts.

Make is a good solution to a problem of 30 years ago, that of reducing
compilation to the minimum number of affected compilation units. These
days compilation is so fast that we just don't care about this - we can
re-compile from scratch in negligible time (certainly compared to
running the unit tests) and so the "blunderbuss" approach to
compilation is adequate. I don't need to spend time (and lots of it)
managing the file-level dependencies I used to do with Make.

Ant is powerful, but I'm increasingly coming to the opinion that it's
power I don't need. It does "task level" dependencies such that I can
re-run the compile target before the JAR-maker, but this is of little
_real_ benefit. I have a big Ant file with lots of separate targets,
but the practicality is that I only ever use two execution paths
through this: "Changed some source, so re-compile it and do the rest"
or "This one is going out to a punter, so run the whole lot from
scratch in clean directories". So there's the great virtue of Ant, and
I'm not even using it. I don't need target dependencies here, just a
few lines of rigid procedural script would be adequate.

I also hate Ant's lack of string-slicing. IMHO (to paraphrase emacs and
email), every scripting tool should expand until it has the ability to
use regexes. It's not much to ask, but I feed my buildfile a build tag
parameter and need to make deliverable zipfiles with names based on it.
This is _painful_ in Ant. One of my Ants has about 800 lines of 1500
total devoted just to parameter-handling logic. I could probably
replace this with 20 lines of Python / Visual Basic.

When I started this project, I went through an aberrant phase of
writing custom Ant tasks. These were supposedly great - I could do
anything, my Ant was simple and elegant afterwards, and we're a Java
shop so the language was familiar. I no longer do this anywhere, and
would be most reluctant to ever do it again. Custom tasks are a
terrible way to work - just don't go there!

The problem is that custom tasks split your build in two, quite
probably even in two different editors. If you have "business logic" in
the build, this is an obvious maintenance problem.

_Extending_ Ant by writing new tasks is OK, provided that the
requirements for the task are sufficiently generic. A task that
understands regexes is one thing, because it's stable within itself. A
task that understands your local build tag format and maps it in and
out of SVN paths is quite another problem -- day-to-day maintenance and
process development means working across two platforms, with an
unstable interface.

I'm also reluctant to use Ant tasks that are outside the basic Ant
package (so JUnit and FOP are just about OK) because I have to assume
an Ant environment in many locations, even customer sites. It's no use
using Ant for an easy product deployment if I first have to work
through a non-standard Ant deployment.

Ant might still have something to offer for multi-platform deployment.
Problem of the week is deploying what began as a pure Tomcat
development onto Weblogic / Websphere and JBoss as well. This is messy
and Ant (or at least the Ant community and collected best practices)
has things to offer for cleaning it up.

So if I don't (very often) need task-level dependencies and I don't
need file level dependencies in compilation, then what's left for Ant
to do ?  And of this remainder, is Any any good at doing it?

As I mentioned before, I'm moving to more and more scripting (Python)
but keeping this outside a somewhat arbiitrary boundary of the
Internal/External build. With hindsight though (and some process dev
time before the build-request-batphone next rings) I'd certainly be
thinking about a pure procedural script approach.

Agree with this question! Only bad makefiles looked like scripts. Good
makefiles used the dependency facility which is declarative. However,
most makefiles I have seen became highly procedureal because the
maintainers did not understand the declarative approach of make.

Kind regards,

  Peter Kriens

Ant is a batch file interpreter that understands XML and has flow control via
implicit gotos (task dependancies).

Ant is a scripting language. Make one target, stick a sequence of tasks
in it. Use <antcall> as a subroutine mechanism. You've got yourself a
scripting language.

It's not a _good_ scripting language, but it's still better than
Windows offers.

The question is whether Ant's advantage of _also_ (and separately)
being a dependency-flattening langauge is sufficient to excuse the poor
scripting features, when our application of it is generally more
dependent on scripting than anything else.