ccnet-devel Mailing List for CruiseControl.NET

i've refactored the unit tests for the NAntBuilder class (should be part of
build 162 on ccnetlive).  some users reported having trouble running the
unit tests as a product of the NAntBuilderTest's dependency on the location
of the nant executable.  this dependency has now been removed as all calls
to NAnt have been mocked.

my next task is to eliminate all of the superfluous failures on ccnetlive.
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/.

Owen Rogers wrote:

>a couple of users mentioned that they were receiving a Win32Exception when
>trying to launch the build web page from cctray.  i believe that this is
>because their environment does not allow them to launch a browser window by
>passing a url to a process directly.  so, i have updated cctray to
>explicitly use Internet Explorer to display the build page.  if you don't
>like IE and want cctray to use the browser of your choice, you can modify
>the cctray usersettings.xml file and change the <browser> element to launch
>whichever browser you choose.
>  
>

We're changing the behaviour for everybody because a couple of people 
have problems. I don't really want IE coming up on my system if I've set 
up Mozilla as my default browser. Can you investigate further the 
problems those particular users are getting? Or use "start" as the 
process, and pass the URL as an argument?

Cheers,
Mike.

a couple of users mentioned that they were receiving a Win32Exception when
trying to launch the build web page from cctray.  i believe that this is
because their environment does not allow them to launch a browser window by
passing a url to a process directly.  so, i have updated cctray to
explicitly use Internet Explorer to display the build page.  if you don't
like IE and want cctray to use the browser of your choice, you can modify
the cctray usersettings.xml file and change the <browser> element to launch
whichever browser you choose.
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/.

Hi Bob,

So just to make it clear, you have 2 things - 1 is a standalone script 
or application that generates all the files / config updates you 
explained, and one is some updates to the CCTray?

We've definitely been thinking of doing the 2nd of those, and the first 
would be a great addition until we have a 'nirvana' GUI app that does 
all these things.

In terms of contribution, I'd definitely be interested in trying to 
integrate both into the project. Just 2 project admin things I should 
mention though:
- Although CruiseControl.NET is an open-source project, ThoughtWorks 
retains copyright to the entire source tree, so I need to check that you 
(and your company if necessary) would be ok about ThoughtWorks taking 
copyright for your contribution.
- Because of our desire to retain copyright and project direction, all 
the CCNet committers are developers at ThoughtWorks, so we don't want 
give commit privileges to others outside of the company.

If you're OK with both of these things, I'd definitely appreciate your 
updates and would work to get them into the project ASAP.

Many thanks,

Mike

Bob Vandehey wrote:

> We have just spent about two weeks adding multi-project support to 
> CruiseControl. We have added the ability to automatically add a new 
> project which sets up a new entry in the ccnet.config, creates a 
> default build file, creates the appropriate folders and creates a 
> virtual directory within IIS. We have also added multi-project support 
> to CCTray. I would be willing to contribute these changes back to the 
> community. Are you interested or are you already developing this 
> functionality separately?
>
> **Robert D. Vandehey**
> Director, Research & Development
>
> Integrated Data Systems
> 21051 Warner Center Lane, Ste 220
> Woodland Hills, CA  91367
> Phone: 818.223.3344 x3832
> Fax: 818.206.3832
> Email: bva...@id... <mailto:bva...@id...>
> www.idsus.com <http://www.idsus.com/>
>
>  
>
>
> -- This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they 
> are addressed. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and 
> delete this e-mail from your system. If you are not the intended 
> recipient you are notified that disclosing, copying, distributing or 
> taking any action in reliance on the contents of this information is 
> strictly prohibited.

Hi
=20
    On the "web" project there's a bug in reading the "ServerLog"
option.
    It will say that the file is locked by another process.
=20
    Solution is to modify the file "ServerLogFileReader.cs"
=20
    private bool OpenFile()
  {
   Debug.Assert(_reader =3D=3D null && _readLines =3D=3D 0);
   if (_filename !=3D null)
   {
=20
    //*********************************
    // This does not work
   //*********************************
      _reader =3D new BufferedStream(new FileStream(_filename,
FileMode.Open, FileAccess.Read));
  =20
        //*********************************
       // This Works
        //*********************************
    _reader =3D new BufferedStream(new FileStream(_filename,
FileMode.Open, FileAccess.Read, FileShare.ReadWrite));

    return _reader.Length > 0;
   }
   else
   {
    return false;
   }
  }

