ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: Initial impressions of ant...
Date Mon, 23 Jul 2001 23:57:32 GMT
> From: Paul Kilroy []
> I'm in the process of migrating our project to ant, everything
> went smoothly
> except the following:
> 1)I initially tried to write a task that used (w/o inheritance) the Java
> task. This was too hard IMO. Had to set the project on the Java task, but
> the method was package scoped, so I had to play some silly games.

You should probably use project.createTask("java"). This will properly
initialise the Task. I guess it is a bit like servlets in a servlet
container. You can't just create them and hope they will be connected into
the container's infrastructure. It is the same in Ant.

>   -I think the the core tasks should be easily reusable and extendable.

There are services for executing java programs within Ant (ExecuteJava) and
these should be used in preference to configuring a task. I believe you
should be using these services. Reusable and extendable tasks are nice but
it also creates an ongoing commitment to backward compatability. I think
that guarantee should be made in the services not the tasks layered on these
services. We need to control the scope of the API Ant makes available to
task writers to make upgrading Ant manageable.

Of course, many times it is nicer to use the Task interface, but that is a
failing of the underlying services

>   -Tasks should probably take a project on construction, but this is a big
> change. If this can't be done, setProject() should be public.

I would not want to see a setProject that is public. It may create
expectations that a task could be moved to another project at will. This is
not so.

> 2) Core tasks should do more parameter checking. On the java task, I set
> failonerror to true AND fork to false. This should probably
> produce an error
> / warning.

Why? Just because the current code always returns an error code of 0, does
not mean this is a valid combination of attributes. In fact, I have been
working on a patch to capture System.exit calls and return the status value
even for non forked code. This would make this combination valid.

> 3) When I wrote my first custom task, my create method returned null, this
> caused an NPE in ant code. Core code interacting with user code should be
> more defensive.


> 4) Java code that is forked has no access to input.
>   -There was a TODO in the code for this, I submitted a patch for this to
> the mailing list a few hours ago.

OK, I'll check it out.

> 6) ClassLoaders are not cached. There was some discussion on this ealier
> related to loading new tasks. I'd like to point out that this
> could also be
> helpful for running java code too. Here is my situation:
>   -I start ant w/o anything in the classpath. I read a property
> file to find
> out what my classpath needs to be. I then run a series of 60
> small programs
> to configure and load my database. Each of these 60 programs
> needs this new
> classpath. Currently (if I'm not mistaken) ant creates 60 ClassLoaders and
> loads these classes over and over.

I'm currently mulling over classloader caching. One concern I have is that,
certainly on Windows, the classloader will retain read locks on the jar
files in the classpath. These can be the cause of mysterious "access denied"
errors when people try to delete these jar files. So caching can be a
problem too. One possibility would be to create a classloader data type

<classloader id="common">
    <classpath refid="blah"/>

   <classloader refid="common">

let me think about that a bit more.

>   -I think adding an argument to tasks that take classpaths like "cacheid"
> or something, might help this.
> Other Questions
> ---------------
> -How can I run a task on a build failure? Do I have to use a listener?

You currently can't run a task on build failure. We have talked about this
previously. Check the archives. Probably we can discuss this again.

> -I thought it would be interesting if a target knew how to "clean" itself
> up. This could be specified in the target along with how to
> "build" it. Any
> thoughts?

I don't like it much.

> -I can do most of this work I described above. What is the
> process for this.
> Create a bug, then write a patch? Or just submit a patch? Or
> something else?

It depends on you to some extent.
I like it when people create a bug report as it can be tracked - It doesn't
get forgotten. Nevertheless, patches to the dev-list are also effective.

Checkout these links for a guide to how things work

This link covers patch formats, etc


View raw message