ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Malcolm Sparks" <malcolm.spa...@iona.com>
Subject Feedback on first uses of Ant
Date Wed, 12 Jul 2000 10:30:45 GMT
Hi,

Firstly, congratulations to everyone who has contributed to Ant. We've
managed to replace an imake system that took months to create in just a few
days by using Ant. I thought I would offer some feedback and first
impressions- you always forget your first experiences when you are familiar
with a product.

So, here are the problems we had:

1. Taskdefs

Taskdefs are great, we would have been really stuck without them. Some of
our projects have their own taskdefs which need to be maintained. The
trouble is when it comes using Ant itself to build recently modified taskdef
code. First off, Ant loads the classes declared as taskdefs, then perhaps
rebuilds a taskdef, and then goes on to use the taskdef in another target.
This only works if you stop Ant after it has rebuilt the taskdef, and then
rerun it. This could be fixed by excluding the custom taskdefs from the
system CLASSPATH and having Ant use a custom classloader for loading
taskdefs when they are found in a target, rather than at bootup time.

Custom taskdefs often depend on other jars. In our J2EE work we have lots of
J2EE jars that aren't in the standard Java runtime. Often we find the
taskdefs build OK, but then when they are used we get ClassNotFound
exceptions since the dependent classes are not in Ant's bootup classpath. It
would be good if Ant let you specify this:

<taskdef name="dosomething" class="com.acme.MyCustomerTaskDef"
classpath="${myjars}"/>

This could be implemented by a custom class loader.

One of the things I really love about Ant is that I remove my system
classpath and give control to Ant. Everyone can see what is going on, there
is no hidden environmental dependencies (notwithstanding the taskdef
caveat). This means I can ensure that all the developers on my team are
building from the same components. Great job.

2. Properties

I started writing a build.xml like this:

<project>
  <target name="jar"/>
    <buildinfo/>
    <property name="version" value="${BUILDNO}"/>
  </target>
</project>

<buildinfo/> was my own custom taskdef which set the property BUILDNO
to a unique build number. Ofcourse, this doesn't work. The property
"version" is null, because all properties are resolved (ie. their variables
are substituted with values) in advance of other tags being parsed. I
believed that property substitution happened dynamically running statically.
I soon discovered I was wrong. Is there a good reason for this? Can it be
configurable?

3. Javadoc

We had to add support for -docletPath to get our custom javadoc doclets to
work. The javadoc taskdef doesn't quite correctly anticipate scenarios when
the standard doclet is not used. Also, javadoc requires all the package
names. As far as I know, you can't say "all the packages below this
directory", so this is the only reason we have to keep a package list. We
had to do this in our imake system and it was a great bonus to be able to
dispense with it, only to find we have to maintain one after all just for
javadoc.

4. Sharing properties between projects

We have lots of properties that are duplicated in projects, such as the
location of certain jars and important directories. To remove duplication,
we wrote our own <load-properties file="foo.properties"/> tag which read the
properties file sequentially such that we could do the following in our
properties file:

build.dir="/home/malcolm/build"
build.jar="${build.dir}/classes.jar"
x.cp="${build.jar}"

java.util.Properties is obviously an unordered Hashtable, so there's no way
of assuming the order of the properties. That's why <properties
file="foo.properties"/> couldn't support variable substitution. Perhaps our
workaround is a bit evil, but it helps us avoid lots of duplication.

5. A wacky suggestion

Has anyone considered the overlap between an ant build file and a JSP with a
build tag library? JSPs also support some degree of in place Java, and
expressions and so on. Jakarta has it's own JSP implmentation. The build.jsp
file could be compiled into a servlet which is then invoked by ant, which do
es the build. Perhaps the output of the JSP would be the results of the
build, and this would also allow remote building from the web. Taskdefs
would simply be tag library extensions, and all sorts of extra facilites
provided by the servlet engine provider (logging, EJBs, connectors, etc.)
would be available to the build script writer.

That's it. Personally speaking, I'd be happy to contribute programming time
to the Ant project.

Best regards,

Malcolm


Mime
View raw message