Re: [Lucene.Net] CI Task Update: Hudkins
Last call for build tool suggestions. Jira goes in later tonight. NCover has provided us a license. NDepend is on hiatus (more on this later). MSBuild tasks and other tools that are opensource will go into the project SCM. We'll put in logic into the build scripts will attempt to detect the tools and then fall back and not use them if they can not be found. - Michael On Sun, Mar 6, 2011 at 2:33 PM, Michael Herndon mhern...@wickedsoftware.net wrote: Are there any other tools that anyone wishes to be installed on the windows / mono slaves? I'll put the jira for the tools to be installed in by wednesday. I'll be e-mailing for foss licenses for ndepend ncover tomorrow. And verify the fxcop license. Mono's Gendarme was also a good suggestion. - Michael On Wed, Mar 2, 2011 at 5:19 PM, Troy Howard thowar...@gmail.com wrote: I've been following builds@ for the past couple of days. Looks like they just finished the migration to Jenkins. Michael - Have you had a chance to contact them and find out what tools are available out of our list? Want me to do that? Thanks, Troy On Mon, Feb 28, 2011 at 9:19 PM, Scott Lombard slomb...@theta.net wrote: +1 Scott On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig bode...@apache.org wrote: On 2011-02-28, Troy Howard wrote: One quick concern I have, is how much of the things listed are already available on the Apache hudson server? builds@apache is the place to ask. A lot of this is .NET specific, so unlikely that it will already be available. well, the DotCMIS build seems to be using Sandcastle Helpfile Builder by looking the console output. 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. Really, go to the builds list. License issues usually don't show up for build tools. It may be good if anybody of the team could volunteer time helping administrate the Windows slave. - Mono is going to be a requirement moving forward This could be done on a non-Windows slave just to completely sure it works. This may require installing a newer Mono (or just pulling in in a different Debian package source for Mono) than is installed by default. - Project structure was being discussed on the LUCENENET-377 thread. As a quick note, in general we prefer the mailing list of JIRA for discussions around the ASF. Stefan
Re: [Lucene.Net] CI Task Update: Hudkins
Are there any other tools that anyone wishes to be installed on the windows / mono slaves? I'll put the jira for the tools to be installed in by wednesday. I'll be e-mailing for foss licenses for ndepend ncover tomorrow. And verify the fxcop license. Mono's Gendarme was also a good suggestion. - Michael On Wed, Mar 2, 2011 at 5:19 PM, Troy Howard thowar...@gmail.com wrote: I've been following builds@ for the past couple of days. Looks like they just finished the migration to Jenkins. Michael - Have you had a chance to contact them and find out what tools are available out of our list? Want me to do that? Thanks, Troy On Mon, Feb 28, 2011 at 9:19 PM, Scott Lombard slomb...@theta.net wrote: +1 Scott On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig bode...@apache.org wrote: On 2011-02-28, Troy Howard wrote: One quick concern I have, is how much of the things listed are already available on the Apache hudson server? builds@apache is the place to ask. A lot of this is .NET specific, so unlikely that it will already be available. well, the DotCMIS build seems to be using Sandcastle Helpfile Builder by looking the console output. 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. Really, go to the builds list. License issues usually don't show up for build tools. It may be good if anybody of the team could volunteer time helping administrate the Windows slave. - Mono is going to be a requirement moving forward This could be done on a non-Windows slave just to completely sure it works. This may require installing a newer Mono (or just pulling in in a different Debian package source for Mono) than is installed by default. - Project structure was being discussed on the LUCENENET-377 thread. As a quick note, in general we prefer the mailing list of JIRA for discussions around the ASF. Stefan
Re: [Lucene.Net] CI Task Update: Hudkins
response from build list: On Thu, Mar 3, 2011 at 7:55 PM, Michael Herndon mhern...@wickedsoftware.net wrote: Also does anyone know of the existing tools that maybe available on the windows slave such as: ncover, ndepend, fxcop, msbuild, versions of the .net framework etc. (If these does not already exist on the server, we would like to request licenses for opensource projects for both ncover ndepend) Sorry, our documentation for what we got installed on the different slaves is not kept up to date :-/ Anyways, we got .Net 2.0, 3.5 and 4.0 installed on the Windows slave. As for the other tools, please open JIRA issues and I'll take care of them. Also, if you could assist in requesting the needed licenses, that would be great. Which version of the OS is installed on the windows salve? Windows Server Standard 2008, Service Pack 2. Would it be possible to also setup a mono build on a linux slave? Yes. Requested additionally needed packages if needed On Wed, Mar 2, 2011 at 5:19 PM, Troy Howard thowar...@gmail.com wrote: I've been following builds@ for the past couple of days. Looks like they just finished the migration to Jenkins. Michael - Have you had a chance to contact them and find out what tools are available out of our list? Want me to do that? Thanks, Troy On Mon, Feb 28, 2011 at 9:19 PM, Scott Lombard slomb...@theta.net wrote: +1 Scott On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig bode...@apache.org wrote: On 2011-02-28, Troy Howard wrote: One quick concern I have, is how much of the things listed are already available on the Apache hudson server? builds@apache is the place to ask. A lot of this is .NET specific, so unlikely that it will already be available. well, the DotCMIS build seems to be using Sandcastle Helpfile Builder by looking the console output. 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. Really, go to the builds list. License issues usually don't show up for build tools. It may be good if anybody of the team could volunteer time helping administrate the Windows slave. - Mono is going to be a requirement moving forward This could be done on a non-Windows slave just to completely sure it works. This may require installing a newer Mono (or just pulling in in a different Debian package source for Mono) than is installed by default. - Project structure was being discussed on the LUCENENET-377 thread. As a quick note, in general we prefer the mailing list of JIRA for discussions around the ASF. Stefan
Re: [Lucene.Net] CI Task Update: Hudkins
+1 DIGY On Mon, Feb 28, 2011 at 10:29 AM, Troy Howard thowar...@gmail.com wrote: +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.comwrote: 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
Re: [Lucene.Net] CI Task Update: Hudkins
On 2011-02-28, Michael Herndon 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 I could talk hours about Gump (after all I'm the chairman of the Gump PMC) but let me just state it is not really a CI system as you'd expect so it is not a good option for day-to-day CI. Its purpose is different. 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). https://hudson.apache.org/hudson/computer/windows1/ and the chemistry DotCMIS project is a .NET build (looks like it was using framework 3.5). Stefan
Re: [Lucene.Net] CI Task Update: Hudkins
On 2011-02-28, Troy Howard wrote: One quick concern I have, is how much of the things listed are already available on the Apache hudson server? builds@apache is the place to ask. A lot of this is .NET specific, so unlikely that it will already be available. well, the DotCMIS build seems to be using Sandcastle Helpfile Builder by looking the console output. 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. Really, go to the builds list. License issues usually don't show up for build tools. It may be good if anybody of the team could volunteer time helping administrate the Windows slave. - Mono is going to be a requirement moving forward This could be done on a non-Windows slave just to completely sure it works. This may require installing a newer Mono (or just pulling in in a different Debian package source for Mono) than is installed by default. - Project structure was being discussed on the LUCENENET-377 thread. As a quick note, in general we prefer the mailing list of JIRA for discussions around the ASF. Stefan
Re: [Lucene.Net] CI Task Update: Hudkins
+1 Scott On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig bode...@apache.org wrote: On 2011-02-28, Troy Howard wrote: One quick concern I have, is how much of the things listed are already available on the Apache hudson server? builds@apache is the place to ask. A lot of this is .NET specific, so unlikely that it will already be available. well, the DotCMIS build seems to be using Sandcastle Helpfile Builder by looking the console output. 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. Really, go to the builds list. License issues usually don't show up for build tools. It may be good if anybody of the team could volunteer time helping administrate the Windows slave. - Mono is going to be a requirement moving forward This could be done on a non-Windows slave just to completely sure it works. This may require installing a newer Mono (or just pulling in in a different Debian package source for Mono) than is installed by default. - Project structure was being discussed on the LUCENENET-377 thread. As a quick note, in general we prefer the mailing list of JIRA for discussions around the ASF. Stefan
[Lucene.Net] CI Task Update: Hudkins
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
