ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@mad.scientist.com>
Subject Re: [RFE] Richer Task Specification
Date Wed, 14 Jun 2000 11:29:57 GMT
At 12:55  14/6/00 +0200, you wrote:
>>>>>> "PD" == Peter Donald <donaldp@mad.scientist.com> writes:
>
> PD> What I would like is some method of knowing how to preprocess
> PD> properties so that they are in form task wants.  [...]  This
> PD> would also mean it would be possible to have properties that are
> PD> not strings and in fact could effectively be any Object.
>
>Peter, take a look at spec/core.html. Some things you want are already
>there, some things have been discussed and even been agreed on but
>unfortunately the document hasn't been updated to reflect this.

oh .. working of oldish (about a month) cvs copy thou I will have a look :P

>Basically it has been agreed that project properties as well as task
>attributes should be richer objects not just plain strings. 

oh just in case there was confusion when I say properties, I meant JavaBean
properties and thus attributes in build.xml not <properties .../> elements :P.

>The way to
>go for attributes (IIRC) was to use classes with a constructor taking
>a String object as its only argument.
>
>Say you have a task Foo with an Attribute named bar of type Baz then
>you would need:
>
>public class Baz {
>    public Baz(String value) {...}
>    ...
>}
...snip...

okay ... sounds good for user created types but how about standard types in
java library .. it would mean that you have to restrict properties to new
classes you are willing to define but I guess that may not be too much of a
problem except for the primitive type wrappers ...

>I don't know what to do with the processing part of your idea
>though. I view this as very tightly coupled to the task at hand in
>most cases - with the exception of file lists maybe, but then using
>DirectoryScanner seems a reasonable approach to me. I'm not convinced
>that moving the processing out of the individual tasks into Ant's core
>would be a good idea.

perhaps not sure ... but howmany wrapper classes will there end up being.
Currently I factored out a lot of functionality from other classes (like
package listing from javadocs task) and am seeing repetition of same
calling over and again in my own tasks. This led me to believe there has to
be a better way ... not sure if this is it thou. I just hate seeing the
same two lines or copied methods all through my code 

>
> PD> Request 2:
>
> PD> Would it be possible to have a bunch of standard ant properties
> PD> in Tasks that effect project in other manners.
>
>We should have properties that are named and used in the same way
>across different tasks. Other than that I don't think I understand
>what you mean. 
>
>Your example would be tied to the Javac and maybe the Java task, so
>let's make sure they use the attribute classpath consistently.

unfortunately classpath usually has to happen *before* task is loaded .. ie
you have to load the task through the new classloader .... you can hack it
now (which is what I do :P) by either recursively delegating to another
task or starting a new vm.

> PD> Request 3:
>
> PD> This would allow a single build file to compile the taskdefs it
> PD> needs and then use those in turn to do further processing.
>
>That is you want to build the Task and use it in the same build file,
>right? I've never thought about doing something like this
>myself. Maybe you are trying unusual things 8^)?

probably .. I am not sure it is a good idea thou .. just throwing thoughts
out really :P

>
> PD> Request 4:
>
> PD> A standardised set of taskdefs for invoking standard C/C++ tools
>
>I think after Ant has settled there will be some kind of library for
>optional tasks - hopefully somewhere under the Jakarta umbrella but
>not necessarily in the same repository. I view things like this as
>prime candidates for "standard optional tasks" i.e. optional tasks
>with an implementation from the Ant developers.
>
>A draft on how to handle optional tasks in future versions of Ant can
>be found in spec/core.html again.

off to have a look ...

But before I go there is another Request that I forgot to mention (that is
not patently absurd :P). That is that input and output get wrapped before
each task executes. Some of my tasks produce excessive verbose output that
I can't really hide. I can't hide it as I often delegate to classes that I
don't own or to native apps. 

So what I would like to see is to replace System.out with a custom
PrintStream before execution. This PrintStream buffers output until end of
task. If the task ends in error the output is printed out but otherwise it
is silenetly ignored. This behaviour can be modified by properties ... err
attributes of the task element such as 
<some-task ant:force-output-display="true" .. /> or something similar.
While this could be done in the task it is useful to multiple targets and
should possibly placed in core ???


Cheers,

Pete

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

Mime
View raw message