Where do I find the "long and winding discussions about the repository format"? Is there a mailing list thread(s) on the maven dev list I should read?
--- 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, 8:48 PM 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/
