Menu
▾
▴
ccnet-devel — Development List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(33) |
Jun
(44) |
Jul
(40) |
Aug
(23) |
Sep
(26) |
Oct
(41) |
Nov
(37) |
Dec
(42) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(40) |
Feb
(58) |
Mar
(81) |
Apr
(94) |
May
(77) |
Jun
(83) |
Jul
(55) |
Aug
(118) |
Sep
(51) |
Oct
(193) |
Nov
(77) |
Dec
(17) |
| 2005 |
Jan
(56) |
Feb
(87) |
Mar
(83) |
Apr
(155) |
May
(115) |
Jun
(157) |
Jul
(90) |
Aug
(87) |
Sep
(145) |
Oct
(56) |
Nov
(105) |
Dec
(88) |
| 2006 |
Jan
(56) |
Feb
(93) |
Mar
(30) |
Apr
(46) |
May
(46) |
Jun
(16) |
Jul
(33) |
Aug
(54) |
Sep
(47) |
Oct
(21) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
|
2
(10) |
3
(4) |
4
(4) |
5
(2) |
6
|
7
|
|
8
|
9
(1) |
10
(1) |
11
(5) |
12
(1) |
13
(1) |
14
|
|
15
|
16
(1) |
17
|
18
|
19
(8) |
20
(2) |
21
|
|
22
(3) |
23
(5) |
24
(5) |
25
(3) |
26
(1) |
27
|
28
|
|
29
(1) |
|
|
|
|
|
|
|
From: Mike R. <mik...@th...> - 2004-02-29 14:46:34
|
Hi all, The build server on CCNetLive is currently down, and I've lost administrative access to it. I've contacted the sys admins in charge of that machine to let them know there's a problem - hopefully this will be resolved tomorrow (Monday). In the mean time, if anyone does need latest changes you can get them from CVS and compile yourself, or I can put a temporary build somewhere. Cheers, Mike -- Mike Roberts http://mikeroberts.thoughtworks.net/ |
|
From: Chacon-Taylor, M. <Mon...@ca...> - 2004-02-26 18:51:37
|
Hi there:
There is a ugly workaround if you turn on the log4net in NAnt you get =
the result (and a lot more!)
Although I have not investigated the log4net settings in detail.
log4net: log4net assembly [log4net, Version=3D1.2.0.30714, =
Culture=3Dneutral, PublicKeyToken=3Db32731d11ce58905]. Loaded from =
[c:\programs\nant\bin\log4net.dll]. (.NET Runtime [1.1.4322.573] on =
Microsoft Windows NT 5.0.2195.0)
log4net: DefaultRepositorySelector: defaultRepositoryType =
[log4net.Repository.Hierarchy.Hierarchy]
log4net: DefaultRepositorySelector: Creating repository for assembly =
[NAnt, Version=3D0.84.1455.0, Culture=3Dneutral, PublicKeyToken=3Dnull]
log4net: DefaultRepositorySelector: Assembly [NAnt, =
Version=3D0.84.1455.0, Culture=3Dneutral, PublicKeyToken=3Dnull] Loaded =
From [C:\programs\nant\bin\NAnt.exe]
log4net: DefaultRepositorySelector: Assembly [NAnt, =
Version=3D0.84.1455.0, Culture=3Dneutral, PublicKeyToken=3Dnull] does =
not have a DomainAttribute specified.
log4net: DefaultRepositorySelector: Assembly [NAnt, =
Version=3D0.84.1455.0, Culture=3Dneutral, PublicKeyToken=3Dnull] using =
domain [log4net-default-domain] and repository type =
[log4net.Repository.Hierarchy.Hierarchy]
log4net: DefaultRepositorySelector: Creating repository for domain =
[log4net-default-domain] using type =
[log4net.Repository.Hierarchy.Hierarchy]
log4net: DOMConfigurator: configuring repository =
[log4net-default-domain] using file =
[C:\programs\nant\bin\NAnt.exe.config] watching for file updates
log4net: DOMConfigurator: configuring repository =
[log4net-default-domain] using file =
[C:\programs\nant\bin\NAnt.exe.config]
log4net: DOMConfigurator: configuring repository =
[log4net-default-domain] using stream
log4net: DOMConfigurator: loading XML configuration
log4net: DOMConfigurator: Configuring Repository =
[log4net-default-domain]
log4net: DOMConfigurator: Configuration update mode [Merge].
log4net: DOMConfigurator: Logger [root] Level string is [ERROR].
log4net: DOMConfigurator: Logger [root] level set to =
[name=3D"ERROR",value=3D70000].
log4net: DOMConfigurator: Loading Appender [ConsoleAppender] type: =
[log4net.Appender.ConsoleAppender]
log4net: DOMConfigurator: Setting Property [ConversionPattern] to String =
value [[%c{2}:%m - [%x] <%X{auth}>]%n]
log4net: DOMConfigurator: Setting Property [Layout] to object =
[log4net.Layout.PatternLayout]
log4net: DOMConfigurator: Created Appender [ConsoleAppender]
log4net: DOMConfigurator: Adding appender named [ConsoleAppender] to =
logger [root].
log4net: DOMConfigurator: Hierarchy Threshold [ALL]
log4net: DefaultRepositorySelector: Creating repository for assembly =
[NAnt.Core, Version=3D0.84.1455.0, Culture=3Dneutral, =
PublicKeyToken=3Dnull]
log4net: DefaultRepositorySelector: Assembly [NAnt.Core, =
Version=3D0.84.1455.0, Culture=3Dneutral, PublicKeyToken=3Dnull] Loaded =
From [c:\programs\nant\bin\nant.core.dll]
log4net: DefaultRepositorySelector: Assembly [NAnt.Core, =
Version=3D0.84.1455.0, Culture=3Dneutral, PublicKeyToken=3Dnull] does =
not have a DomainAttribute specified.
log4net: DefaultRepositorySelector: Assembly [NAnt.Core, =
Version=3D0.84.1455.0, Culture=3Dneutral, PublicKeyToken=3Dnull] using =
domain [log4net-default-domain] and repository type =
[log4net.Repository.Hierarchy.Hierarchy]
log4net: DefaultRepositorySelector: domain [log4net-default-domain] =
already exisits, using repository type =
[log4net.Repository.Hierarchy.Hierarchy]
NAnt 0.84 (Build 0.84.1455.0; net-1.0.win32; release; 12/26/2003)
Copyright (C) 2001-2003 Gerry Shaw
http://nant.sourceforge.net
<buildresults project=3D"example">
<message level=3D"Info"><![CDATA[Buildfile: =
file:///D:/build/scripts/test.build]]></message>
<message level=3D"Info"><![CDATA[Target(s) specified: =
makeexception]]></message>
<target name=3D"makeexception">
<task name=3D"script"[Core.Task:script Generated Exception - [] <>]
Exception: NAnt.Core.BuildException
Message: D:\build\scripts\test.build(4,18):
Compilation failed:
d:\temp\yuzix4jp.0.cs(14,61) : error CS1010: Newline in constant
d:\temp\yuzix4jp.0.cs(15,23) : error CS1010: Newline in constant
Source: NAnt.Win32Tasks
at NAnt.Core.Tasks.ScriptTask.ExecuteTask() in =
c:\programs\nant\src\NAnt.Win32\Tasks\ScriptTask.cs:line 263
at NAnt.Core.Task.Execute() in =
c:\programs\nant\src\NAnt.Core\Task.cs:line 143
/>
</target>[Core.Project:Build failed. - [] <>]
Exception: NAnt.Core.BuildException
Message: D:\build\scripts\test.build(4,18):
Compilation failed:
d:\temp\yuzix4jp.0.cs(14,61) : error CS1010: Newline in constant
d:\temp\yuzix4jp.0.cs(15,23) : error CS1010: Newline in constant
Source: NAnt.Win32Tasks
at NAnt.Core.Tasks.ScriptTask.ExecuteTask() in =
c:\programs\nant\src\NAnt.Win32\Tasks\ScriptTask.cs:line 263
at NAnt.Core.Task.Execute() in =
c:\programs\nant\src\NAnt.Core\Task.cs:line 151
at NAnt.Core.Target.Execute() in =
c:\programs\nant\src\NAnt.Core\Target.cs:line 217
at NAnt.Core.Project.Execute(String targetName, Boolean =
forceDependencies) in c:\programs\nant\src\NAnt.Core\Project.cs:line 772
at NAnt.Core.Project.Execute() in =
c:\programs\nant\src\NAnt.Core\Project.cs:line 734
at NAnt.Core.Project.Run() in =
c:\programs\nant\src\NAnt.Core\Project.cs:line 797
</buildresults>
-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...]On Behalf Of Mike Roberts
Sent: Wednesday, February 25, 2004 1:23 PM
To: ccn...@li...; ccn...@li...
Subject: [Ccnet-user] More on the 'when NAnt exceptions we don't get the
output' problem
Hi everyone,
Most of you probably know the problem where if a build fails nastily we=20
often don't see the output in CCNet's build (assuming we use Nant=20
xmllogger, which is CCNet's default behaviour). I've always presumed=20
this was because it was going to standard error, and we weren't=20
capturing it properly.
Unfortunately, I've produced a small example to show this is not the=20
case (example build at the end of this email) - if you use NAnt's=20
xmllogger it really does lose output and there's *no workaround* we can=20
perform in CCNet. I've emailed the NAnt project to see if they can work=20
on a fix. In the mean time if anyone fancies looking at NAnt's source=20
and figuring out what the problem is I'm sure they'd appreciate it.
I'll let you know the outcome of this should something concrete come=20
from the NAnt list.
Cheers,
Mike
--
<project name=3D"example" default=3D"makeexception">
<target name=3D"makeexception">
<script language=3D"C#">
<code><![CDATA[
public static void ScriptMain(Project=20
project)
{
throw new Exception("Making=20
target throw exception");
}
]]></code>
</script>
</target>
</project>
(Try running this from the command line, both with and without using=20
xmllogger - you'll see that the message is not printed in the latter =
case)
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Ccnet-user mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-user
|
|
From: Mike M. <mg...@th...> - 2004-02-25 23:34:39
|
Mike Roberts wrote: > Hi folks, > > Small coding standard issue - on my project we set compile warnings to > actually be errors (so failing the build). I was dubious at first but > there's been examples (like unused variables) that convince me its a > good idea. Any objections for us doing it on CCNet? I know there are > currently wanrings that would have to be fixed, but I'd happy to go > through these if we went forward. +1, you know it makes sense. Now if only I could get people to agree that saving a Java file with anything other than an IntelliJ "green blob" was a shootable offense... ;-) Laters, Mike. |
|
From: Michael C T. <MC...@th...> - 2004-02-25 21:53:43
|
This started happening when NAnt rolled out log4net. They bypassed their
own internal logging mechanism for the log4net one in some cases so the
XmlLogger won't catch it.
ThoughtWorks, where being meta-cognitive is something worth thinking
about.
Mike Roberts <mik...@th...>
Sent by: ccn...@li...
02/25/2004 03:23 PM
To: ccn...@li..., "'ccn...@li...'"
<ccn...@li...>
cc:
Subject: [Ccnet-devel] More on the 'when NAnt exceptions we don't get the output'
problem
Hi everyone,
Most of you probably know the problem where if a build fails nastily we
often don't see the output in CCNet's build (assuming we use Nant
xmllogger, which is CCNet's default behaviour). I've always presumed
this was because it was going to standard error, and we weren't
capturing it properly.
Unfortunately, I've produced a small example to show this is not the
case (example build at the end of this email) - if you use NAnt's
xmllogger it really does lose output and there's *no workaround* we can
perform in CCNet. I've emailed the NAnt project to see if they can work
on a fix. In the mean time if anyone fancies looking at NAnt's source
and figuring out what the problem is I'm sure they'd appreciate it.
I'll let you know the outcome of this should something concrete come
from the NAnt list.
Cheers,
Mike
--
<project name="example" default="makeexception">
<target name="makeexception">
<script language="C#">
<code><![CDATA[
public static void ScriptMain(Project
project)
{
throw new Exception("Making
target throw exception");
}
]]></code>
</script>
</target>
</project>
(Try running this from the command line, both with and without using
xmllogger - you'll see that the message is not printed in the latter case)
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
|
|
From: Mike R. <mik...@th...> - 2004-02-25 21:32:28
|
Hi everyone,
Most of you probably know the problem where if a build fails nastily we
often don't see the output in CCNet's build (assuming we use Nant
xmllogger, which is CCNet's default behaviour). I've always presumed
this was because it was going to standard error, and we weren't
capturing it properly.
Unfortunately, I've produced a small example to show this is not the
case (example build at the end of this email) - if you use NAnt's
xmllogger it really does lose output and there's *no workaround* we can
perform in CCNet. I've emailed the NAnt project to see if they can work
on a fix. In the mean time if anyone fancies looking at NAnt's source
and figuring out what the problem is I'm sure they'd appreciate it.
I'll let you know the outcome of this should something concrete come
from the NAnt list.
Cheers,
Mike
--
<project name="example" default="makeexception">
<target name="makeexception">
<script language="C#">
<code><![CDATA[
public static void ScriptMain(Project
project)
{
throw new Exception("Making
target throw exception");
}
]]></code>
</script>
</target>
</project>
(Try running this from the command line, both with and without using
xmllogger - you'll see that the message is not printed in the latter case)
|
|
From: Mike R. <mik...@th...> - 2004-02-24 23:33:56
|
Done - its in the latest build. I actually set the start date to Jan 1 1980 just to make sure. :) Mike Mike Roberts wrote: > Yup, we can do that - I'll work on it today and get back to you. > > Mike > > Jan Sandquist wrote: > >> Thanks Mike! >> >> A minor glitch (in build 111) is that for the very first integration >> step 'IntegrationResult.StartTime' is still 1/1/1 which is >> not accepted by SVN: >> > ccnet >> [CruiseControl Server:Info]: Starting CruiseControl.NET Server >> [MUMS:Error]: Exception: Error: >> \jansa\tools-build\Svn\subversion\subversion\clients\cmdline\main.c:746: >> (apr_err=205000) >> svn: Syntax error in revision argument >> '{0001-01-01T00:00:00Z}:{2004-02-23T23:13:21Z}' >> > >> >> It might be a bit misleading at first, but upon the next >> build/integration this is no longer an issue. >> Should we care to initiate it to 1970-01-01 to avoid this? >> >> Best Regards, >> >> Jan >> >> > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Ccnet-devel mailing list > Ccn...@li... > https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: Mike M. <mg...@th...> - 2004-02-24 16:29:02
|
Jan Sandquist wrote: >Thanks Mike! > >A minor glitch (in build 111) is that for the very first integration step 'IntegrationResult.StartTime' is still 1/1/1 which is >not accepted by SVN: > > ccnet > [CruiseControl Server:Info]: Starting CruiseControl.NET Server > [MUMS:Error]: Exception: Error: \jansa\tools-build\Svn\subversion\subversion\clients\cmdline\main.c:746: (apr_err=205000) > svn: Syntax error in revision argument '{0001-01-01T00:00:00Z}:{2004-02-23T23:13:21Z}' > > > >It might be a bit misleading at first, but upon the next build/integration this is no longer an issue. >Should we care to initiate it to 1970-01-01 to avoid this? > > Blegh. I didn't realise CCNet was setting the first build time to 1st January 0001 -- I'm suprised any of the revision control systems are accepting it! (unless they're getting 1/1/1 and parsing that as 1st January 2001...). I think Mike (Roberts) is on this one. Cheers, Mike. |
|
From: Mike R. <mik...@th...> - 2004-02-24 12:34:20
|
Yup, we can do that - I'll work on it today and get back to you. Mike Jan Sandquist wrote: >Thanks Mike! > >A minor glitch (in build 111) is that for the very first integration step 'IntegrationResult.StartTime' is still 1/1/1 which is >not accepted by SVN: > > ccnet > [CruiseControl Server:Info]: Starting CruiseControl.NET Server > [MUMS:Error]: Exception: Error: \jansa\tools-build\Svn\subversion\subversion\clients\cmdline\main.c:746: (apr_err=205000) > svn: Syntax error in revision argument '{0001-01-01T00:00:00Z}:{2004-02-23T23:13:21Z}' > > > >It might be a bit misleading at first, but upon the next build/integration this is no longer an issue. >Should we care to initiate it to 1970-01-01 to avoid this? > >Best Regards, > >Jan > > |
|
From: Owen R. <OR...@th...> - 2004-02-24 08:52:14
|
no objection from my part. looking at the warnings at this point, we have some warnings about using an obsolete api for xsl transforms. fixing this using the 1.1 api breaks backwards compatibility with .net 1.0. is there a way that we can fix this while maintaining backwards compatilibity? there are also some warnings in the controlpanel about unused variables. this we should fix. cheers, o. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. Mike Roberts <mike.roberts@thoughtworks.n To: ccn...@li... et> cc: Sent by: Subject: [Ccnet-devel] warnings as errors? ccn...@li... ceforge.net 23/02/2004 22:05 Hi folks, Small coding standard issue - on my project we set compile warnings to actually be errors (so failing the build). I was dubious at first but there's been examples (like unused variables) that convince me its a good idea. Any objections for us doing it on CCNet? I know there are currently wanrings that would have to be fixed, but I'd happy to go through these if we went forward. Cheers, Mike ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: Jan S. <J.S...@te...> - 2004-02-24 01:41:46
|
Thanks Mike! A minor glitch (in build 111) is that for the very first integration step 'IntegrationResult.StartTime' is still 1/1/1 which is not accepted by SVN: > ccnet [CruiseControl Server:Info]: Starting CruiseControl.NET Server [MUMS:Error]: Exception: Error: \jansa\tools-build\Svn\subversion\subversion\clients\cmdline\main.c:746: (apr_err=205000) svn: Syntax error in revision argument '{0001-01-01T00:00:00Z}:{2004-02-23T23:13:21Z}' > It might be a bit misleading at first, but upon the next build/integration this is no longer an issue. Should we care to initiate it to 1970-01-01 to avoid this? Best Regards, Jan ----- Original Message ----- From: "Mike Mason" <mg...@th...> To: "Jan Sandquist" <J.S...@te...> Cc: <us...@su...>; <ccn...@li...> Sent: Sunday, February 22, 2004 7:16 PM Subject: Re: SVN & CC.NET - Windows date parser & issue #408 > Jan Sandquist wrote: > > > Also sorry if this is (really) old news. I've searched through the > > mail archives but only > > > > found issue #408 "date parser rewrite", and a single email from Mike > > Mason related to > > > > SVN integration in CC.NET. An "old" date parser is currently used on > > Windows if I > > > > got it right. I think this is addressed by the patch in #408, right? > > > > > > > Hi Jan, > > My apologies for not getting back to you sooner, but I've been on > vacation. You're right -- the Subversion date parser changed a little > while ago and doesn't support the format CC.Net is feeding it (weird > though, I thought it was a reasonable format I'm using...). > > Anyhoo, I've updated the CruiseControl.NET code to pump proper > timestamps into Subversion, and checked in. The next CCNetLive build > should contain the fix, you can see the build status and download builds > from http://ccnetlive.thoughtworks.com/ccnet/ > > Cheers, > Mike. |
|
From: Farhatullah, F. <far...@ve...> - 2004-02-23 17:12:11
|
How to install CCTray Remote Monitoring of CruiseControl.NET ? =20 Thanks=20 Farhan Farhatullah=20 * 972-507-4495=20 * Far...@Ve...=20 Pager: 800-781-7457 Pin: 1368192=20 =20 |
|
From: Mike R. <mik...@th...> - 2004-02-23 16:43:58
|
Hi folks, Small coding standard issue - on my project we set compile warnings to actually be errors (so failing the build). I was dubious at first but there's been examples (like unused variables) that convince me its a good idea. Any objections for us doing it on CCNet? I know there are currently wanrings that would have to be fixed, but I'd happy to go through these if we went forward. Cheers, Mike |
|
From: Mike R. <mik...@th...> - 2004-02-23 13:12:06
|
Dev folks, This came up on the user list. I think a really nice way of implementing this would be to write a 'ModificationFilter' class that implements 'ISourceControl', but decorates an underlying 'real' source control, just like the 'MultiSourceControl' class does. It would delegate to the underlying ISourceControl to get the full list of modifications, and then run filters against the each modification's path. To start with, it could just do simple single file excludes. I'm thinking it may need a way of specifying what the base directory is for some source controls (CVS wouldn't need this, but Perforce would since it returns full depot paths for modification paths.) Anyone fancy looking at this? Its a nice self-contained piece and would be fairly easy for newbies to the project to work on. Cheers, Mike Mike Roberts wrote: > Hi Nicke, > > First up, I think it would be useful, and it would be interesting to > consider whether this should be sourcecontrol-type independent or not. > I think it could be done independently, but it would need some work. > If you're interested in helping out, we can carry on this discussion > on the dev email list, otherwise I'll add it to the feature list. > > Thanks, > > Mike > > Nicklas Norling wrote: > >> Hi! >> >> I'd like to be so bold as to suggest a feature that I've been >> thinking of for awhile. >> >> We have a pretty large project with loads of files in CVS. >> We build with CCNet for .NET but with CC + Ant for Java. The >> code resides in the same cvs module so any java check in will >> trigger a client build and vice versa. The build put strain >> on the machines and takes some time. We've had to reduce the >> integration time to 1 hour because of it. >> >> I'd like to suggest that one can set the path(s) for which >> a new build should be triggered. Maybe even specify file types. >> E.g. if files in ...\sharpcode\* has changed, build, otherwise >> skip the changes. Or, if *.cs;*.csproj files changes trigger >> a build, otherwise not. Maybe even combination of excludes/includes >> of files/folders. >> >> Anyone else feel that this would be useful? >> >> /Nicke >> >> >> ------------------------------------------------------- >> SF.Net is sponsored by: Speed Start Your Linux Apps Now. >> Build and deploy apps & Web services for Linux with >> a free DVD software kit from IBM. Click Now! >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >> _______________________________________________ >> Ccnet-user mailing list >> Ccn...@li... >> https://lists.sourceforge.net/lists/listinfo/ccnet-user >> >> > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Ccnet-user mailing list > Ccn...@li... > https://lists.sourceforge.net/lists/listinfo/ccnet-user |
|
From: Owen R. <OR...@th...> - 2004-02-23 06:22:45
|
ok, it's official: i've finally upgraded to vs.net 2003. the lure of ReSharper (http://www.jetbrains.net/resharper) proved too much for me. plus i was sick of hand-editing the 2003 sln and proj files just so mike could use the <solution> tag with our build. (bah!) so, i'm removing the 2002 sln and proj files. hopefully no one objects. if you do, you can always downgrade (http://www.codeproject.com/macro/vsconvert.asp?target=convert%7C2003). cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. |
|
From: Owen R. <OR...@th...> - 2004-02-23 06:15:44
|
i've been going through the source and changing the way that ccnet uses external processes (processes are used throughout the application, for every task that needs to be able to invoke executables through the command-line). ccnet was facing several issues with using external processes: - because of the deadlock issue with the .net Process class, we weren't reading the results of standard error stream from the process. as a result, it was often hard to debug configuration issues with ccnet. - we also had some issues where the process was not timing out properly. hence an inadvertent dialog box, or a non-terminating process could crash the server. - also, it was very hard to test classes that needed to shell out to a process as they depended on having an appropriate file to execute on the command-line. this was especially a problem for the sourcecontrol classes as executing the appropriate process required having that source control system installed on your machine. with the new set of process classes, the interaction with external processes has now been centralised into a handful of well-tested utility classes. i have been able to delete a mass of duplicated code from the other classes using processes as a result. there is still some refactoring required as the existing classes are now more lightweight (ie. do we really need the ProcessSourceControl class and the template method pattern that it is using?). i still have to go through and insert mocks into the sourcecontrol classes so that they are no longer dependent on invoking the command-line. anyone want to help with this? cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. |
|
From: Mike R. <mik...@th...> - 2004-02-22 21:42:36
|
Owen Rogers wrote: >hi adrian, >thanks for submitting your modifications. i'm going to defer to mike on >this one as he done all the work on the dashboard. he should be back from >holiday next week. >i think that providing the capability from the web app to force builds is >useful functionality. however, i would suggest that we should implement it >as a web app plug-in. that way we could easily exclude it from web apps >where security is potentially an issue (like our public ccnet server on >ccnetlive). >cheers, >owen. > Adrian - Thanks for the inspiration. I've added something slightly different but along the same lines. It is actually in the dashboard now since that is already configured to talk a remoted Cruise Server, but in the future the dashboard and main web app are hopefully going to be collapsed into one client. Check it out in Build 108 - http://ccnetlive.thoughtworks.com/CCNet-builds/108/ Mike |
|
From: Mike M. <mg...@th...> - 2004-02-22 18:51:53
|
Mike Mason wrote: > Anyhoo, I've updated the CruiseControl.NET code to pump proper > timestamps into Subversion, and checked in. The next CCNetLive build > should contain the fix, you can see the build status and download > builds from http://ccnetlive.thoughtworks.com/ccnet/ Sorry I got the wrong URL. You actually want http://ccnetlive.thoughtworks.com/CCNet-builds/ Cheers, Mike. |
|
From: Mike M. <mg...@th...> - 2004-02-22 18:24:14
|
Jan Sandquist wrote: > Also sorry if this is (really) old news. I've searched through the > mail archives but only > > found issue #408 "date parser rewrite", and a single email from Mike > Mason related to > > SVN integration in CC.NET. An "old" date parser is currently used on > Windows if I > > got it right. I think this is addressed by the patch in #408, right? > > > Hi Jan, My apologies for not getting back to you sooner, but I've been on vacation. You're right -- the Subversion date parser changed a little while ago and doesn't support the format CC.Net is feeding it (weird though, I thought it was a reasonable format I'm using...). Anyhoo, I've updated the CruiseControl.NET code to pump proper timestamps into Subversion, and checked in. The next CCNetLive build should contain the fix, you can see the build status and download builds from http://ccnetlive.thoughtworks.com/ccnet/ Cheers, Mike. |
|
From: Jan S. <J.S...@te...> - 2004-02-20 17:50:11
|
> hi jan, > i don't believe that this has been patched yet (though mike is on holiday > so i don't know for sure). it would be great if you could submit your > patch to the list so that we can apply it. > what about the subversion patch that you were referring to? has that > already been fixed? It works fine in my environment, but I intend to test some alternative solutions before submitting it. I didn't get any response from the SVN list, so I'm still pussled about the date parser differences on Linux vs Windows. Some of the acceptable date formats shown in the SVN book (http://www.svnbook.org/book.html#svn-ch-3-sect-3.3) don't apply to my Windows environment at least. To sum up the problem I've patched: 1) The current mindate (1/1/1) set by CC.NET is not accepted by SVN, but this is only a problem for the first integration step. 2) 'GMT' is not accepted by SVN in my environment, so I'm temporarily using local time instead. The alternative is to use the SVN revision numbers, as they are sequentially updated for each atomic commit. BTW, anyone on this list - except Mike - using Subversion(SVN)? I hope to be back with a patch before the next release of CC.NET... Cheers, Jan PS. SVN version 1.0 is due for release on Monday, 23 Feb 2004 so we might be better off testing with that one while we're at it. > This is what I see on Windows XP: > D:\jansa\MUMS\product\trunk\src>svn log -r {"2004-01-20 01:12:15 > GMT"} > svn: Syntax error in revision argument '{2004-01-20 01:12:15 GMT}' > D:\jansa\MUMS\product\trunk\src>svn log -r {"2004-01-20 01:12:15"} > ------------------------------------------------------------------------ > D:\jansa\MUMS\product\trunk\src>svn log -r {"2004-02-01 01:12:15"} > ------------------------------------------------------------------------ > > r34 | Jan | 2004-01-30 16:03:04 +0100 (Fri, 30 Jan 2004) | 1 line > ------------------------------------------------------------------------ > D:\jansa\MUMS\product\trunk\src> > > A related one might be: > D:\jansa\MUMS\product\trunk\src>svn log -r {"0001-01-01 > 00:00:00"}:{"2004-02-12 00:00:00"} > svn: Syntax error in revision argument '{0001-01-01 > 00:00:00}:{2004-02-12 00:00:00}' > D:\jansa\MUMS\product\trunk\src> > > with or without the 'GMT'. This is apparently the MinDate in .NET, and used > by CC.NET. What is the minimum date supported by SVN? > Does the locale settings matter? > > I've currently patched CC.NET so it works fine with Subversion so just > curious about issue #408 before I submit a possible patch to CC.NET, or not... |
|
From: Shen T. <ST...@th...> - 2004-02-20 03:26:38
|
Interesting! Been looking at the web project building problem and missed
that one completely. Thanks Jan.
- shen -
Owen Rogers <OR...@th...>
Sent by: ccn...@li...
19/02/2004 07:48 PM
To: J.S...@te...
cc: ccn...@li..., Shen Tham <ST...@th...>
Subject: Re: [Ccnet-devel] [PATCH] web.csproj in build 98
ah ha! so that's why it wasn't properly building the web project! i had
been wondering about that! as i'm the only vs.net 2002 user, i wasn't too
sure what the problem was. that's a big help.
what about the subversion patch that you were referring to? has that
already been fixed?
cheers,
owen.
---
R. Owen Rogers
ThoughtWorks Technologies (India) Pvt Ltd.
ThoughtWorks - Deliver with passion!
ThoughtWorks is always looking for talented people who are passionate
about
technology. To find out more about a career at ThoughtWorks go to
http://www.thoughtworks.com/career/.
|---------+--------------------------------------->
| | "Jan Sandquist" |
| | <J.S...@te...> |
| | Sent by: |
| | ccn...@li...|
| | ceforge.net |
| | |
| | |
| | 19/02/2004 03:32 |
|---------+--------------------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: <ccn...@li...> |
| cc: |
| Subject: [Ccnet-devel] [PATCH] web.csproj in build 98
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Not much in here, except that the post build event for web.csproj need to
be changed from
copy "$(ProjectDir)test\test.config" "$(TargetPath)"
to
copy "$(ProjectDir)test\test.config" "$(TargetDir)"
Otherwise, the web page cannot be displayed.
It's been there for a couple of revisions, so I thought a little hint
could
be appropriate. ;-)
Many thanks for your work on CruiseControl.NET!
-- Jan
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
|
|
From: Owen R. <OR...@th...> - 2004-02-19 10:10:19
|
hi loren, as mike pointed out, this is a bug in either the NAnt XmlLogger class or (more likely) somewhere in NAnt is not properly logging its exceptions. i am a committer on the NAnt project, but unfortunately i don't have the bandwidth to look into what the problem is right now (i'm spending enough time just trying to keep up-to-date with the ccnet lists). if someone was to look into the NAnt source to produce a patch, i'd be happy to commit it. however, the only caveat is that you would need to use the patched version of nant until they made a new release. wrt to what mike said, i don't think that changing the NAntBuilder is sufficient. we need NAnt to output Xml so that we can properly render the build results in the ccnet web app. so changing the code in ccnet, is not sufficient IMO. cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. |---------+---------------------------------------> | | Mike Roberts | | | <mike.roberts@thoughtworks.n| | | et> | | | Sent by: | | | ccn...@li...| | | ceforge.net | | | | | | | | | 05/02/2004 20:58 | |---------+---------------------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Loren Halvorson <lor...@ho...> | | cc: ccn...@li... | | Subject: Re: [Ccnet-devel] NAnt.Core.XmlLogger loses failure information | >--------------------------------------------------------------------------------------------------------------------------------------------------| Hi Loren, This is a known problem. You're right in that really its a bug in NAnt, but one we should considering workign around in CCNet. I thought they'd fixed NAnt for this, but it looks like you're using 0.8.4 final. We might be able to work around this by capturing all standard out and including it in the log output, but it would require a code change in the NAntBuilder class. Mike Loren Halvorson wrote: >This is probably an issue for the NAnt team, but since CruiseControl.NET >makes such heavy use of the XmlLogger, I figure someone on this list must >have seen this issue and may know a work-around. > >The XmlLogger doesn't report the failure information, so it's tough to >diagnose why a build isn't failing. To illustrate: > >Given this simple build file > ><project name="test" default="test"> > <target name="test"> > <copy file="NoDir\SomeFileThatDoesntExist.txt" todir="."/> > </target> ></project> > >When I run it from command line I get this output: > > >nant -f:test.build > NAnt 0.84 (Build 0.84.1455.0; net-1.0.win32; release; 12/26/2003) > Copyright (C) 2001-2003 Gerry Shaw > http://nant.sourceforge.net > Buildfile: file:///C:/Temp/New Folder/test.build > Target(s) specified: test > test: > BUILD FAILED > Could not find file C:\Temp\New Folder\NoDir\SomeFileThatDoesntExist.txt to >copy. > Total time: 0.1 seconds. > >But when I run it using the XmlLogger it completely loses the failure reason > > >nant -f:test.build -logger:NAnt.Core.XmlLogger > NAnt 0.84 (Build 0.84.1455.0; net-1.0.win32; release; 12/26/2003) > Copyright (C) 2001-2003 Gerry Shaw > http://nant.sourceforge.net > > <buildresults project="test"> > <message level="Info"><![CDATA[Buildfile: file:///C:/Temp/New >Folder/test.build]]></message> > <message level="Info"><![CDATA[Target(s) specified: test]]></message> > <target name="test"> > <task name="copy" /> > </target> > </buildresults> > >As a result, the log files that CruiseControl.NET shows me in the web are of >limited use to diagnose why a build is failing, as I still need to re-run >the build using the console to see the real failure. > >Thanks, >--Loren > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Ccnet-devel mailing list >Ccn...@li... >https://lists.sourceforge.net/lists/listinfo/ccnet-devel > > ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: Owen R. <OR...@th...> - 2004-02-19 09:21:53
|
hi loren, i have applied the patch to the compile.xsl. thanks for fixing that. with regards to the log.xsl stylesheet. i completely agree that it would be better to transform the log file rather than just output the xml. putting together such a stylesheet and build plug-in is something that i've been meaning to do for a while. anyone want to take a stab at doing this? -- i think that the idea is to render the log file in a format similar to how it looks when you run nant from the console. cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. |---------+---------------------------------------> | | "Halvorson, Loren" | | | <Lor...@gm...| | | > | | | Sent by: | | | ccn...@li...| | | ceforge.net | | | | | | | | | 12/02/2004 20:20 | |---------+---------------------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: ccn...@li... | | cc: | | Subject: [Ccnet-devel] Modified compile.xsl to prevent false report of errors | >--------------------------------------------------------------------------------------------------------------------------------------------------| We <exec> devenv and msdev to do some of our Visual Studio compiling. We were getting error entries on CCNET's web summary page for output that looked like: (excerpt from one of the XMLLogger logs:) : <message level="Info"><![CDATA[MyComponent.dll - 0 error(s), 0 warning(s)]]></message> : One of our developers modified the web site's compile.xsl to exclude these messages. Here it is, we were hoping to get this change (or something like it) incorporated in to the project. <<compile.xsl>> I've also attached an XSL we use to view the log in a prettier format (by the way, the plugin concept in the web app is very cool, made plugging this in a snap) Maybe a link could be added to the web app to view the log formatted with something like this instead of needing to download the raw XML to see the details. <<log.xsl>> By the way, we're really looking forward to the fix that will capture the build failure information. Thanks. --Loren |
|
From: Owen R. <OR...@th...> - 2004-02-19 08:54:10
|
ah ha! so that's why it wasn't properly building the web project! i had been wondering about that! as i'm the only vs.net 2002 user, i wasn't too sure what the problem was. that's a big help. what about the subversion patch that you were referring to? has that already been fixed? cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. |---------+---------------------------------------> | | "Jan Sandquist" | | | <J.S...@te...> | | | Sent by: | | | ccn...@li...| | | ceforge.net | | | | | | | | | 19/02/2004 03:32 | |---------+---------------------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: <ccn...@li...> | | cc: | | Subject: [Ccnet-devel] [PATCH] web.csproj in build 98 | >--------------------------------------------------------------------------------------------------------------------------------------------------| Not much in here, except that the post build event for web.csproj need to be changed from copy "$(ProjectDir)test\test.config" "$(TargetPath)" to copy "$(ProjectDir)test\test.config" "$(TargetDir)" Otherwise, the web page cannot be displayed. It's been there for a couple of revisions, so I thought a little hint could be appropriate. ;-) Many thanks for your work on CruiseControl.NET! -- Jan |
|
From: Jan S. <J.S...@te...> - 2004-02-19 08:30:19
|
Not much in here, except that the post build event for web.csproj need to be changed from copy "$(ProjectDir)test\test.config" "$(TargetPath)" to copy "$(ProjectDir)test\test.config" "$(TargetDir)" Otherwise, the web page cannot be displayed. It's been there for a couple of revisions, so I thought a little hint could be appropriate. ;-) Many thanks for your work on CruiseControl.NET! -- Jan |
|
From: Owen R. <OR...@th...> - 2004-02-19 07:05:06
|
oh, i should add that the ccnet.service.exe.config also now includes the <NAnt.Logger> element. i guess we better make another release soon to keep people from rediscovering this problem. cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. |---------+---------------------------------------> | | Jonathan Gray | | | <Jonathan.Gray@netdecisions.| | | com> | | | Sent by: | | | ccn...@li...| | | ceforge.net | | | | | | | | | 11/02/2004 21:38 | |---------+---------------------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Owen Rogers <OR...@th...>, Mat...@sr... | | cc: "'ccn...@li...'" <ccn...@li...>, ccn...@li... | | Subject: [Ccnet-devel] RE: [Ccnet-user] Fixed service email prob | >--------------------------------------------------------------------------------------------------------------------------------------------------| <build date="11/02/2004 15:54:22" buildtime="00:00:02" error="true">NAnt 0.84 (Build 0.84.1455.0; net-1.0.win32; release; 26/12/2003) Copyright (C) 2001-2003 Gerry Shaw http://nant.sourceforge.net Invalid value '' for command-line argument '-logger'. Try 'nant -help' for more information</build> On a related note, I had been getting the error detailed above in the XML build log once I had installed ccnet.service.exe meaning that the builds kept on failing. Inspired by copying stuff from ccnet.exe.config to ccnet.service.exe.config (nice one Matt!), I copied the Nant.Logger <appsetting> from ccnet.exe.config to the ccnet.service.exe.config and, hey presto, the build now works. My ccnet.service.exe.config appSettings element now looks like this: <appSettings> <add key="ccnet.config" value="c:\ccnet-0.4.2\server\ccnet.config"/> <add key="remoting" value="on"/> <add key="NAnt.Logger" value="NAnt.Core.XmlLogger"/> </appSettings> Perhaps the two configs could be heirachical or unified in some way to stop these errors from occurring? Jon -----Original Message----- From: Owen Rogers [mailto:OR...@th...] Sent: 11 February 2004 14:20 To: Mat...@sr... Cc: 'ccn...@li...'; ccn...@li... Subject: Re: [Ccnet-user] Fixed service email prob hi matt, thanks for diagnosing this bug. this has been plaguing quite a few ccnet users. i've updated the ccnet.service.exe.config file that is included with the distribution. out of curiosity, how did you diagnose that this was the problem? cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. 6th Floor, Tower D, Corporate Block Diamond District, Airport Road Bangalore, INDIA tel: +91 80 508 9572 mobile: +91 98451 53169 ThoughtWorks - Deliver with passion! |---------+--------------------------------------> | | "Steele, Matt" | | | <Mat...@sr...> | | | Sent by: | | | ccn...@li...| | | ceforge.net | | | | | | | | | 07/02/2004 05:47 | |---------+--------------------------------------> >--------------------------------------------------------------------------- -----------------------------------------------------------------------| | | | To: "'ccn...@li...'" <ccn...@li...> | | cc: | | Subject: [Ccnet-user] Fixed service email prob | >--------------------------------------------------------------------------- -----------------------------------------------------------------------| Ok, I think I figured this one out. The BuildLogTransformer class throws when it's trying to get the list of XSLs to apply to the email content. If you look at the ccnet.service.exe.config file, there is no list of XSLs to apply. So I just copied the list from ccnet.exe.config and it worked. The actual addition to the ccnet.service.exe.config file is <configSections> <section name="xslFiles" type="ThoughtWorks.CruiseControl.Core.Config.XslFilesSectionHandler,ccnet.co re"/> </configSections> <xslFiles> <file name="xsl\header.xsl"/> <file name="xsl\compile.xsl"/> <file name="xsl\unittests.xsl"/> <file name="xsl\fit.xsl"/> <file name="xsl\modifications.xsl"/> </xslFiles> Now it's sending email like a champ. Hope this helps and isn't redundant for anyone... ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Ccnet-user mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-user ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
1 message has been excluded from this view by a project administrator.