ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <james.david...@eng.sun.com>
Subject Re: [RFE] Richer Task Specification
Date Thu, 22 Jun 2000 10:01:26 GMT
on 2000/06/20 01:35, Stefan Bodewig at bodewig@bost.de wrote:

> 1. Don't treat properties as tasks at all. Don't even say they are
> tasks in the documentation.
> 
> 2. Do the same for taskdefs.
> 
> 3. Don't instantiate tasks before they get executed.
> 
> 4. Merge init and execute into a single method that gets called right
> after the task has been configured.

Souds good. Can you update the core spec thingy that I started to reflect
this?

> The only tricky thing in this is part 3.

Not really tricky, just a smop.

> One solution would be to revert to a DOM tree and defer parsing of the
> tree part below targets until the target gets executed. Neither too
> difficult nor elegant.

Eewwww...

> Another solution would be the proxy pattern Sam suggested a while
> back. Configure a proxy object for the task at parse time and that
> again instantiates, configures and executes the task when it's time to
> get the work done.

Or you might be able to get away with a simple table structure that carries
all of the information. This is something a bit simplier than proxys. But
the thought is the same. This is the way to go.

> This latter solution might even have the additional power to choose
> between several special implementations of a generic task (choose
> between classic/modern javac or jikes or ..., choose the vendor
> implementation of idl2java, sqlj or similar things) like Valentin
> suggested. I'm not sure how to implement this easily without having to
> modify all existing tasks though.

Makes it real easy, and depending on how much of the model is exposed to
scripting, you should be able to tweak taskdefs on the project at will which
would affect the things that you want to do.

> The only drawback I can see is that errors like misspelled attribute
> names in the build.xml won't get caught before the task gets executed
> as the proxies would need to accept all attributes.

Not really a drawback. At least the error is still localized to the exact
place it needs to be. Doesn't really matter that the preceeding tasks
executed -- it's not much different than "normal" failures.

.duncan


Mime
View raw message