ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
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 00:49:15 GMT
Replying to my own message.

I think the real problem demonstrated by <echo> is the fact that ANT was not
defined with embbeding in mind. For example we should not be considering
System.out as the standard output of ANT, instead we should provide
an API that allows associating a standard output with an executing project:

	Project p = ProjectFactory.createProject(.....);
	p.setOut(gui.getConsole());
      p.execute().

<echo>'s code should be:

	project.getOut().print(message);

By default, Project.getOut() will return System.out unless changed by the
above API.
Simillarly, one may have Project.setErr() and Project.setIn() and allow
tasks that
may read input: like passwords.

I'll see if I can make some proposals this weekend (if I have some time
left).

Jose Alberto

> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:JFernandez@viquity.com]
> Sent: Friday, November 17, 2000 4:33 PM
> To: 'ant-dev@jakarta.apache.org'
> Subject: RE: Why does the echo task output to System.out? (Was: RE:
> [submi t] I ntegration of Ant into Visual Age for Java)
> 
> 
> > From: Simeon Fitch [mailto:metasim@yahoo.com]
> > 
> > 
> > --- Jose  Alberto Fernandez <JFernandez@viquity.com> wrote:
> > > > From: glennm@ca.ibm.com [mailto:glennm@ca.ibm.com]
> > > > I have to agree with Wolf's analysis of the situation 
> > with <echo>.  In
> > > > fact, I agree so much I've made the changes he's suggested 
> > > > and commited
> > > > them. :-)
> > > > 
> > > 
> > > -1, I would have prefered to keep the logging capabilities for a
> > > different
> > > task.
> > > A subclass of <echo> perhaps. 
> > 
> > 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.
> 
> >       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.
> 
> > vs.
> >       echo "my message" > /dev/null
> > 
> 
> Of course, my problem was with:
> 
>   echo "my message" -if-log-level=info |logger
> 
> what does this means?
> 
>   <echo message="my message" output="myfile" loglevel="info" /> 
> 
> what does it mean to just write to a file depending on the log level?
> Can I compile a file depending on the loglevel?
> 
> 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.
> 
> 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.
> 
> Jose Alberto
> PS: By the way, there is also a <fail> task. What should be 
> the behaviour of
> that one?
> 

Mime
View raw message