Comments in line. On 8/8/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 8 Aug 07, at 2:39 AM 8 Aug 07, Shane Isbell wrote: > > > I tend to agree: NMaven's primary target are those development > > environments > > using both .NET and Java. It is an important niche area that > > Microsoft and > > Ant are not able to address. Once we have a new API, I have no > > problems > > moving to that. The primary things I need are to be able to handle > > multiple > > classifiers, > > That we can't currently support but could be fixed. > > > not use a version in the file-name > > That can already be done, Dan Fabulich did for his .NET work. > > > and be able to support a > > separate executable application space. > > You mean running the resolver in a process outside of Maven? Why do > you need that? >
No it's not running the resolver outside of Maven. This is the private application base (pab) area, where .NET executables and their dependencies are. For instance, when NMaven downloads NMaven.Plugin.Loader.exe, it places a copy in a directory within the pab, along with its dependencies. So now there is a versioned location for executing the assembly. It's not that I would expect a resolver to do this, but rather that the use of the resolver API would not preclude it. > > The resolver also needs to be able to > > pull in multiple versions of the same artifact, as the CLR may use > > both in > > different application loaders for each version. > > What restrictions are in the resolver that prevent you from doing > that? Or you mean pulling down [a0, a1, a2] in one shot? We need to be able to pull down in one shot; but it's a little more complicated than Java. If the dependent assembly is strong-named, all versions of the same artifact (even multiple versions specified as direct dependencies) need to be brought into the dependency set. If the dependency is weak-named, then it could follow similar resolving as the Java case. There is also the need to allow the assembly provider to specify whether the resolved assembly should also be installed within the global assembly cache. I am not sure how this would fit - as a general case - in an artifact component. It would involve some meta-data (I currenty use net-dependencies.xml) and a post-resolve operation. So for .NET, we need additional meta-data: requirements/classifier(s) (Vendor/Framework Version), isSigned, isGacInstall Shane
