Comments in line. On 8/29/07, PeterNilsson <[EMAIL PROTECTED]> wrote: > > > Hi, > > We are using Maven for building a multi-language project with both Java, > C# > and C++. > For the C# projects we have been using NMaven since this spring. Currently > we use a version of NMaven from late spring but we trying to upgrade to > head > as we speak. > > I haven't been coding that much C# myself (more Java and Maven) though so > I > apologize if some of my comments are off target. > > Given our aim our main priority is: > > 1) NMaven should be as tightly integrated with Maven as possible.
This has been a constant issue: to what degree do we diverge from Maven and to what degree do we diverge from .NET standards? This revolves around two central issues: 1) version in the file-names (this enforces certain implied loading rules). 2) support for multiple vendors and framework versions. If we can break apart (2) and/or add tool-chain support to Maven core, then that solves half the problem. (1) is a little trickier, but I am okay with going with versions in the filenames, provided that the group, in general, accepts the limitations. It's worth it to have a separate discussion (and possible vote) on this issue. As we have a multi-language build all things that require special treatment > are a problem. > For example: > - The repository layout should be identical to Maven (I am not enough into > C# to understand the problem with having versions in dll names) The current approach is to use an entirely different repo structure that mirrors the GAC. For plugins - like the deploy and assembly plugins - that require a default repository layout, there is a repository converter that does a conversion from the GAC-style repo to the default repo. You could attach the converter to the lifecycle and then run the plugin. But again, a lot of these issues relate to (1). - Maximum reuse of existing Maven plugins. For example, I have tried using > the dependency plugin for extracting artifacts from the repository (both > Java and C#) but it fails for C# artifacts because the type coordinate > "library" is assumed to be file extension which means it won't find C# > dlls. I have encountered this problem myself. This is a bug within Maven itself, as it doesn't load the custom artifact handlers from the components.xmlfile. In certain cases, I have to do explicit loading of artifact handlers prior to plugins working. This is something we can address within Maven core and/or the respective plugins. - No local installation (except the compiler of course). NMaven should be > downloaded from remote repository as other plugins. Currently we can't > delete our local repos as we have to rerun bootstrap-build again then. The latest version in the trunk can handle downloading of release (not snapshot) versions. - Snapshot support I agree that this is important. We only target Windows for C# so Mono support is not a priority for us. > However, support for Visual Studio 2008 will become a priority very soon. > We > tried running bootstrap-build with Studio 2008 but it failed. > > Regarding generation of csproj or pom.xml we would prefer generating > csproj > from pom.xml in the same way as the eclipse plugin generates eclipse > projects. In a multi-language environment common configuration (in pom.xml > ) > is very valuable. > > To sum it up: A stable build that works as similar to Maven for Java as > possible, possibly at the expense of C# specific features, is our target. I think that this is the critical direction that we need to address. Not only do we have issue (1) above but we also need to decide whether we follow Maven standards (such as the directory structure) that don't play nicely with Visual Studio 2005. It looks as though people are adopting NMaven to support a standard build system for Java and C#; but we also have Amol's case that developers on Visual Studio need to use NMaven without modifying the pom.xml. I have a similar requirement from a customer that NMaven should be invisible as possible. This is much easier to support if we move away from or at least don't enforce Maven conventions. If we can find out how people intend to use the system, then we can make these hard decisions. Shane Peter > > -- > View this message in context: > http://www.nabble.com/Need-Some-Feedback-tf4333020.html#a12392657 > Sent from the nmaven-dev mailing list archive at > Nabble.com<http://nabble.com/> > . > >
