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 >
