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.
  -I think the the core tasks should be easily reusable and extendable.
  -Tasks should probably take a project on construction, but this is a big
change. If this can't be done, setProject() should be public.

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.

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.

5) The main loop in StreamPumper.java (IMO) has some issues:
  -The input stream is not buffered, and could overrun.
  -The loop relys on the InputStreams closing for read() to return. This
works for the sub processes output, but not for its input. I'd prefer
something like:

while( keepReading ) {
  size = available();
  if( size > 0 ) {
    read( buf, size );
    write( buf, size );
  } else {
    sleep( SLEEP );
  }
}

Then the PumpStreamHandler should (gracefully?) request that the
StreamPumper stop reading.

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

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

Thanks

Paul

Reply via email to