RE: [RFE] Richer Task Specification

[ru...@us.ibm.com]

I've thought about this a bit more, and was wondering what people think
about the following idea.

How about a new task which subclasses off of javac.  Its init method calls
super.init(), then super.execute(), then loads and generated class files
and defines them as new tasks?

Nested taskdef elements, with identical syntax to the current taskdef task,
could be used to generate the necessary <include> statements on the javac
and then to define the mapping between classname and task name.  Users
could obviously add their own <include> statements if necessary.

- Sam Ruby

Re: [RFE] Richer Task Specification

[James Duncan Davidson <ja...@eng.sun.com>]

on 6/15/00 5:46 PM, rubys@us.ibm.com at rubys@us.ibm.com wrote:

> How about a new task which subclasses off of javac.  Its init method calls
> super.init(), then super.execute(), then loads and generated class files
> and defines them as new tasks?

Interesting idea.

> Nested taskdef elements, with identical syntax to the current taskdef task,
> could be used to generate the necessary <include> statements on the javac
> and then to define the mapping between classname and task name.  Users
> could obviously add their own <include> statements if necessary.

Could you propose a sample of how this would be stated in XML?

.duncan

RE: [RFE] Richer Task Specification

[Peter Donald <do...@mad.scientist.com>]

At 08:46  15/6/00 -0400, you wrote:
>How about a new task which subclasses off of javac.  Its init method calls
>super.init(), then super.execute(), then loads and generated class files
>and defines them as new tasks?
>
>Nested taskdef elements, with identical syntax to the current taskdef task,
>could be used to generate the necessary <include> statements on the javac
>and then to define the mapping between classname and task name.  Users
>could obviously add their own <include> statements if necessary.

feels like a huge work-around. It would also require copious duplication of
code from Ants other classes (ie ProjectHelper).  I know currently there is
reason not to go to imediate execution of tasks but if you were going to
put in so much effort it could be worth the effort to do it.

Current Problems:

1. it would require building an object tree
2. can't call init before any task execution starts

I don't believe removal of 2 should be a problem for as far as I see no
task relies on it's functionality. Even if it did we could move it to
target level rather than project level. Hence all Initing occurs as a
particular targte gets executed.

1. is a problem because it requires writing more code :P but if you are
going to go to the effort of rewriting a chunk of it anyway then it may be
worth the effort, no ?

BTW if I stepping on toes just tell me to back off :P. 






Cheers,

Pete

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