Thanks for the detailed information. I think you have a solid grasp of
it.
It also seems we need to spend some time documenting the status of:
- the long and winding discussions about the repository format
- support for C# authored plugins via a proxy in the future (in
comparison to what was done in 0.14)
Cheers,
Brett
On 03/09/2008, at 1:44 AM, James Carpenter wrote:
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/
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