i've upgraded ccnetlive to use build 155.  everything a-ok.
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/.

Excellent.=20

-------------------------------
Peter G Jones
University of Canterbury, NZ
-------------------------------=20
Senior Analyst/Programmer
Microsoft .Net MVP
Blog: http://jonsie.net


=20

> -----Original Message-----
> From: Mike Roberts [mailto:mik...@th...]=20
> Sent: Thursday, 25 March 2004 10:10 AM
> To: Peter Jones
> Cc: Owen Rogers; ccn...@li...
> Subject: Re: [Ccnet-devel] RE: design suggestions: multiple=20
> projects in the webapp
>=20
> Peter Jones wrote:
>=20
> >Well, since you asked...
> >
> >I find that having 2 web sites - ie, the dashboard and the project
> >site(s) - very confusing.  If these could be combined it would make=20
> >things a lot easier.  You could then have the current dashboard home=20
> >page as the menu and the merged webapp pages would only need=20
> the name=20
> >of the current project displayed somewhere.
> > =20
> >
> That's exactly the approach I was thinking of taking - the=20
> dashboard would become the home page for the CCNet Web App,=20
> but obviously a project's detailed page can be linked to=20
> directly if required. Detailed pages will need a link back to=20
> the dashboard and/or a list of other projects (I'm thinking a=20
> drop-down box and a dashboard link is the way to go).
>=20
> I'm going to start working on this whole are over the next=20
> week or so (I've been on vacation a lot recently, which is=20
> why it hasn't happened over the last couple of months). The=20
> other reason I've been slow off the ground is that the other=20
> thing the detailed web app should do is get pre-styled=20
> results from the server - I'm very bad at taking baby steps=20
> though and tend to want to make big changes in one go, but=20
> I'll try and actually do the update incrementally for a change. :)
>=20
> Cheers,
>=20
> Mike
>=20
>=20

Peter Jones wrote:

>Well, since you asked...
>
>I find that having 2 web sites - ie, the dashboard and the project
>site(s) - very confusing.  If these could be combined it would make
>things a lot easier.  You could then have the current dashboard home
>page as the menu and the merged webapp pages would only need the name of
>the current project displayed somewhere.
>  
>
That's exactly the approach I was thinking of taking - the dashboard 
would become the home page for the CCNet Web App, but obviously a 
project's detailed page can be linked to directly if required. Detailed 
pages will need a link back to the dashboard and/or a list of other 
projects (I'm thinking a drop-down box and a dashboard link is the way 
to go).

I'm going to start working on this whole are over the next week or so 
(I've been on vacation a lot recently, which is why it hasn't happened 
over the last couple of months). The other reason I've been slow off the 
ground is that the other thing the detailed web app should do is get 
pre-styled results from the server - I'm very bad at taking baby steps 
though and tend to want to make big changes in one go, but I'll try and 
actually do the update incrementally for a change. :)

Cheers,

Mike

Hi all,

The community site has now moved to 
http://confluence.public.thoughtworks.org/display/CCNETCOMM/Home. The 
reason for this is that we've decided to move the main CCNet Website and 
documentation onto Confluence aswell, and that will be in the 'CCNet' 
Space. We've done this so that the documentation and website are easier 
to edit and so (hopefully!) we'll be updated more frequently.

The CCNet Website space is not publically edittable but the community 
space is.

At present, the old website is still the same content, but we'll move 
content across to Confluence over the next week or two and then we'll 
redirect the old URLs at the new server.

If you have any questions then please ask.

Cheers,

Mike

Mike Roberts wrote:

> Hi all,
>
> As Owen mentioned a few days ago, we now have a 'Confluence' site - 
> basically a wiki, but quite a lot more powerful than that. I've added 
> some basic structure now, but this can always be changed.
>
> Its community updatable, so please feel free to go and add stuff!

Well, since you asked...

I find that having 2 web sites - ie, the dashboard and the project
site(s) - very confusing.  If these could be combined it would make
things a lot easier.  You could then have the current dashboard home
page as the menu and the merged webapp pages would only need the name of
the current project displayed somewhere.

An interim solution way may be to specify a parameter to the current
webapp for the name of the project in ccnet.config.  The webapp can then
read the logdir and other properties from ccnet.config instead of it's
own web.config.  In fact if all it needs is the logdir and a project
name to disply then these could both be parameters and you wouldn't need
to read the ccnet.config at all.

