[Ann] antmerge 1.0.4 released

[Phillip Lord]

We are proud to announce the release of a new version of antmerge, a
small tool which enables simple inheritance between ant build
files. In this release we have added functionality for tighter linkage
between the files in the inheritance tree. See...

http://www.russet.org.uk/download/java/antmerge/antmerge.html#SEC5

for details.





Antmerge :- providing inheritance for ant build files.

What is it:- Antmerge is a small and simple tool for allowing
inheritance between ant build files. This means you can reuse
build files much more easily than before.

How does it work:- It generates a build.xml from one or more
"super class" files, and a project specific build file. The
end result is a normal ant build file.

Will it work with my build file:- Antmerge will work
on any ant build file. So if you already have your own
"template" build file, you can use this as a "super class".
If not, antmerge provides a number of standard build files
that provide functionality for building, deploying, and
testing applications.

Why should I use antmerge:- Its small, simple, and does not require
you to learn a new format. All of the files it works on are valid ant
files. Very little "buy in" is required. You can try it, and if it
works, you can use it. If it doesn't it's easy to move your build
away from it again.

How is it licensed:- Its freely available under LGPL.

Will users need antmerge to build my project:- No. Antmerge can be used
to generate normal ant build files. Having done this antmerge is not
required to build the project. It will be needed if you wish to change
the build, which will require regenerating the build file.

Who built it:- Phillip Lord([email protected]), and Nick
Sharman([email protected]) as part of the myGrid
(http://www.mygrid.org.uk) project.

Why are you releasing it:- We developed antmerge
to simplify the build process within myGrid. We've found it
to be useful, so we are releasing it in the hope that others
will find it useful also.

Where do I get it:- http://www.russet.org.uk/antmerge.html

 

[AJ]

Wasn't the idea of any to "simplify" things? Now you are introducing
inheritance? Java buzzkill at it's finest.

 

[rkm]

"of ant to simplify" you mean?

Well I guess you could think that based on all the hype.

Really, ant is just warmed over "make", the underlying
concept is not different at all. It does clear up some of
the annoyances of make, some peculiarities regarding white
space, but mostly it just wraps the make concept in a
verbose xml tag language. So saying it simplifies things is
like saying German simplifies English.

Adding inheritance to it might actually be a step in the
right direction, though I think ditching ant tag language
entirely and using straight java code to describe the build
would be better. After all, that's what ant's calling
anyway, so why do I need to learn a new language to describe
the calling sequence?

 

[Phillip Lord]

AJ> Wasn't the idea of any to "simplify" things?

It may have been. And when used simply, ant is indeed simple. However
a build process is often not simple, and then using ant can become
fairly difficult. It's routine to end up with very large ant
files. Once you get to several 100 lines of code for your build, you
start to think about code reuse. Once you have written a tar, javadoc,
or compile, you don't want to do it again.


AJ> Now you are introducing inheritance? Java buzzkill at it's
AJ> finest.


It seemed like a reasonable way of doing things. Its a fairly poor
version of inheritance. It enables you to say "I want exactly the same
as this build file, except for a few bits I want to change". It seems
to work well for me, and has made my life simpler. If you don't want
to use it, then don't. It's no skin off my nose.

Phil

 

[Phillip Lord]

rkm> "of ant to simplify" you mean?

rkm> Well I guess you could think that based on all the hype.

rkm> Really, ant is just warmed over "make", the underlying concept
rkm> is not different at all. It does clear up some of the
rkm> annoyances of make, some peculiarities regarding white space,
rkm> but mostly it just wraps the make concept in a verbose xml tag
rkm> language. So saying it simplifies things is like saying German
rkm> simplifies English.

I would disagree. The one thing that it does not do is wrap up
make. Make had a clear and consistent model, based upon rules, and
targets. Ant does not. If you want to say "file a, depends on file b,
and to get from a to b, you do f", its two lines in make. And hell on
earth with ant.


rkm> Adding inheritance to it might actually be a step in the right
rkm> direction, though I think ditching ant tag language entirely
rkm> and using straight java code to describe the build would be
rkm> better. After all, that's what ant's calling anyway, so why do
rkm> I need to learn a new language to describe the calling
rkm> sequence?

I would agree to some extent, although I think that I would prefer a
more declarative dependency based build tool, a la make. This could
have been modified for the Java cross platform environment, with
something like "tasks" taking the place of the shell commands in make.
And no XML syntax which is terrible to write.

But we have to live with what is, which is why I wrote
antmerge. Interestingly ant is promising to bring an import task in
soon anyway. This might be a good solution, it might not. I shall have
to try it when it's implemented.

Cheers

Phil

 

[catalysoft.com]

I welcome the idea of antmerge for the following reason.

A basic ant script with the usual targets such as compile, distribute,
clean, javadoc etc is about a page of text.
Getting this basic starting script together is a small task for most
projects, but I often write small standalone Java
programs to investigate or test a particular concept before incorporating
the ideas into a larger, main project.

For an investigation that lasts (or is expected to last) a couple of hours
up to half a day, the overhead of
writing the build file sometimes seems too much, when you can compile the
blasted thing in a batch (or shell) file
containing a single javac command.

I know writing the batch file is the wrong thing to do, because what starts
out as a short investigation often
gets bigger than you ever thought it would, and you end up having to write
that ant script anyway.

In summary, I find that the overhead of getting started puts me off using
ant for small projects, and I sometimes
do what I know to be the 'wrong' thing to do. It is a bad state of affairs
when I can justify NOT using the state
of the art build tool for some (albeit small) projects.

So, in my opinion, ant was desperately in need of a mechanism/improvement
for decreasing the size of that
overhead. Ideally, writing a basic build script should not be more work than
writing the equivalent javac/java
commands in a batch file or shell script.

antmerge seems to address this issue, making a basic build file very small
and far less work.
So I like the idea and will give it a go.

Thanks Phillip!

Simon

 

[Phillip Lord]

catalysoft> So, in my opinion, ant was desperately in need of a
catalysoft> mechanism/improvement for decreasing the size of that
catalysoft> overhead. Ideally, writing a basic build script should
catalysoft> not be more work than writing the equivalent javac/java
catalysoft> commands in a batch file or shell script.

catalysoft> antmerge seems to address this issue, making a basic
catalysoft> build file very small and far less work. So I like the
catalysoft> idea and will give it a go.

This was one of my motivations behind antmerge. Although for me the
major one is that I can extend, or fix all of my builds at once,
because I no longer need to duplicate my build files.

catalysoft> Thanks Phillip!

My pleasure. Let me know how you get on with it.

Phil