--- Jose  Alberto Fernandez <JFernandez@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/