As for CCTray, this should also read the ccnet.config (probably via
remoting?) and it could then monitor all or selected projects.

I'd love to dive into the code and figure out how to do this for you but
I'm just too busy at present.  I may see if I can hack web app though...

Cheers


-------------------------------
Peter G Jones
University of Canterbury, NZ
-------------------------------=20
Senior Analyst/Programmer
Microsoft .Net MVP
Blog: http://jonsie.net


=20

> -----Original Message-----
> From: Owen Rogers [mailto:OR...@th...]=20
> Sent: Wednesday, 24 March 2004 6:57 PM
> To: ccn...@li...
> Cc: Peter Jones
> Subject: design suggestions: multiple projects in the webapp
>=20
>=20
>=20
>=20
>=20
> the fact that the webapp _still_ only supports a single=20
> project view is a bit of longstanding issue for ccnet.  it's=20
> not that it is technically hard to implement -- for me at=20
> least, the main reason that i have hestitated picking up this=20
> task is because i wasn't sure of a good way to design it from=20
> a usability perspective (UIs are hardly my forte).
>=20
> i'm curious as to what suggestions you have as to which=20
> usability idiom would be most appropriate for displaying and=20
> accessing different projects within the web UI.  a few idioms=20
> come to mind:
>=20
> - a tab-based view that has the project name on each tab. =20
> selecting a tab will display the main page for that project
>       - where should this be located?  along the top of the=20
> screen?  above the project links or beside them?
>=20
> - drop-down list of projects that enables you to select and=20
> navigate to the project you want to see
>       - where should this reside?  in the left sidebar?  next=20
> to the project links?
>=20
> - a horizontal set of links ( eg. project 1 | project 2 |=20
> project 3) -- this is probably the easiest to implement from=20
> a UI perspective
>       - where should this reside?  along the bottom next to=20
> the TW logo?
>=20
> any other ideas?  any preferences?  what would be the most=20
> intuitve idiom?
> what would be the most convenient location? (i'm leaning=20
> towards option 3 myself, just to get it done, and then=20
> refactoring to something more attractive later).
> cheers,
> owen.
> ---
> R. Owen Rogers
> ThoughtWorks Technologies (India) Pvt Ltd.
>=20
> ThoughtWorks - Deliver with passion!
>=20
> ThoughtWorks is always looking for talented people who are=20
> passionate about technology.  To find out more about a career=20
> at ThoughtWorks go to http://www.thoughtworks.com/career/.
>=20
>=20
>=20

