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...