RE: Build CI Considerations

2011-01-29 Thread Prescott Nasser

would the accessibility just be a configuration script? I'm not sure how CI is 
set up, but I assume that we could set up something that points to our 
repository for that, thus any committer could update the configuration script.
 
Also, I dug a bit into Hudson (I'm not familiar with it), there is MSBuild 
support (http://wiki.hudson-ci.org/display/HUDSON/MSBuild+Plugin), and looking 
at the FAQ for Hudson that the apache infrastructure team has it looks like 
plugin's can be added 
(http://wiki.apache.org/general/Hudson#How_do_I_install_a_new_Hudson_plugin.3F).
 This is likely something they had to do for us, but I don't see why it would 
be an issue for them to do it for us
 
~Prescott





 Date: Sat, 29 Jan 2011 15:49:51 -0500
 Subject: Re: Build  CI Considerations
 From: mhern...@o19s.com
 To: lucene-net-dev@lucene.apache.org

 Something to think about for future use is accessibility of the build server
 for those maintaining.

 How we do go about sharing that information, obviously you don't want to
 hand out access to the ci server to a public mailing list.





 On Fri, Jan 28, 2011 at 1:41 PM, Wyatt Barnett wrote:

  Why do I forget to check against the obvious? Anyhow, I guess we can
  run with what we have, though that build is not doing much. Any idea
  how we get administrative access over there? Might as well try and get
  it to do stuff like run the tests as well.
 
  I think long-term, we'll need something a bit more custom, at least
  for the build slave/build agent angle --- that would be where the
  magic largely happens. Such as automated sharpen builds . . .
 
 
  On Thu, Jan 27, 2011 at 5:29 AM, digy digy wrote:
   No. It's Rune's work.
  
  
  http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/200912.mbox/%3c4b1820f4.10...@gmail.com%3E
  
   
  http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/200912.mbox/%3c4b1820f4.10...@gmail.com%3E
  
   DIGY
  
   On Thu, Jan 27, 2011 at 12:16 PM, Glyn Darkin   wrote:
  
   The guys at code better run a Team City CI which has been building
   Lucene.Net for a while
  
   I believe that DIGY set this up.
  
   http://teamcity.codebetter.com/login.html
  
   Glyn
  
  
   On 27 Jan 2011, at 09:28, Stefan Bodewig wrote:
  
On 2011-01-26, Wyatt Barnett wrote:
   
2) CI : oh hells yeah. My vision would be to setup something where
  the
automated conversion would be triggered by commits to the stable
branch of the java project. I think if we can construct this bit
  right
we can even really get down the road of automatically running all the
conversion options until we get it right.
   
Sounds good. Back to the mundane as you said later the ASF runs a
  few
options for CI , one of them is Hudson
which has at least one Windows
  slave
installation (Server 2008) and is supposed to support MSBuild.
  Buildbot
might work as well.
   
I'm not up to speed with the state of xbuild but adding support for it
to Gump (which fills quite a different role from a traditional CI)
wouldn't be too hard and give us builds on Mono - albeit 2.4 right
  now,
this could be changed by adding the Mono PPAs to the Ubuntu servers.
   
Stefan
  
   Glyn Darkin
  
   Darkin Systems Ltd
   Mob: 07961815649
   Fax: 08717145065
   Web: www.darkinsystems.com
  
   Company No: 6173001
   VAT No: 906350835
  
  
  
  
  
  
  
 



 --
 Michael Herndon
 Senior Developer (mhern...@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: Build CI Considerations

2011-01-27 Thread Stefan Bodewig
On 2011-01-26, Wyatt Barnett wrote:

 2) CI : oh hells yeah. My vision would be to setup something where the
 automated conversion would be triggered by commits to the stable
 branch of the java project. I think if we can construct this bit right
 we can even really get down the road of automatically running all the
 conversion options until we get it right.

Sounds good.  Back to the mundane as you said later the ASF runs a few
options for CI http://ci.apache.org/, one of them is Hudson
https://hudson.apache.org/hudson/ which has at least one Windows slave
installation (Server 2008) and is supposed to support MSBuild.  Buildbot
might work as well.

I'm not up to speed with the state of xbuild but adding support for it
to Gump (which fills quite a different role from a traditional CI)
wouldn't be too hard and give us builds on Mono - albeit 2.4 right now,
this could be changed by adding the Mono PPAs to the Ubuntu servers.

Stefan


Re: Build CI Considerations

2011-01-26 Thread Michael Herndon
Robert,

 .


I don't believe this is necessary. At least there were no requests
for alternative build systems in the past.

There may never be a need for the alternative building scripts, its was more
of a curious question. I've seen a few projects on github use both albacore
and psake. Maybe it was done in vain by the authors or possibly to attract
people from the alt.net crowd.


The Mono ecosystem is also preferring MSBuild/Visual Studio projects to
other build systems.

Are they using the xbuild or literally using msbuild and are they
completely compatible ?  I haven't kept up with how far xbuild has come
lately.  I know that mono develop and mono is still a little flakey with c#
4.0 and things like the expando object but that probably will not affect the
current lucene builds.

I believe we should rather provide our own NuGet package
than using it for external dependencies. We currently
have only one dependency: NUnit.  - Robert

So I think is in more regards to dependencies in general. This has
a possibility to increase, especially if we incorporate other libraries such
as Moq for testing, or expand lucene functionality to include linq.

Nuget isn't just for compiled assemblies but can also be used for importing
classes such as the notorious internal Guard class.

http://www.clariusconsulting.net/blogs/kzu/archive/2010/12/08/HowtocreatelightweightreusablesourcecodewithNuGet.aspx


Regarding NuGet for dependencies.. I'd say we should not do that at
this time. Primarily because, AFAIK, NuGet is an add-on for Visual
Studio which can only be used in a paid-for version of 2010. You can't
use it with the Express versions. You can't use it in MonoDevelop. So,
we'd be raising the barrier of entry to only those who have a licensed
version of Visual Studio 2010.  - Troy

Troy,

The core of Nuget itself does not actually have a ui or dependency on Visual
Studio.  While nuget's default interfaces are currently limited to
powershell or visual studio 2010, it is possible to create additional user
interfaces for it.

Its just a matter of time before there is a command line version of nuget.
 There has already been patches made to the nuget core to support mono and
there already hooks in nuget aimed at command line usage in the future.

However, another thing to pay attention to is that once the binaries are
added to the project, they become a part of the source tree.  Thus people
can still build and code without using Nuget.

While we do not need to run or rush to this right away, its something to be
considered.


CI

As far as CI is concerned, I'm not particular on any technology. Hudson or
cc.net, or insert another one here, is all fine with me. I would just like
to see one become a part of the process especially when we are looking at
using tools like Sharpen.

Build targets: Real question is what do we want to target. I do
think we can target different versions for development work versus
runtime compatibility. EG, nothing is stopping us from making the
dev/build environment VS 2010 while still targeting the 2.0 runtime.
Personally, I'd vote aiming for 3.5/VS 2010, at least for the 3.0
branch.  - Wyatt


Wyatt,

I know that its possible to load the same csproj files for both VS 2008 and
2010 (using different solutions).  These will generally load inside of Mono
Develop as well.

VS 2005 is where it gets tricky.

Another thing we should look at is making sure can compile on both the 2x
and 4x runtime.  I remember getting log4net to compile in 4x was a little
bit of work.  I am sure other would like for this to build on other versions
of the framework. I remember CF being one of those mentioned.

I don't know if the list includes Silverlight or Micro. If it does we'll
most likely need to look hard at the BCL as well as the Supported
Interfaces, core types and methods.

Possibly the Portable Tools Library could help with that in the future.
http://blogs.msdn.com/b/bclteam/archive/2011/01/19/announcing-portable-library-tools-ctp-justin-van-patten.aspx


- Michael.





Below are the responses from another thread: Proposal Status, Initial
Committors List, Contributors List




Robert Jordan,




Michael,


On 26.01.2011 19:18, Michael Herndon wrote:

 Should the project include build scripts for powershell, nant, albacore
 scripts? (would this further entice developers to download the code and
 build it)?  These also could be available as a separate download.


I don't believe this is necessary. At least there were no requests
for alternative build systems in the past.



 What would be the preferred way of working with the code base in mono ?
  Should we ensure the project loads and compiles in mono develop, etc.


The Mono ecosystem is also preferring MSBuild/Visual Studio projects
to other build systems.


would it be beneficial to add a .gitignore file for those avid git-svn
 users?


Yes, but let's do it on demand.



 should we start looking at nuget for external