following Mike Two's suggestion, i've created 'Build' configurations for
all of the ccnet projects.  this configuration is used when you do a build
using the nant build file.  as previously discussed, the purpose of this
change is to eliminate the assembly lock contentions when building to the
same location as VS.NET.  in the process, i've also stopped the build from
trying to run nunit on assemblies without tests and i've gone through the
deployment packaging, and eliminated some of the superfluous assemblies
(drew's wobbly form is gone too :) ).  oh, and i upgraded to a new verison
of nant in the process to fix some of the bugs with the <solution> task.
in short, the build process should be easier and more streamlined.
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/.

Hi, 

thought I'd interject at this point.

> i'm curious as to what suggestions you have as to which 
> usability idiom would be most appropriate for displaying and 
> accessing different projects within the web UI.  a few idioms 
> come to mind:
> 
> - a tab-based view that has the project name on each tab.  
> selecting a tab will display the main page for that project
>       - where should this be located?  along the top of the 
> screen?  above the project links or beside them?

Tabs would be fine, until I go and use ccnet for 10 projects and the tabs
scroll off the screen. I don't think tabs are the right idea.

> - drop-down list of projects that enables you to select and 
> navigate to the project you want to see
>       - where should this reside?  in the left sidebar?  next 
> to the project links?

I would say in the left sidebar, and this is a reasonable idea - it's quite
scalable.

> - a horizontal set of links ( eg. project 1 | project 2 | 
> project 3) -- this is probably the easiest to implement from 
> a UI perspective
>       - where should this reside?  along the bottom next to 
> the TW logo?

This again suffers from the too many projects problem - it will make the
page too big.

> any other ideas?  any preferences?  what would be the most 
> intuitve idiom?

Project grouping? Then you could select a group from a drop-down, and then
each project would be listed in the sidebar with its 'x' most recent builds
and a link to see them all:

Project Group: Banana

Project1
2004-01-01 10:34
2003-12-30 11:12
...

Project2
Some
More
Dates

...

That would allow me to create a Components group, and then a group for each
department showing only their main projects. The more I think about it the
more I like the idea.

> what would be the most convenient location? (i'm leaning 
> towards option 3 myself, just to get it done, and then 
> refactoring to something more attractive later).

Sounds to me like more effort for the team in the long run?! 

________________________________________________________________________
This e-mail has been scanned for viruses by MessageLabs.

the fact that the webapp _still_ only supports a single project view is a
bit of longstanding issue for ccnet.  it's not that it is technically hard
to implement -- for me at least, the main reason that i have hestitated
picking up this task is because i wasn't sure of a good way to design it
from a usability perspective (UIs are hardly my forte).

i'm curious as to what suggestions you have as to which usability idiom
would be most appropriate for displaying and accessing different projects
within the web UI.  a few idioms come to mind:

- a tab-based view that has the project name on each tab.  selecting a tab
will display the main page for that project
      - where should this be located?  along the top of the screen?  above
the project links or beside them?

- drop-down list of projects that enables you to select and navigate to the
project you want to see
      - where should this reside?  in the left sidebar?  next to the
project links?

- a horizontal set of links ( eg. project 1 | project 2 | project 3) --
this is probably the easiest to implement from a UI perspective
      - where should this reside?  along the bottom next to the TW logo?

any other ideas?  any preferences?  what would be the most intuitve idiom?
what would be the most convenient location? (i'm leaning towards option 3
myself, just to get it done, and then refactoring to something more
attractive later).
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/.

Hrm, I set all my users to "always" (we're in early development), so I
don't think the change group would be a problem.

The only thing I can think of that I did out-of-the-norm would be to
have a friendly email name.

So instead of "bl...@bl..., it was "PROJECT 1.0 Build<bl...@bl...>".
This is valid as far as .NET's SmtpMail is concerned as well as the SMTP
spec and virtually ever email client out there.

But if you're doing special processing with the email address, it could
have an effect perhaps? Otherwise, I doubt this would interfere with
anything.

-Chad

-----Original Message-----
From: Owen Rogers [mailto:OR...@th...]=20
Sent: Monday, March 22, 2004 8:03 AM
To: Chad Myers
Cc: ccn...@li...
Subject: Re: [Ccnet-devel] Email stopped working?





hi chad,
there was a bug fix with the way that ccnet was building the list of
recipients that it should send an email to.  maybe this is the cause of
the
problem that you are having.  here's how the mailing lists are built:

ccnet supports two types of notification for its mail groups: always and
change.  email addresses in an 'always' group receive emails every time
a
new build is run.  email addresses in a 'change' group receive emails
only
when i) the state of the integration server has changed (ie. the build
has
gone from working to broken or from broken to fixed) or ii) when they
have
checked in changes that have caused a successful build.

now there's one subtle point to understand with the change group.  the
email user 'name' *must* match the user id of the user for the
sourcecontrol system.  what ccnet does is it parses the modifications,
extracts the user id and then when building the mailing list, looks up
the
email user by this id.

does this help you diagnose the problem that you are experiencing?  if
not,
let's log a jira issue and investigate this further.
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/.


|---------+--------------------------------------->
|         |           "Chad Myers"                |
|         |           <ch...@ch...>        |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           12/03/2004 23:46            |
|---------+--------------------------------------->
=20
>-----------------------------------------------------------------------
------------------------------------------------------------------------
---|
  |
|
  |       To:       <ccn...@li...>
|
  |       cc:
|
  |       Subject:  [Ccnet-devel] Email stopped working?
|
=20
>-----------------------------------------------------------------------
------------------------------------------------------------------------
---|




I just upgraded to CC.NET 0.5 and all the Subversion 1.0 stuff is
working now, thanks for that fix! :)

Everything is running great except emails aren't going out now (even
though my config file is exactly the same and also matches the new
example.config).

Has anything changed with email since the last build?

Thanks,
Chad



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

hi mark,
thanks for raising this.  i'll see if i can answer your question:

