I still haven't hit the problem with the level of aggression I would like to be able to devote to the effort. Surface evaluations appear to bear out my initial concerns that nothing is truly capable of everything I need without significant development effort. =========================================== NMaven is still the front-runner. I recognize this will involve creating custom plugins and bug fixes here and there. As long as I am able to contribute such enhancements back to the NMaven project and have them accepted this is much better than maintaining in-house build code (maven, ant, etc.). Showstopper Issues: * From past experience a couple years ago building C# with pre-NMaven .NET sandbox plugins as well as past discussions on this mailing list the ability for the repository to store assemblies without requiring versions in the file names (and assembly meta-data) is absolutely critical. Nothing I have read so far indicates the intent of the core nmaven developers regarding this functionality. Non-versioned assembly filenames were obviously available in the 0.14 release but no longer appears to be on the trunk. I completely agree with the decision to move the nmaven plugins in alignment with core maven, I just need to better understand the roadmap. I don't think this is a feature that can be omitted and have a workable solution. I have submitted a post to the mailing list on this issue but I am yet to receive a response. If the effort required to teach the artifact resolver/nmaven to handle an alternate repository layout for certain classes of artifacts isn't too great I would consider taking it on. I would need a few pointers though as although I have written lots of custom maven plugins I have never dug as deep into the maven internals as this may require. I also expect the nmaven developers have a better idea than I as to what needs done. I am only willing to take this on if I can get my current employee to empower me to attack it. * From a sustainability standpoint any custom plugins I build should be consistent with the 0.15+ architecture. This is to say I don't want to spend development time coding against a deprecated architecture and I realize some amount of development will indeed be necessary. Manageable Consequences of using NMaven at this stage: * I will need to create an in-house release of NMaven to provide the necessary build stability until the time an appropriate formal NMaven release is created. This is a pain but by no means a show-stopper. * I will need to live without Visual Studio support for some period of time. * I will likely have to create several report plugins. * Dependent builds in TeamCity will need to be manually configured and/or I will need to figure out how to extend TeamCity to figure it out on its own. * Selling the solution to those drinking the .NET cool-aid will be difficult. Even I would prefer an all .NET solution for building an all .NET product. * I suspect any nmaven plugins will have to be authored in Java. The ability to write .NET plugins in C# might help when trying to call .NET tooling as opposed to making system calls on executables pragmatically resolved via the artifact resolver. I haven't examined the NMaven trunk in great detail but it appears the C# plugin support is no longer available. Can C# based plugins make use of component dependencies injected by plexus? (i.e. Has some fancy/complicated cross-vm proxy mechanism been implemented?) * I will spend a great deal of time training .NET developers/build staff on how/why to use maven. =============================== The other decent choice is some combination of Ant/msbuild/Nant/Ivy with TeamCity for CI. The biggest advantage with this choice is the appearance of using technologies more familiar to .NET developers. The biggest drawback (as with any custom build system) is the resulting build scripts quickly become more complicated than simply learning a new technology which solves most of the problems out of the box. It is also probably fair to say there are less likely to be major technical complications with Ant/Nant/msbuild/Ivy which show up at the last minute as there may be with nmaven. The fact maven is capable of so much results in a great deal more complexity. Therefore when one runs into an issue which can't be addressed via configuration and/or a simple plugin things get complicated quickly. This doesn't tend to happen much in maven built Java projects as the road is pretty well paved at this point, but nmaven is still very much on the bleeding edge. The emotional response of developers to problems with familiar technologies is often much different than their response to similar issues with unfamiliar technologies. ============================== In the end, I am still left needing to build a non-trivial prototype build in both technologies in order to make a good decision.
--- On Tue, 9/2/08, Brett Porter <[EMAIL PROTECTED]> wrote: From: Brett Porter <[EMAIL PROTECTED]> Subject: Re: Questions regarding current state of C# build systems To: [email protected] Date: Tuesday, September 2, 2008, 2:36 AM Hi James, Sorry it has taken quite a while to reply, I've been behind on mail. You may have already made a decision, but it'd be great to hear what you found out. Thoughts inline... On 10/08/2008, at 9:36 AM, James Carpenter wrote: > ============================ > Questions: > > I could use some advice on the current state of C# build tooling. > > * What choices are available and how would you contrast them? I am > currently aware of NAnt, MSBuild and NMaven but have little > experience with any of them, although I am user level expert with > Ant and Maven. Are there any commercial solutions which are > currently way ahead of the above choices? I'm not aware of any other commercial solutions to this specific area myself. MSBuild is completely integrated with visual studio which is of benefit, though the available tasks I have found for it for the tools you refer to are limited. NAnt certainly has been around longer than NMaven and so is more mature and has more resources available for it. However, I believe NMaven is the closest to what you are ultimately looking for: being based on Maven you will already have the ability to run the tools you've described and use it from within any continuous integration server, and this is certainly where its objectives lay. > * Although i am convinced a maven based .NET build will potentially > one day satisfy all my requirements, I don't have a great grasp of > the status quo. Is NMaven in its current state a better solution > for a very large project than other choices? I believe NMaven would be technically capable of meeting your needs for a large project, but there are a couple of caveats. Between the stage of the project and the fact that it is incubating, it is essential to become involved in the community in some way to get the most out of it. I'd say if you have some time to put in here it will be repaid, but it does still require that investment at the moment. We currently only have one official release - 0.15. While this is much more suitable for some of your applications (since it is much more closely aligned to Maven's practices), it also lacks a lot of the features that are present in 0.14-SNAPSHOT. While we're working on (and looking for volunteers) to get involved in migrating that to the trunk now, using it now requires building an inhouse release and being involved here as you mentioned in a later question. I hope that helps clear it up. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
