Re: Technical Decisions Regarding NMaven?

[James Carpenter]

I'm not currently actively engaged in .NET development built via maven, but I did use the early pre-nmaven plugins which used to be found down in maven's SVN. While working with those I was frequently tweaking the various plugins to implement tactical fixes, recognizing a proper solution would require the major architectural changes and momentum shown by nmaven. If you look on the maven JIRA you will actually see a lot of old obsolete JIRAs I posted against them.

Please forgive me if what I am discussing is overly obvious.

On Nov 12, 2007, at 3:15 PM, Shane Isbell wrote:

While doing this work it became painfully obvious that .NET artifacts should be stored in the maven repository without versions as part of their names (or at least moved to their original filename once downloaded by the resolver). The assembly dependencies listed in the meta-data files within a strongly named (digitally signed) 3rd party .NET assembly must have the same name they were built with. When placing strongly named 3rd party dlls into my maven repo (such as Tibco), I don't get to monkey with the meta-data within them as they are digitally signed. Furthermore I don't have the source code with which to build my own. Even if I did have source, its unreasonable to require me to recompile every 3rd party library I want to use. In short, please please don't do anything which mandates a name change when placing an arbitrary 3rd party artifact into the repository. If you have not already done so, I recommend you simply teach the standard maven artifact resolver to be capable of using the repository directory structure and pom contents alone to determine version information. If you absolutely must, introduce an extra meta- data file (say version.xml) to sit alongside the pom, but please don't impose mandatory inflexible naming convention on the artifacts. (Java artifacts should continue to place the version in the filename as its really nice to have when it doesn't cause problems, but this should become optional.)

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?

uac directory.

dependency.

2) Remove support for the nmaven-settings and requirement/capability
matching?

Easier integration with Maven core.

support for new framework versions.


environment, which appears to be the general use case for NMaven.

3)  Continued support for downloading and running executables from the
repository?


integration with Maven core easier. In the first case (1), I'm all for

prove disadvantageous.


functionality, but from my observations, most people are targeting one

which solved this issue of needing to modify the pom but then I was

solution. In that case, we should consider deprecating it.


run as a Maven plugin and have all the runners, loaders download

this. However, others may find it useful. My preference would be to


Shane

Pros: Simplifies the resolving and brings it in line with Maven. No RDF, no 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 Pros: Faster start up time, due to no reading of settings file and matching. 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 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 These three decisions have to do with the reduction of functionality to make 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 The second case (2) is a little trickier because we would lose some cool 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 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 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 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 discontinue this unless someone finds this useful and intends to use it.

smime.p7s
Description: S/MIME cryptographic signature