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