Strongly in favor of throwing 0.8 against the wall and seeing what
sticks.

Re: logging

What's folks feeling about moving "back" to the Ant-style loglevel
concept?  (quiet, normal, verbose, warning, error).  I'd traded some
mail with Scott about log4net, .config files, and other "wouldn't it be
better if" issues but it seems like the code has hit a cul-de-sac
because of Project.Verbose and Log.WriteIf

Just seems like the logging is kind of stuck not because moving forward
is difficult, but because the changes would effect a big hunk of the
code.  

(Hmmm... I think I just repeated the "we need to rework logging"
discussion.)

So I guess my question is... I'm close to a complete stab at moving to
the Ant style and removing WriteIf and WriteLineIf completely, and
replacing Project.Verbose with Project.LogLevel... does this sound like
a good jumping off point for the "better" stuff?

Brian

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Matthew Mastracci
Sent: Friday, February 14, 2003 7:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [nant-dev] Indenting external program output? + Let's get
this release out

Regardless of future implementation tasks, would anyone object if I 
enhance the ExternalProgramBase to indent output from called programs?
:) 

I agree that we need a more powerful logging system, but as things stand

right now, we have a half-decent one that gets the job done.  Once 0.8 
is finally released, we can start to look at things like this. 

BTW, anyone have anything urgent that needs to go into the release?  If 
not, I can take what we have now and put it out as a release candidate 
for 0.8.  I think we're in a good enough place to at least let people 
give it a whirl.

Simon Steele wrote:

>Hi,
>
>  
>
>>[see below] Is that the kind of thing you had in mind?
>>    
>>
>
>In a way, yes. I was under the impression that all the tasks currently
use
>the Log class to write their build output, and it might be nice to
extend
>this to output something a little better defined:
>
><build-results>
>       <target-output name="target-name"
result="[success|failure|...]">
>               [if verbose]
>               <parameters>...</parameters>
>               [/if]
>               <info>Some info.</info>
>               <info>Some more info.</info>
>               <warning>This is a warning.</warning>
>               <info>even more info.</info>
>               <error class="fatal">Could not build...</error>
>       </target-output>
>       <summary result="failed">
>               <successes>
>                       <target name="target1" />
>                       <target name="target2" />
>               </successes>
>               <failures>
>                       <target name="target-name" class="ignored"
>message="..." />
>                       <target name="target-name" class="fatal"
>message="..." />
>               </failures>
>       </summary>
></build-results>
>
>That's just off the top of my head, so it might be completely
inappropriate,
>but hopefully it gets across the point of having the xml provide useful
>information which couldn't happen (so easily) using the trace system
you
>propose. The meaning of each entry in the log would be much more clear,
and
>therefore (IMHO) much more useful. Either way, I believe the tasks
would
>need changing to use a different output mechanism, and we could use
that
>opportunity to make the output more useful.
>
>(note: obviously we can't necessarily expect to parse the
compiler/other
>tools output and place it into the relevant <info/>, <warning/> and
<error/>
>tags, but in these cases we could include the compiler output in an
<info/>
>tag.)
>
>Thoughts?
>
>Thanks,
>  
>




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to