ccnet-devel Google Group

Messaging and communications

2009-01-04T19:43:33Z

Hello all,

Yesterday Dave identified a limitation with some of my recent changes.
Because they require new parameters to some of the interfaces, this
has a large flow-on affect to many other interfaces and classes. He
also suggested a solution, which I think would work very nicely.

However, considering this will be a major change in the way

Re: Security Branch

2009-01-04T10:25:50Z

Hi David,

I'd be interested in testing out the RC of the security branch when it
is available.

Cheers,

John

Re: [ccnet-devel] Re: SF.net SVN: ccnet:[4523] branches/security/project

2009-01-04T06:50:11Z

Considering how many files it touches, at least right now, I'd like to
save it for 1.5 so it can get more testing. I know "files touched" is
a very crude measure, but it's also one that is immediately obvious.
Dave Cameron
CruiseControl.NET - [link]
On Sun, Jan 4, 2009 at 5:39 PM, Craig & Sammi Sutherland

RE: [ccnet-devel] Re: SF.net SVN: ccnet:[4523] branches/security/project

2009-01-04T06:39:46Z

Hi Dave,
Thanks for the feedback. Your idea of a build-request object is brilliant!
It would definitely simple things moving forward in the long-term and allow
us to simplify the interfaces (it's the sort of idea I was I had thought
of!)
As a side-note, I have added this to the security branch, rather than the

Re: SF.net SVN: ccnet:[4523] branches/security/project

2009-01-04T06:31:26Z

Nice work Craig.
The number of fiels that needs to change is a black mark against the
CCNet design. I think there is an opportunity to wrap up some sort of
build-request object and pass that around, rather than having to
change method signatures through so many interfaces?
This is more of a long term change, and doesn't need to affect this

Re: [ccnet-devel] Security Branch

2009-01-03T04:40:25Z

Hi
There are enough changes on trunk for another release. I think we
should make a 1.4.3 release in January.
The security branch changes would make for a 1.5 release sometime
after January. John do you have the time and interest to try the
security changes when a release candidate is available?
Dave Cameron

Re: [ccnet-devel] Security Branch

2009-01-02T17:52:00Z

Hi
I'm testing it also, and am working together with Craig to iron out some
small issues,
(documentation for instance). An exact timeline is not known yet :-(
but I expect the merge to appear the next weeks, when the holidays are over
;-)
with kind regards
Ruben Willems

Security Branch

2009-01-02T11:31:22Z

Hi All,

Is there a timeline for merging the security branch into the main
branch?

Thanks,

John

Re: [ccnet-devel] Re: issue 748 : Provide better trigger exception logging

2009-01-02T09:22:40Z

Hi
let me know if the latest patch works,
I'm now working on making it configurable, and have some idea on the posible
options.
Hopefully this is ready during the weekend.
Keeping you posted ...
with kind regards
Ruben Willems

Re: issue 748 : Provide better trigger exception logging

2009-01-02T07:33:16Z

You're absolutely right. This occurred to me and when I returned here
to post again I found your response. :)

-Steve

Re: [ccnet-devel] Re: issue 748 : Provide better trigger exception logging

2009-01-01T20:50:46Z

Hi Steve
this fix will not work:
you will only run the publishers if a build occured,
but when an error occured at getmodifications, the publishers are not ran.
I'll try to fix this problem, it is indeed not needed to run the publishers
on every integration.
only when a build ran, or there was an error in getting the modifications.

source code available as a mercurial repository on bitbucket

2009-01-01T09:54:28Z

I've wanted an offline copy of the ccnet repository for a while. Over
the past couple days I was able to use hgsubversion[1] to create a
local repository with the full project history. This afternoon, I
uploaded it to BitBucket. If you'd like to clone a mercurial
repository for yourself, you can do it from bitbucket at

Re: issue 748 : Provide better trigger exception logging

2008-12-31T21:48:00Z

Hi Ruben,
So this patch will *always* call PostBuild() regardless of
result.ShouldRunBuild() which is a serious problem.

Here is my modification to IntegrationRunner.cs
IntegrationRunner.Integration( ...) to fix this problem. These changes
more closely mirror the previous code with respect to the result of

Re: issue 748 : Provide better trigger exception logging

2008-12-31T21:23:23Z

Just a quick heads up as it looks like I spoke too soon as the patch
causes problems with the project integration. If I run a project it
*always* complete integration regardless of whether or not there were
modifications thus triggering whatever publishers are active.

I haven't determined the cause yet but this patch definitely breaks

Re: issue 748 : Provide better trigger exception logging

2008-12-30T22:39:08Z

Hi Ruben,
I saw the call to Stopped() which I've commented out for now in my
build. I played around with the restart options and found the things
you mentioned to work accordingly.

Thanks again,
-Steve