You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Michael Herndon <mh...@o19s.com> on 2011/02/28 08:10:14 UTC
[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
Re: [Lucene.Net] CI Task Update: Hudkins
Posted by Stefan Bodewig <bo...@apache.org>.
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
Posted by Michael Herndon <mh...@wickedsoftware.net>.
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 <mherndon@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 <th...@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 <sl...@theta.net>
> wrote:
> >> +1
> >>
> >> Scott
> >>
> >> On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig <bo...@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
Posted by Michael Herndon <mh...@wickedsoftware.net>.
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 <th...@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 <sl...@theta.net> wrote:
>> +1
>>
>> Scott
>>
>> On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig <bo...@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
Posted by Michael Herndon <mh...@o19s.com>.
The licenses on some of the tools may not cover having them in svn. If
there were free open source versions that allowed redistributing the
binaries of all the tools listed that did the job well, we could put them
into svn.
However as far as I know there isn't a pure .net open source tool chain for
some of the tools listed above.
Thus it needs to be put on the slave or accessible from the slave with the
limited licenses.
Also one would want to install hudson plugins that generate reports and
graphical information based on the xml documents generated during the build.
Then have hudson process them on initial load and display them on the
dashboard / build output.
- Michael
On Thu, Mar 3, 2011 at 1:57 PM, Wyatt Barnett <wy...@gmail.com>wrote:
> I'd ask if we need to install this stuff on hudson at all -- most of
> it is command line utilites that can be transported with the source in
> svn anyhow. Sidebar advantages here are it is much easier to debug the
> build scrips since you have no environmental dependencies and you've
> got all the toys in one download.
>
> On Thu, Mar 3, 2011 at 10:05 AM, Michael Herndon <mh...@o19s.com>
> wrote:
> > Sorry I've been just reading through the list & wiki (
> > http://wiki.apache.org/general/Hudson)
> >
> > I subscribed to the list last night and haven't received the usual
> message
> > for activating subscriptions, I'll try again today and get on the list to
> > see what is already on the windows slave.
> >
> > We also have to ask if others are interested in tools that not installed
> and
> > if not install them under home/username.
> >
> > - michael.
> >
> > On Wed, Mar 2, 2011 at 5:19 PM, Troy Howard <th...@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 <sl...@theta.net>
> wrote:
> >> > +1
> >> >
> >> > Scott
> >> >
> >> > On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig <bo...@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
> >> >>
> >> >
> >>
> >
>
--
Michael Herndon
Senior Developer (mherndon@o19s.com)
804.767.0083
[connect online]
http://www.opensourceconnections.com
http://www.amptools.net
http://www.linkedin.com/pub/michael-herndon/4/893/23
http://www.facebook.com/amptools.net
http://www.twitter.com/amptools-net
Re: [Lucene.Net] CI Task Update: Hudkins
Posted by Wyatt Barnett <wy...@gmail.com>.
I'd ask if we need to install this stuff on hudson at all -- most of
it is command line utilites that can be transported with the source in
svn anyhow. Sidebar advantages here are it is much easier to debug the
build scrips since you have no environmental dependencies and you've
got all the toys in one download.
On Thu, Mar 3, 2011 at 10:05 AM, Michael Herndon <mh...@o19s.com> wrote:
> Sorry I've been just reading through the list & wiki (
> http://wiki.apache.org/general/Hudson)
>
> I subscribed to the list last night and haven't received the usual message
> for activating subscriptions, I'll try again today and get on the list to
> see what is already on the windows slave.
>
> We also have to ask if others are interested in tools that not installed and
> if not install them under home/username.
>
> - michael.
>
> On Wed, Mar 2, 2011 at 5:19 PM, Troy Howard <th...@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 <sl...@theta.net> wrote:
>> > +1
>> >
>> > Scott
>> >
>> > On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig <bo...@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
Posted by Michael Herndon <mh...@o19s.com>.
Sorry I've been just reading through the list & wiki (
http://wiki.apache.org/general/Hudson)
I subscribed to the list last night and haven't received the usual message
for activating subscriptions, I'll try again today and get on the list to
see what is already on the windows slave.
We also have to ask if others are interested in tools that not installed and
if not install them under home/username.
- michael.
On Wed, Mar 2, 2011 at 5:19 PM, Troy Howard <th...@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 <sl...@theta.net> wrote:
> > +1
> >
> > Scott
> >
> > On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig <bo...@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
Posted by Michael Herndon <mh...@o19s.com>.
response from build list:
On Thu, Mar 3, 2011 at 7:55 PM, Michael Herndon
<mh...@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 <th...@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 <sl...@theta.net> wrote:
>> +1
>>
>> Scott
>>
>> On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig <bo...@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
Posted by Troy Howard <th...@gmail.com>.
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 <sl...@theta.net> wrote:
> +1
>
> Scott
>
> On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig <bo...@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
Posted by Scott Lombard <sl...@theta.net>.
+1
Scott
On Mon, Feb 28, 2011 at 5:18 AM, Stefan Bodewig <bo...@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
Posted by Stefan Bodewig <bo...@apache.org>.
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
Posted by digy digy <di...@gmail.com>.
+1
DIGY
On Mon, Feb 28, 2011 at 10:29 AM, Troy Howard <th...@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 <mh...@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
>>
>>
>>
>>
>
Re: [Lucene.Net] CI Task Update: Hudkins
Posted by Troy Howard <th...@gmail.com>.
+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 <mh...@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
>
>
>
>