ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Feedback on first uses of Ant
Date Wed, 12 Jul 2000 10:51:45 GMT
At 11:30  12/7/00 +0100, you wrote:
>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.

Strangely enough your experience/complaints are exactly the same ones I
have and had to solve. I used to maintain a custom version of Ant but I
kept hacking and it fell to bits :P. Now I am working with base Ant I am
waiting approval or other cases so I can rework and include :P

>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.

Could be a shot thou it may be better to wait until the tag is got to. ie
Don't lookup class at start but instead when you reach the tag. Immediate
mode processing would solve this problem I believe. The only thing it would
stop is using two different versions of same taskdef - which I am not sure
is a regular occurence :P

>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"

The next stage I believe is to keep tasks in jar files. You could then
conceivably maintain a classpath by specifying a Class-Path: in manifest.
Would this work for you ?

>2. Properties
>I started writing a build.xml like this:
>  <target name="jar"/>
>    <buildinfo/>
>    <property name="version" value="${BUILDNO}"/>
>  </target>
><buildinfo/> was my own custom taskdef which set the property BUILDNO
>to a unique build number. Ofcourse, this doesn't work. The property

Yep. I believe there are going to be at least two types of variables in the
future. Immediately evaluated and constants. First type would not get set
to you got to said tag. This would solve that problem but there was some
discussion on whether or not to even allow variables in properties - so I
am not sure what is going to happen. 

>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. 

been fixed recently (within last few days) - you can download it again and
the problems should go away. The task specification has slightly changed thou.

>Also, javadoc requires all the package
>names. As far as I know, you can't say "all the packages below this

yup :P. People have commented on this before. 

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

I am sure you will be welcome then :P (As long as you don't talk about make



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message