SiteMesh - SiteMesh.NET is a web templating engine:
http://sourceforge.net/projects/sitemesh.  it is a port of the popular
OpenSymphony SiteMesh for Java.  basically it allows us to have a
consistent look and feel across the different pages in the CCNet web app.
NetReflector - NetReflector is a Xml data binding framework implemented by
me: http://sourceforge.net/projects/netreflector.  All those
[ReflectorType] attributes that you see scattered throughout the codebase
are from NetReflector.
YPluginDLL - this is a dependency for the YahooPublisher implemented by
Ajey Gore: it enables you to publish CCNet build updates via Yahoo
Messenger.  Note: this publisher is not currently included with CCNet
releases.  If anyone is interested in finding out more about this, let us
know.
Nmock - NMock is a mock objects framework for .NET.  It is used extensively
in our process of designing and testing the code.  For more information go
to: http://sourceforge.net/projects/nmock for project information and here:
http://www.mockobjects.com/wiki/ for information about mocking in general.
Marathon - Marathon.NET is a functional testing tool for testing WinForm
GUIs.  It features record-and-playback functionality.
http://sourceforge.net/projects/marathonnet.  It is currently used by the
CruiseControl.NET Control Panel (a soon-to-be-released GUI for managing
CCNet configuration files).

cheers,
owen.

ps. this is now posted on the confluence site:
http://confluence.public.thoughtworks.org/display/CCNET/FAQ

---
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/.


|---------+--------------------------------------->
|         |           "Mark Watts"                |
|         |           <mw...@st...>       |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           14/03/2004 09:27            |
|---------+--------------------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:       <ccn...@li...>                                                                                              |
  |       cc:                                                                                                                                        |
  |       Subject:  [Ccnet-devel] Used libraries                                                                                                     |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




I have been reading the source code for CC.Net and I ran across some used
libraries that did not contain any source code and no documentation about
where to get the source, what the libraries were used for,etc.  After some
googlling I tracked down most of them to
http://opensource.thoughtworks.com/
(which makes sense given the relationship of CC.Net to ThoughtWorks).

My suggestion is to add some documentation, perhaps just in the readme
about
these libraries, what they are for and where to obtain them.

The libraries in question:
SiteMesh
NetReflector
YPluginDLL
Nmock
Marathon

PS: I still havn't tracked down YPluginDLL

-Mark




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

hi chad,
there was a bug fix with the way that ccnet was building the list of
recipients that it should send an email to.  maybe this is the cause of=
 the
problem that you are having.  here's how the mailing lists are built:

ccnet supports two types of notification for its mail groups: always an=
d
change.  email addresses in an 'always' group receive emails every time=
 a
new build is run.  email addresses in a 'change' group receive emails o=
nly
when i) the state of the integration server has changed (ie. the build =
has
gone from working to broken or from broken to fixed) or ii) when they h=
ave
checked in changes that have caused a successful build.

now there's one subtle point to understand with the change group.  the
email user 'name' *must* match the user id of the user for the
sourcecontrol system.  what ccnet does is it parses the modifications,
extracts the user id and then when building the mailing list, looks up =
the
email user by this id.

does this help you diagnose the problem that you are experiencing?  if =
not,
let's log a jira issue and investigate this further.
cheers,
owen.

---
R. Owen Rogers
ThoughtWorks Technologies (India) Pvt Ltd.


ThoughtWorks - Deliver with passion!

ThoughtWorks is always looking for talented people who are passionate a=
bout
technology.  To find out more about a career at ThoughtWorks go to
http://www.thoughtworks.com/career/.


|---------+--------------------------------------->
|         |           "Chad Myers"                |
|         |           <ch...@ch...>        |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           12/03/2004 23:46            |
|---------+--------------------------------------->
  >--------------------------------------------------------------------=
-----------------------------------------------------------------------=
-------|
  |                                                                    =
                                                                       =
       |
  |       To:       <ccn...@li...>                =
                                                                       =
       |
  |       cc:                                                          =
                                                                       =
       |
  |       Subject:  [Ccnet-devel] Email stopped working?               =
                                                                       =
       |
  >--------------------------------------------------------------------=
-----------------------------------------------------------------------=
-------|




I just upgraded to CC.NET 0.5 and all the Subversion 1.0 stuff is
working now, thanks for that fix! :)

Everything is running great except emails aren't going out now (even
though my config file is exactly the same and also matches the new
example.config).

Has anything changed with email since the last build?

Thanks,
Chad



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
=

Hi all,

As Owen mentioned a few days ago, we now have a 'Confluence' site - 
basically a wiki, but quite a lot more powerful than that. I've added 
some basic structure now, but this can always be changed.

Its community updatable, so please feel free to go and add stuff!

