RE: Why does the echo task output to System.out? (Was: RE: [submi t] I ntegration of Ant into Visual Age for Java)

[Simeon Fitch <me...@yahoo.com>]

--- Jose  Alberto Fernandez <JF...@viquity.com> wrote:
> 
> > > 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.
> > 
> 
> By that definition then:
> 
>  <echo message="my message" output="myfile" />
> 
> this will log the message to the logger, eventhough I wanted to write a
> file.
> This is so, because you are defining echo as having default loglevel
> "warn"(sp?)

Default log level is currently MSG_VERBOSE (as defined in BuildEvent),
which may or may not be the correct level for <echo> semantics. Probably
MSG_INFO is better. In any case, the log message will still go to the file
"myfile", and any BuildListener who pays attention to BuildEvent objects
with a log level value of MSG_VERBOSE or above can do what they will with
it.

> 
> So the above is equivalent to:
> 
>  <echo message="my message" output="myfile" loglevel="warn" />
> 
> how do I say just write this to the file!!!
> 

You don't. I think all messages should be available to any listener who
wishes to processes it. I don't think there should be any message hidden
from the build listeners. It still gets written to the specified output
file, and who knows, maybe there is a good reason for others monitoring
these type of messages. Why limit ourselves? If we go with the approach you
previously proposed where the PrintStream is set at startup (either
System.out, or some GUI connected stream), then only one output can
registered at a time to get the messages (unless you implemented a
multiplexing output stream...). I think an event based delivery mechanism
is much more powerful.

 
> Every time people clump together to different tasks into one just because
> 
> it is easy, I looks to me like a hack. 

I think that is unfair, as I'm not proposing it becuase it is "easy". I
happen to think it's desireable behavior. It's OK for us to differ on this
point, but it's certainly not because I'm in some camp that of people who
like to "clump together two different tasks... just because it is easy".

> One thing is to log something
> a different thing is to write the content of a file as part of the
> build. In particular <echo> is used to create property files and so on
> why would such file contents go to the log subsystem.

Maybe I'm totally misunderstanding the purpose of <echo>. I thought <echo>
was for printing informative messages to the user, not for creating
property files. If there is a requirement for creating property files,
perhaps that is where a <export-properties> task is needed instead of
"clumping" property writing into the <echo> task.

Again, if I'm "Joe New User" and I want to print out a message during build
execution, <echo> jumps out as the task to use. I don't care what tool I'm
using around Ant, I just want to always see the output of <echo>.
Regardless of whether the user is using Ant in command line mode or useing
Antidote, that message should be delivered via the BuildListener API, where
the registered listeners can determine what the proper handling for the
message is. If there are five consoles they should all be able to see the
messages if they like.

Again, it is just a difference of opinion between us as to what the
semantics of <echo> should be, not an issue of me looking for the "easy"
solution.

sim

__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

Re: Why does the echo task output to System.out?

[Stefan Bodewig <bo...@apache.org>]

Conor MacNeill <co...@m64.com> wrote:

> Yes, the issue really applies to all Tasks and so, perhaps, the
> mechanisms for redirection should be supplied in the Task
> superclass.  System.out/System.err would be set to either a
> logOutputStream or a FileOutputStream and the particular task
> execution could ignore the whole issue, just writing to
> System.out.

Most of them could, yes. <java> needs to keep track of an output file
for forked execution for example, but in the general case this should
work.

> When using the LogOuptutStream, log levels would not be
> settable, just coming out as MSG_INFO for System.out and MSG_WARN
> for System.err.

This seems to be the convention that has always been used in <exec>,
so I'd say yes.

> A separate <log> task with the ability to write a message at a
> particular level may still be useful.

Yep.

Stefan

RE: Why does the echo task output to System.out?

[Conor MacNeill <co...@m64.com>]

> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> There already is a LogOutputStream class for exactly this type of
> thing.

Umm - should have looked :-)

> I had modified the java task to support output files shortly
> after the release, so it should be quite easy to plug in a
> LogOutputStream into it. Other tasks like <junit> may have different
> issues.
>
> One thing to note here (<java> task) is that we are going to face the
> same problem we had with <echo> in a slightly different way. This task
> has a outfile attribute to redirect the output - and obviously nobody
> ever thought of using the logging system in any other situation - so
> it's either write to the file or to Ant's logging system (to ensure it
> ends up somewhere where the user can read it).

Yes, the issue really applies to all Tasks and so, perhaps, the
mechanisms for redirection should be supplied in the Task superclass.
System.out/System.err would be set to either a logOutputStream or a
FileOutputStream and the particular task execution could ignore the
whole issue, just writing to System.out. When using the LogOuptutStream,
log levels would not be settable, just coming out as MSG_INFO for
System.out and MSG_WARN for System.err. Either that or we create a new
log level for task output, such as MSG_OUTPUT. A separate <log> task
with the ability to write a message at a particular level may still be
useful.

Whaddaya reckon?

Re: Why does the echo task output to System.out? (Was: RE: [submi t] I ntegration of Ant into Visual Age for Java)

[Stefan Bodewig <bo...@apache.org>]

Conor MacNeill <co...@m64.com> wrote:

> We are also going to need to handle the case of java classes,
> executed by ant in-VM, which write to System.out. This output should
> be directed to the log with MSG_INFO for System.out and MSG_WARN for
> System.err. We will probably need a LogOutputStream for this. This
> is similar to the LogStreamHandler for java classes run in a
> separate VM.

There already is a LogOutputStream class for exactly this type of
thing. I had modified the java task to support output files shortly
after the release, so it should be quite easy to plug in a
LogOutputStream into it. Other tasks like <junit> may have different
issues.

