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
