Hi Nicke, good call I think. Verbosity problem is here, and I really want so solve it, but I prefer to do it after release. I also think (and beleive others also) we need shorter release cycle (aprox. 4 a year?) 1/: I didnt catch it - sorry. Structure of Nant's XML log is pretty vague - thats true but I never notice, it is problem somewhere. 2/ log file size: I dont think there is any good was to reduce logs unless precize verbosity threshold feature is introduce. Any information could be valuable. 3/ verbosity: many tasks have today use wrong message levels. I personally also gets many errors/warning on mine CCNet console when running xmlpeek failonerror=false. Your readregistry seems to be same problem. Solution task is other thing. It calls other tasks (like resgen or copy) and those produce many garbage. What about to change Info level messages from all nested tasks to Verbose level? Error/Warning should remain same.
Martin ------------------------- From: .. On Behalf Of Nicklas Norling Sent: Friday, November 19, 2004 12:30 PM To: [EMAIL PROTECTED] Subject: [nant-dev] Nant XmlLogger Hi. I have a few questions and thoughts about the XmlLogger facility in NAnt. I'm currently been using 11-15 nightly but basically as long as I've used the XmlLogger to provide data for CCNet there have been all kinds of problems with this logging. As 0.85 seem to draw closer I thought I'd better brought this up before the release rather then after. These are the main problems: 1. None-functional XML structure. This is only indirectly getting me into trouble as other tools relying on the Nant XML file can not figure out what's failing and what's not due to the information structure (or so I've been told). I wonder what lovely things CCNet and other teams could do if this worked. 2. Log file size. I have around 2 MB large logs after each build. Due to item 1 above developers do often not get to know what went wrong from the CCNet so they have to look at the raw log using i.e. IE (please note the rime). Over a 100 MBit connection this takes around 15-30 seconds depending on the computer. But lots of our devs (several hundreds) are using this over a 512k line. It takes ages to load the log file for them and it's also a very slow process to find the relevant information at times. 3. Verbosity Most of the 2 MB log file consists of spam. Empty tags denoting a task running. Worthless INFO and DEBUG style entries. Let me take some examples by giving you a walkthrough of my builds. My main build script begins with a clean task to remove the old build artifacts. Here is the snipplet: <foreach item="Folder" property="foldername"> <in> <items> <include name='client\**\bin'/> <include name='client\**\obj'/> </items> </in> <do> <delete dir='${foldername}' /> </do> </foreach> And the log it procuces. <target name="clean"> <task name="foreach"> <task name=""> <task name="delete"> <message level="Info"><![CDATA[Deleting directory 'C:\CodeModules\Test\Montgomery\modules\fndadm\client\EventAdministration\bi n'.]]></message> </task> </task> <task name=""> <task name="delete"> <message level="Info"><![CDATA[Deleting directory 'C:\CodeModules\Test\Montgomery\modules\fndadm\client\EventAdministration\ob j'.]]></message> </task> </task> .... All of those log entries sums up to quite a few. But what for? The only need I can see is if the task failed, but it's not. A programmer would probably like to see that his delete task is finding it's target and that the code gets ran, but as a end user of nant it becomes an annoyance to have to scroll through. Next my build fetches the latest code from cvs. This time I'm actually interested in what comes out as that will eventually get transformed by CCNet into a build mail and a web page. Here's the snipplet: <target name="cvsup" depends="init"> <exec program="${cvsprog}" commandline="-q ${cvscompress} -d${cvsroot} update -d -P" /> </target> When this task is logged normal information from CVS is logged as warnings: <message level="Info"><![CDATA[U Montgomery/modules/fndadm/client/ManageUsers/UserRolePicker.resx]]></message > <message level="Warning"><![CDATA[cvs update: Montgomery/modules/fndbas/model/ImplementationModel/EntityPackages/entitypac kage_ArtifactCache.xml is no longer in the repository]]></message> CCNet thinking it better alert me will transform this into the Warning section of the email and webpage. But it's an informal message. Now it's time to do the actual compile. I'm using the <solution> task: <solution configuration="Debug" solutionfile="${filename}"/> This is the log result for one of the project (the solution contains around 30 of them): <message level="Info"><![CDATA[Building 'Ifs.Fnd.Explorer.Interfaces' [Debug] ...]]></message> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> <task name="copy" /> This then continues with the rest of the 70 or so solutions we have. I can understand that the solution task needs to copy references local, but do the log really need to have each and every copy logged without any info in it? To me a failure to copy is quite enough. If the project contains a resx file (or several) the resgen task logs each compile: <task name="resgen"> <message level="Info"><![CDATA[Read in 0 resources from 'C:\CodeModules\Test\Montgomery\modules\fndwin\framework\Controls\Ifs.Fnd.Wi ndows.Forms.CommonControls\FndTreeView.resx']]></message> <message level="Info"><![CDATA[Writing resource file... Done.]]></message> <task name="delete" /> </task> I don't see any usage for any of this information. Once again it seems to me it's giving a programmer good debug info but a builder is having a hard time sorting out the important stuff. I'm estimating 1/3 of the file is filled with the debug info from the solution task. Next after the build is complete I run FxCop. In order to do that no matter what machine I'm reading the registry to find the key. This snipplet does it: <readregistry property="fxcop.path" key="Software\Microsoft\FxCop\InstallRoot" hive="CurrentUser" failonerror="false"/> Note the failonerror="false". This is what ends up in the log when the key can not be found (normal thing as it can be installed as Me or for All). <task name="readregistry"> <message level="Error"><![CDATA[Registry Path Not Found! - key='Software\Microsoft\FxCop\';hive='Microsoft.Win32.RegistryHive[]';]]></m essage> </task> This needless to say also ends up in the Error section of CCNet build mails/web page. Next FxCop encounters one of our projects that hasn't got a reference set up correctly. This is what the Exec task ends up logging: .... <message level="Info"><![CDATA[WARNING: the following missing references were detected.]]></message> <message level="Info"><![CDATA[Analysis might be compromised. Use the '/directory' switch.]]></message> <message level="Info"><![CDATA[to specify additional assembly reference search paths.]]></message> <message level="Info"><![CDATA[* Microsoft.Vbe.Interop Version=10.0.4504.0, used by:Microsoft.Office.Interop.Word]]></message> <message level="Error"><![CDATA[C:\CodeModules\Test\Montgomery\modules\fndwin\package s.build(119,6): External Program Failed: C:\Program Files\Microsoft FxCop 1.312\FxCopCmd.exe (return code was 512)]]></message> I'm aware of this problem but there isn't much I can do about it at this time. It will still analys the rest of the code so I wan't it to run. I figure the only sane thing to do is setting failonerror="false". This gives the same problem as above. Another Error in CCNet. Is there anything that can be done to improve the situation before the release? I think that a lot of people would appretiate that a lot. With the very high quality 0.85 has a good chance of sustaining I find it very likely lots of people will not run as much on nightlys as they have. And with a release cycle of around a year it seems shame that the logging isn't in a better shape then it is now. Am I way off here? /Nicke ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers