We would have to raise the issue of how long it would take for the tool chain support on the general maven dev list (although Jason may have some idea). An alternative approach would be to breakout and generalize the dotnet-executable and dotnet-vendor components to handle J2ME and J2SE compilers and executables. The dotnet-vendor is a state machine that fills in missing vendor info (vendor name, vendor version, framework version) and finds executable paths, etc. Many of the APIs would work for Java but it would need a different state-machine implementation. This state-machine implementation would need to be pluggable.
The dotnet-executable is fairly generalized at a low level (meaning the conf files and lower-level constructs should not need a lot of changes); but the API itself is .NET specific so there would be a lot of changes at this level. All in all, if you have a descent grasp of the code its about 3-4 man weeks of work. To get this integrated into Maven core, I couldn't say at this point. We'd need to look into that by creating a simple prototype. To understand more on how this works: http://incubator.apache.org/nmaven/environment-configuration.html http://incubator.apache.org/nmaven/adding-executables.html Shane On 8/27/07, David Lewis <[EMAIL PROTECTED]> wrote: > > > We're developing Java and .NET components for both Window and > Linux. We're > not currently using NMaven for the .NET components, but we'd like to > convert > them to use it in the near future. We would need support for Mono to do > this. If you were to yank out support, how long do you think it would > take > to work it back in? I think there are a couple of us in my group that > would > be willing to contribute if that would > help speed it along. > > --David > > > Shane Isbell wrote: > > > > Thanks Amol and Evan. It sounds as though most of the current users of > > NMaven 1) have dual Java/.NET environments and 2) are using > > Microsoft/Visual Studio (not Mono). With (1), the divergence of Maven > and > > NMaven is a problem. In regards to (2), I am wondering if Mono support > > should be required at this point. Multi-vendor support is a big part of > > the > > code base complexity and makes integrating into Maven core problematic. > We > > may be able to remove that support and then work it back in within the > > context of the current tool chain work being done within Maven core. Is > > anybody on the list using Mono or planning on using Mono with NMaven? > > > > Shane > > > > > > On 8/27/07, Amol Manjure <[EMAIL PROTECTED]> wrote: > >> > >> I work on a project that has .NET and Java components and Maven and > >> NMaven seem like a great way to combine the automated build process. > >> > >> However, the biggest issue I face is that most of the .NET developers > >> use Visual Studio to write code and run builds on their machines. A > >> lot of our build steps are built into the csproj files. We use Visual > >> Studio plugins to generate some of our code. > >> > >> These issues need to be addressed in NMaven. The dynamic code > >> generation can be worked around by checking in generated files but the > >> post build steps and other aspects of the .NET project have to be > >> manually sync'ed. > >> > >> My first feature request would be being able to support csproj files > >> in some way without requiring someone to maintain the POM. This could > >> be done by parsing the csproj and generating a POM that provides the > >> same functionality or any other means that is appropriate. I am aware > >> of the feature whereby we can generate the csproj based on the POM but > >> that is not the normal use case for a developer who starts with a > >> csproj and wants a POM to reflect it. > >> > >> Amol > >> > >> On 8/27/07, Evan Worley <[EMAIL PROTECTED]> wrote: > >> > I think the mailing list is slow in general because there is really > >> only > >> one > >> > core developer, and I don't see the benefit in you having design > >> discussions > >> > with yourself :). If we can get more contributors involved, I think > >> the > >> > discussions will flow naturally. I continue to try to find time to > get > >> > acquainted, but I find I can rarely keep up. Now that things are > >> becoming > >> > more stable...?, it might be temping for people to get involved. > >> > > >> > I am personally very interested in seeing how the maven core can > >> supports > >> > .NET components. One great starting point would be implementing a > >> surefire > >> > provider for nunit, a task that his been proven difficult or at least > >> > non-intuitive given the current surefire implementation. > >> > > >> > My 2 cents, > >> > Evan > >> > > >> > On 8/26/07, Shane Isbell <[EMAIL PROTECTED]> wrote: > >> > > > >> > > I noticed the discussion on the mailing list has been a bit slow > >> lately, > >> > > even with the prospect of doing a release. Initially I had hopes to > >> get to > >> > > graduation within 12 months, but I realize from a community > >> perspective we > >> > > have a long way to go. So I wanted to get some feedback from > >> everybody > >> in > >> > > terms of what they think we can do to improve the situation. > >> > > > >> > > I'm perfectly open to going back to the drawing board on any major > >> issues. > >> > > I had hoped that the architecture for doing .NET plugins would > bring > >> in > >> > > .NET > >> > > developers, but I don't see this happening. The platform matching > is > >> a > >> > > pretty big chunk of code that the community may not find > interesting, > >> so I > >> > > need to find out whether this should still be supported. RDF has, > at > >> best, > >> > > gotten lukewarm acceptance. Finally, we have the big issue of how > to > >> bring > >> > > .NET support into Maven itself. > >> > > > >> > > Should we just start compiling a list of features and decide > whether > >> we > >> > > need > >> > > them and then open up the design? > >> > > > >> > > Shane > >> > > > >> > > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Need-Some-Feedback-tf4333020.html#a12356780 > Sent from the nmaven-dev mailing list archive at Nabble.com. > >
