ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <>
Subject RE: Why does the echo task output to System.out? (Was: RE: [submi t] I ntegration of Ant into Visual Age for Java)
Date Sat, 18 Nov 2000 01:29:46 GMT

--- Jose  Alberto Fernandez <> wrote:
> > From: Simeon Fitch []

> > 
> > One thing to consider is that for a new user deciding between 
> > <echo> and
> > <log> might not be obvious. Keeping the number of tasks that 
> > do similar
> > things to a minimum is a desireable thing IMHO. I think it is 
> > ok to provide
> > different attributes to the <echo> task to get different 
> > behavior rather
> > than different, but functionally similar tasks. Think 
> > (although I'm sure
> > someone out there is going to flame me for this :) ):
> > 
> You are right :-)
> Any OO person would tell you that it is not good to just add
> more options to something for it to do different things, but
> you should instead define a subclass with the modified behaviour.

The Ant input language is not an OO language. It's easy to forget that
there can be a distinct difference in the implentation structure of a task
vs. the invocation structure of a task. I don't think OO semantics
expressed in the implementation necessarily need to be expressed in the
input language. This is doubly so if we want Ant to be usable by the
average "web designer" (I think that's the criteria that has been stated
before) who may no nothing about OO expressions.

> >       echo "my message"
> > vs.
> >       echo "my message" > /var/mylog
> > vs.
> >       echo "my message" | logger
> Not exactly like above, since we are not sending just the output
> of <echo> but also the output of every other task.

I'm only discussing the <echo> task here. I think changing the output
behavior of other tasks is a different discussion.

> Of course, my problem was with:
>   echo "my message" -if-log-level=info |logger

This doesn't quite fit the model I was trying to convey. I don't think
having conditionals as parameters/attributes to the command is a good thing
(yes, I think the 'if' and 'unless' clauses are a hack, no offence to the

> what does this means?
>   <echo message="my message" output="myfile" loglevel="info" /> 

I would interpret it as meaning "send the message 'my message' to the
output file 'myfile' and also log it to the logger at the log level
'info'". Now that you express it that way, I think I like being able to do
both like that. It seems a pretty straight forward way of expressing it.

> Can I compile a file depending on the loglevel?

I'm not sure I understand what compiling has to do with the log level. I
see them as orthogonal items. The loglevel is not a condition, it is an
attribute. The message is generated regardless of the loglevel value. It is
at the listener level that it is filtered out. The <echo> task has no
insight into what log level the current set of listeners. As a matter of
fact, you can change the filtering log level in the GUI mid-build if you
decide you wanted to start seeing, say, debug messages.

> On the other hand:
>   <log message"my message" loglevel="info" />
> says log the message at loglevel info, which is not depending on anything
> the message is always sent and it is upto the logger infrastructure to
> decide if the
> message will be filtered out or not.

How is this any different than just saying 
   <echo message"my message" loglevel="info"/>
i.e. functionally they are synonomous.

> I can imagine ANT bradcasting to multiple loggers each one with its own
> loglevel. So for example the embedded GUI console do not gets all the
> tracing, but a the debug file will.

I guess I prefer to see the "output" and "loglevel" attributes as separate
handlers for the same <echo> operation. So, if a target had the following
in it:
    <echo message="I'm in the foo target." output="debug.log"

Then this message would definately go to the file "debug.log", and show up
on the GUI console if the filtering level was set to "debug".

> Jose Alberto
> PS: By the way, there is also a <fail> task. What should be the behaviour
> of
> that one?

Same as above. I'd probably change the implementation of so that
it derived from, called super.execute() and then throw an empty


Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!

View raw message