http://confluence.public.thoughtworks.org/display/CCNET/Home

Cheers,

Mike

Hi all,

I've updated the docs to include how to setup the 'file' and 'multi' 
source control options. See 
http://ccnet.thoughtworks.com/docs/server/ccnet.config.html#file

'Multi' is an interesting one since it allows you to do 'Enterprise' 
Continuous Integration (i.e. CI across multiple projects)

Mike

The following comment has been added to this issue:

     Author: Mike Roberts
    Created: Sun, 21 Mar 2004 1:37 PM
       Body:
Done
---------------------------------------------------------------------
View the issue:

  http://jira.truemesh.com/secure/ViewIssue.jspa?key=CC-12


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CC-12
    Summary: Sample Source Control Configs
       Type: Story

     Status: Resolved
   Priority: Critical
 Resolution: FIXED

 Time Spent: Unknown
   Estimate: 0 minutes

    Project: CruiseControl.NET
 Components: 
             Documentation
   Fix Fors:
             0.4

   Assignee: Mike Roberts
   Reporter: Mike Roberts

    Created: Tue, 4 Feb 2003 8:28 PM
    Updated: Sun, 13 Jul 2003 5:19 PM

Description:
As a User of CC .Net, I would like to have documentation so that I can configure my instance of CC to use any of the source control systems that CC supports


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.truemesh.com/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Brian Nantz wrote:

> First, why did you decide to go with logging via Trace instead of=20
> using Log4NET? Log4NET is proven and well documented. Anyone=20
> developing on CC.NET could easily understand the implementation and=20
> not have to figure out the custom Trace code. Not to mention Log4NET=92=
s=20
> configuration (ie logging level and output types) can be changed on=20
> the fly without restarting the server service. Log4NET also has an XML=20
> and HTML output that you can use out of the box or customize for=20
> things like your reports. Just a thought.

Hi Brian,

I'm not sure about this myself since I haven't worked on any of the=20
logging stuff - Owen?

> Also, Draco.NET has a nice new feature that allows you to build with=20
> VS.NET without using NAnt. While I believe this in general defeats the=20
> purpose of Continuous Integration because of the lack of Unit Testing,=20
> it is useful. Many developers who are new to CI who I have shown=20
> CC.NET/Draco.NET to really like to use it initially as just a build=20
> system with nice outputs (email, web, system tray, etc.). I think all=20
> Draco.NET is doing here is in the config file adding a type in=20
> addition to NAnt called Solution which probably just wraps the NAnt=20
> solution task, but I don=92t know that for sure. Just wondered if this=20
> functionality had been talked about for CC.NET?
>
I was thinking a while back of just making a generic 'executable=20
builder' which just runs any executable and captures stdout / stderr. We=20
could ship a batch file with CCNet which launches command line devenv=20
and then makes sure all the output (when using '/out') gets written to=20
stdout - what do you think?

Also, you *could* consider a valid CI setup with such a way of working=20
since you could add a 'post-build event' to run NUnit to any dlls that=20
contain Unit Tests. You'd have to make sure your environment was all=20
setup correctly to handle this but I don't see why it shouldn't work.

Cheers,

Mike

hi roberto,

> I'm doing a little modification to change the file names on the build
result
page in link to the corresponding page in ViewCVS or WebSVN (see the mht
file).  I think it can be useful.

i think that this is a great idea, though it would obviously have to be
configurable to accomodate different source controls.  i've created a new
issue on the jira to keep track of this feature request.
http://jira.public.thoughtworks.org/browse/CCNET-11.  please let me know
how it goes.
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/.

Hi Nick,

Glad that worked for you.

As for documenting the change, I never realized it worked the other way 
before, so I am a) not sure what has changed b) if this should be noted as 
a bug fix, the introduction of a bug, or simply a feature. Anybody else 
care to comment?

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
Not going to New Jersey isn't procrastination, it's common sense.






"Nicolas V." <le...@ho...> 
Sent by: ccn...@li...
03/15/2004 09:13 AM

To
WEC...@th...
cc
ccn...@li..., 
ccn...@li..., OR...@th..., 
sky...@ya...
Subject
Re: [Ccnet-devel] Re: [Ccnet-user] VSS Problem






Hi Bill,

This was effectivelly the problem. Thanks!!

However, maybe this should be logged somewhereas a change, as
         <baseDirectory>c:\local_build</baseDirectory>
         <buildFile>C:\Prog.Net\SigmaRHNet\nightly.build</buildFile>
