ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@m64.com>
Subject RE: How to tell what Javac did?
Date Fri, 26 May 2000 11:55:15 GMT
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@bost.de]
>
> >>>>> "AK" == Aaron Knauf <AaronK@geniesystems.com> writes:
>
>  AK> So, do we want to do exit status checking at the Task level or at
>  AK> the Target level?
>
> Both seem to be usefull.
>
>  AK> If at the Task level, how does the next Task check/use the value?
>  AK> (Target has a nice easy if="some.property.present".)
>
> Ask the Project? Let's assume Task.execute returns a TaskResult
> object, this could be put into the project via something like
> Project.setLastTaskResult(TaskResult) and retrieved by the next task
> via say Project.getLastTaskResult().
>
> Stefan

I am in two minds over this whole thread.

When I built my weblogic tasks, I used a Java task internally to invoke a
helper class with a defined classpath. This is a slightly unusual use of the
Java task object. I wanted to know the return code from that Java task, but
there was no way to get at it. If the weblogic tools failed, the build would
continue. My solution to this was more narrowly focused than the proposals
here. I added another entry point into the Java Task which would throw a
build exception if the forked JVM returned an error. The patch for this is
attached. In effect this makes the error code available for internal uses of
the Java task and not to the build.xml level.

So, in one sense I see the use of getting at the return codes from tasks.
And yet, I am wary of bringing visibility of that into build.xml file. It
would seem to increase the complexity of ant either by adding lots of
conditional stuff to build.xml or by building implicit coupling of tasks
through task results.

In the example you give above, a task calling getLastResult() implies a
relationship between two tasks which is not explicitly specified in the
build.xml. As a user of ant I now need to know how one task sets that result
and how another task will interpret it. If the tasks are closely coupled
enough for this passing of result information to make sense, then perhaps
they should be combined into a single ant task.

How will we decide the required structure of task results? The original
request which prompted this thread was a desire to know if Javac did any
work, not just whether it succeeded. So would a return result for Javac need
to specify success/failure, did it do anything? How many files did it
compile? Maybe even which files it compiled or even how long it took?

Even if we could come up with a sensible definition for results, how would
another task use those results. Would it need to know it was using a Javac
result? If we are going to expose the return result at the build.xml level,
how would we do that? through a set of properties?

I like the current inter-task communication. If a task is executing it knows
all previously executed tasks did not fail :-)

Thoughts?

Conor

Mime
View raw message