Thanks Evan. So let's go ahead and start removing options 1 and 2. I've opened a branch SI_MAVEN_INTEGRATION which will largely be used to start hacking out the unneeded code and functionality.
We will need to rebuild the plugins without the use of the NetExecutableFactory and most of the stuff that uses VendorInfo won't be needed. A good place to start is to rebuild the compile plugin. We need to support c# and vb, dump the ruby and compact profile for now. Most of the compile functionality is in the DefaultCompiler class. This initial effort deals in decoupling the plugins from the components, copying and pasting whatever functionality we need. The more we can isolate into the plugins, the easier integration with Maven will be. I'd also like to use dotnet:library, dotnet:exe and so on for the types. This way we could actually have two different compiler, testing, etc plugins without conflicting. Shane On Nov 12, 2007 5:19 PM, Evan Worley <[EMAIL PROTECTED]> wrote: > Nice analysis Shane, > > I have a few small comments. > > 1) I think including versions in fine, and for those that are using > NMaven in a dual java/.net environment, we are used to versions in > libraries, so this actually adds consistency. > > 2) I can't speak for everyone, but we are definitely targeting one > environment, so we don't mind a little extra configuration. > > 3) I see this as a nice feature, it also allows us to resolve things > like the NUnit runner, config, etc. I don't see much difference > between deploying and resolving a dll vs deploying and resolving an > exe, it's just a different packaging in the same platform. Unless I > am missing something, I would vote to keep this feature. Now if all > the required executables are to be deployed as an "Nmaven install", > then I might not see a need to keep this feature around. Then we > would not need to resolve Nunit, ResX, etc. > > -Evan > > On Nov 12, 2007 1:15 PM, Shane Isbell <[EMAIL PROTECTED]> wrote: > > We do need to come to some technical decisions regarding the direction > of > > NMaven. I've taken a hard look at what are the most difficult parts to > bring > > in line with Maven core and hope to get some feedback and a decision on > how > > we want to approach it. > > > > 1) Including the versions in the file name? > > Pros: Simplifies the resolving and brings it in line with Maven. No RDF, > no > > uac directory. > > Cons: Forces assembly loading equivalent to strong naming. This means > that > > you need to recompile the whole assembly chain when making a change in a > > dependency. > > > > 2) Remove support for the nmaven-settings and requirement/capability > > matching? > > Pros: Faster start up time, due to no reading of settings file and > matching. > > Easier integration with Maven core. > > Cons: No longer can change the framework versions/vendors of builds > through > > an external settings file, but rather need to manually configure the > paths > > to framework versions and vendors. More manually coding required when > adding > > support for new framework versions. > > > > The nmaven-settings is particularly good for testing applications > against > > multiple build environments and makes it much easier to add support for > new > > framework versions, but not so useful for environments that target a > single > > environment, which appears to be the general use case for NMaven. > > > > 3) Continued support for downloading and running executables from the > > repository? > > > > These three decisions have to do with the reduction of functionality to > make > > integration with Maven core easier. In the first case (1), I'm all for > > including versions in the file-name as I now think that strong naming > should > > be required of all open-source projects, but I am not certain if there > are > > any individual cases (particularly on corporate projects) where this may > > prove disadvantageous. > > > > The second case (2) is a little trickier because we would lose some cool > > functionality, but from my observations, most people are targeting one > > environment anyway, so they may not mind a little extra configuration. > My > > vision for the requirements/capabilities concept requires eventually > having > > requirement concepts within the pom.xml file. I moved toward the RDF > concept > > which solved this issue of needing to modify the pom but then I was > > confronted with all the repository work (Archiva, etc) that would be > needed > > to eventually support RDF, as well as the concerns with moving away from > the > > core Maven implementation. So if (1) goes away, (2) promises only half a > > solution. In that case, we should consider deprecating it. > > > > The third case (3) deals with being able to deploy an executable, its > conf > > file and dependencies into a repo and then be able to resolve and run > that > > exe during a build. In some ways, this is really there to allow NMaven > to > > run as a Maven plugin and have all the runners, loaders download > > automatically and be part of the life-cycle. I think eventually > everything > > will be deployed within Maven core (or through an MSI or other > installer), > > so there will not be a direct need from NMaven's perspective to support > > this. However, others may find it useful. My preference would be to > > discontinue this unless someone finds this useful and intends to use it. > > > > Shane > > >