One thing to note here (<java> task) is that we are going to face the
same problem we had with <echo> in a slightly different way. This task
has a outfile attribute to redirect the output - and obviously nobody
ever thought of using the logging system in any other situation - so
it's either write to the file or to Ant's logging system (to ensure it
ends up somewhere where the user can read it).


Stefan

Echo vs Log (was re:....)

[Alan Gerhard <AG...@E-SyncNet.Com>]

[specifically in response to Connor MacNeill and Stefan Bodewig]

To add to the confusion -
Echo is more of an on the fly user-defined "echo" of string information based on what phase the moon happens to be in for a particular implementation - in other words it is highly specialized based on the implementer. The usual destination for this type of this output is to stdout and is used to inform the user of various stages, etc.

Log is specifically tracing the activities (tasks) and arguments that were executed during an Ant Session. The usual destination for this type of output is a file and is usually used as a type of audit trail - to determine if a particular task was executed and with what arguments; especially when verifying the validity of a particular build in retrospect.


av SB ->
> It would probably be cleaner to have two separate tasks, one for
> writing text - maybe redirecting it to a file - and one for writing
> log messages. I'm just not sure, which of both would deserve the name
> echo.

The existing task -Echo - does just that - Echo's text.
Writing to a log file ( by explicit intent ) enters the activity of an Ant Session into a journal - or a log book.
I would think that the naming of the tasks would follow the functionality they perform; wouldn't you??

As mentioned, a clear distinction between the two tasks, both in the ideological definition of it's implementation as well as in name, will result in a much cleaner code - both in execution as well as in maintenance ...

From what I can gather, Echo used to dump to System.out but was fixed to use a PrintStream which I hope is set to System.out when lacking other specifications - which allow backwards compatibility as 
as well as a consistent means of operation when not in the proposed GUI. This also allows Echo to be dumped to a file .. be we are there already. Sorry for my digression.

With this done, some of the problems in echoing output to a GUI disappear by supplying the appropriate PrintStream which can then be piped to whatever conduit is deemed necessary.

So in concert with you both, I too agree that there should be two separate and distinct tasks to perform these different functions - but we already have a logging facility embedded in the Task class...

RE: Why does the echo task output to System.out? (Was: RE: [submi t] I ntegration of Ant into Visual Age for Java)

[Conor MacNeill <co...@m64.com>]

> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> It would probably be cleaner to have two separate tasks, one for
> writing text - maybe redirecting it to a file - and one for writing
> log messages. I'm just not sure, which of both would deserve the name
> echo.
>
> If we keep them as one task (which might be easiest for new users, I'm
> not sure) maybe we should say you can either specify outfile or
> loglevel, but not both of them? If you don't specify outfile we use
> the logging system, if you do we'll write to the file.
>

Personally, I think we should have two different tasks, but perhaps
diced a little differently. Rather than having one task for writing text
and one for logging, I would have one task for writing to files and one
for logging. IMHO, the only place to "write text", if you are not
writing to a file, is to the log. In the general situation, we cannot
assume that we can write text to System.out. It won't make sense in the
GUI situation.

So, I support a <log> task with a log level attribute and no file
"output" attribute. You are writing to the log and it is up to the
logger where that output gets written. I prefer the name <log> over
<echo> as it is clearer what is being done by the task. The second task
is JUST for writing to files. I'd probably call it something verbose
like <filewrite> to be explicit what it does. I like being explicit :-).
It has a mandatory "output" (or "file") attribute, an "append"
attribute, and NO "log level" attribute.

As for the <echo> task, I'd deprecate it. If it is not writing to a
file, I would make it log with MSG_INFO. It would not have a log level
attribute.

We are also going to need to handle the case of java classes, executed
by ant in-VM, which write to System.out. This output should be directed
to the log with MSG_INFO for System.out and MSG_WARN for System.err. We
will probably need a LogOutputStream for this. This is similar to the
LogStreamHandler for java classes run in a separate VM.

Conor

Re: Why does the echo task output to System.out? (Was: RE: [submi t] I ntegration of Ant into Visual Age for Java)

[Stefan Bodewig <bo...@apache.org>]

Simeon Fitch <me...@yahoo.com> wrote:

> --- Jose  Alberto Fernandez <JF...@viquity.com> wrote:
>> So the above is equivalent to:
>> 
>>  <echo message="my message" output="myfile" loglevel="warn" />
>> 
>> how do I say just write this to the file!!!
>> 
> 
> You don't.

This is taking away part of <echo>'s functionality. The output
attribute has been added to <echo> to have a simple means of writing
files from inside the build file. This use case is in no way connected
to logging at all.

> I think all messages should be available to any listener who wishes
> to processes it. I don't think there should be any message hidden
> from the build listeners.

But if you specify outfile, you want to write to a file, you don't
intend to log messages. It's some kind of poor man's editor, similar
to using echo in shell scripts and batch files.

>> Every time people clump together to different tasks into one just
>> because it is easy, I looks to me like a hack.
> 
> I think that is unfair, as I'm not proposing it becuase it is
> "easy". I happen to think it's desireable behavior.

In a sense both of you are right. The echo implementation we have now
is somewhat similar to /bin/sh's echo builtin or the one of
COMMAND.COM (or is this really an executable of its own?).

It would probably be cleaner to have two separate tasks, one for
writing text - maybe redirecting it to a file - and one for writing
log messages. I'm just not sure, which of both would deserve the name
echo.

If we keep them as one task (which might be easiest for new users, I'm
not sure) maybe we should say you can either specify outfile or
loglevel, but not both of them? If you don't specify outfile we use
the logging system, if you do we'll write to the file.

Stefan