+1 to all suggestions. Hudkins is my new favourite word. ;) One quick concern I have, is how much of the things listed are already available on the Apache hudson server? A lot of this is .NET specific, so unlikely that it will already be available. We'll have to request that ASF Infra team install these tools for us, and they may not agree, or there might be licensing issues, etc.. Not sure. I'd start the conversation with them now to suss this out.
Specifically some thoughts: - FxCop/StyleCop/NCover/NDepend are a basics which should be viewed as a necessity for any serious .NET project - I love SandCastle and was about to bring that up on the list. We could keep rolling with NDoc. Either way. - I love Gallio/MbUnit/Moq... nunit not so much, but again, either would be fine. - Mono is going to be a requirement moving forward - Project structure was being discussed on the LUCENENET-377 thread. For the binary release, I used a structure similar to what you were describing, and the topic of applying that structure to trunk came up. This is something that we should discuss in detail before applying to trunk (my work was in a branch). We need to make sure directory structure remains relatively static, however, current structure needs a lot of improvement.. So now is a good time to change. Digy suggested: \build \contrib \core \core\Lucene.Net \core\Test \demo ... and in the recent binary release, I used a root \bin and \doc in the same way you suggested. As a combination of ideas, how about: Build Files: \build \build\VS2008 \build\VS2010 Source Projects: \src \src\contrib \src\core \src\demo \src\contrib\<project-name> \src\core\<project-name> \src\demo\<project-name> Test Projects: \test \test\contrib \test\core \test\demo \test\contrib\<project-name> \test\core\<project-name> \test\demo\<project-name> Product Documentation: \doc \doc\contrib \doc\core \doc\demo \doc\contrib\<project-name> \doc\core\<project-name> \doc\demo\<project-name> Third-Party Dependencies: \lib \lib\<vendor> \lib\<vendor>\<product> \lib\<vendor>\<product>\<version> Binary Builds: \bin \bin\contrib \bin\core \bin\demo \bin\contrib\<project-name> \bin\core\<project-name> \bin\demo\<project-name> Thanks, Troy On Sun, Feb 27, 2011 at 11:10 PM, Michael Herndon <mhern...@o19s.com> wrote: > So the CI choices for Apache are the following: > > > - Buildbot <http://ci.apache.org/#buildbot> > - Continuum <http://ci.apache.org/#continuum> > - Gump <http://ci.apache.org/#gump> > - Hudson <http://ci.apache.org/#hudson> > > There is a current discussion on the build list about moving with the name > shift of hudson to jenkins. > > My vote is to go with hudkins [?] because it has been successfully used for > .net projects in the past and has plugins to help support that. Nothing > personal against python, but there seems to be more material on integration > .net builds inside of Hudson. > > I've also used Hudson in the past so I can vouch that it does a decent job. > (This was a while ago, so I can only hope the number of plugins and > integration points have increased). > > I'm going to do a bit more reading on the apache mailing list for builds to > see if there is an actual windows slave for hudson/jenkins (which shall > henceforth be called hudkins on this list, well at least by me). > > Obviously the first priority will be getting a build set up and starting > simple. However to spark discussion and future planning: Here is a list of > other things to include or think about for the build process long term. > > * fxcop - (this will probably need customized rules for strict java port > version) > * stylecop - (same) > * sandcastle - (building xml comments into documentation). > * sandcastle help file builder - (SHFB) > * code coverage tool - possibly seeing if we can get a code coverage tool > (possibly ncover as they used to give a free license to os projects), > * code metrics tool - (i.e. cyclomatic complexity, ndepend used to do the > same thing as ncover, thus worth investigating). > * gallio test runner vs nunit. (gallio is testing automation tool capable > of running various testing frameworks and tools including nunit). > * extended msbuild tasks. > * mono build. > * project structure for the build. ** > * insert _____ any other suggestions here. > > I'll volunteer myself for the boring job of fixing up xml comments so there > is some meat and code examples inside xml comments so > the documentation generates more than just text and method signatures with > type information. > > After some discussion in the list and unless there is show stopper or > killer reason not to go with hudkins. I'll notate the decision the jira and > start putting notes in the wiki about the CI. > > notes: > ----------------- > ** a common project structure/format or some variant there of, which might > be more intuitive for people that have worked on other foss projects. > trunk|root > /src (source) > /lib|vendor (dependencies) > /tests (test code) > /docs (documentation, architechture, diagrams, notes, etc) > /bin (executables - bat, exe, cmd files, etc) > root documents (licenses,readme,etc) > > - Michael > > > >