worked perfectly in the last version I used (build 73).

Because of that I thought that <baseDirectory> was more to specify the 
workingDirectory, not a part of the path of the build file.

Regards,
Nick

----Original Message Follows----
From: William E Caputo <WEC...@th...>
To: le...@ho...
CC: 
ccn...@li...,ccn...@li...,OR...@th...,sky...@ya...
Subject: Re: [Ccnet-devel] Re: [Ccnet-user] VSS Problem
Date: Fri, 12 Mar 2004 13:23:46 -0600


Hi Nick,

I am not sure, but I think the problem is in these two lines of your
config file:

         <baseDirectory>c:\local_build</baseDirectory>
         <buildFile>C:\Prog.Net\SigmaRHNet\nightly.build</buildFile>

I believe the baseDirectory element should specify the location of your
buildfile, and the buildFile element should just be the name of your build
file like so:

         <baseDirectory>C:\Prog.Net\SigmaRHNet</baseDirectory> <!-- this
can also be a path that is relative to your ccnet.config file -->
         <buildFile>nightly.build</buildFile>

So, I am not sure what c:\local_build 's relationship to the other path
is, but this looks like a likely candidate to me (as it is different from
the config files I have used/written/seen.

Hope this helps.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
idia ktesis, koine chresis

_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous ! 
http://fr.ca.search.msn.com/



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

Hi Bill,

This was effectivelly the problem. Thanks!!

However, maybe this should be logged somewhereas a change, as
         <baseDirectory>c:\local_build</baseDirectory>
         <buildFile>C:\Prog.Net\SigmaRHNet\nightly.build</buildFile>
worked perfectly in the last version I used (build 73).

Because of that I thought that <baseDirectory> was more to specify the 
workingDirectory, not a part of the path of the build file.

Regards,
Nick

----Original Message Follows----
From: William E Caputo <WEC...@th...>
To: le...@ho...
CC: 
ccn...@li...,ccn...@li...,OR...@th...,sky...@ya...
Subject: Re: [Ccnet-devel] Re: [Ccnet-user] VSS Problem
Date: Fri, 12 Mar 2004 13:23:46 -0600


Hi Nick,

I am not sure, but I think the problem is in these two lines of your
config file:

         <baseDirectory>c:\local_build</baseDirectory>
         <buildFile>C:\Prog.Net\SigmaRHNet\nightly.build</buildFile>

I believe the baseDirectory element should specify the location of your
buildfile, and the buildFile element should just be the name of your build
file like so:

         <baseDirectory>C:\Prog.Net\SigmaRHNet</baseDirectory> <!-- this
can also be a path that is relative to your ccnet.config file -->
         <buildFile>nightly.build</buildFile>

So, I am not sure what c:\local_build 's relationship to the other path
is, but this looks like a likely candidate to me (as it is different from
the config files I have used/written/seen.

Hope this helps.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
idia ktesis, koine chresis

_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous !  
http://fr.ca.search.msn.com/

I have been reading the source code for CC.Net and I ran across some used
libraries that did not contain any source code and no documentation about
where to get the source, what the libraries were used for,etc.  After some
googlling I tracked down most of them to http://opensource.thoughtworks.com/
(which makes sense given the relationship of CC.Net to ThoughtWorks).

My suggestion is to add some documentation, perhaps just in the readme about
these libraries, what they are for and where to obtain them.

The libraries in question:
SiteMesh
NetReflector
YPluginDLL
Nmock
Marathon

PS: I still havn't tracked down YPluginDLL

-Mark

Hi Nick,

I am not sure, but I think the problem is in these two lines of your 
config file:

        <baseDirectory>c:\local_build</baseDirectory>
        <buildFile>C:\Prog.Net\SigmaRHNet\nightly.build</buildFile>

I believe the baseDirectory element should specify the location of your 
buildfile, and the buildFile element should just be the name of your build 
file like so:

        <baseDirectory>C:\Prog.Net\SigmaRHNet</baseDirectory> <!-- this 
can also be a path that is relative to your ccnet.config file -->
        <buildFile>nightly.build</buildFile>

So, I am not sure what c:\local_build 's relationship to the other path 
is, but this looks like a likely candidate to me (as it is different from 
the config files I have used/written/seen.

Hope this helps.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
idia ktesis, koine chresis