I should probably outline my line of reasoning for this branch since Brett (and others) have expressed concern. If we look at the structure of the maven repo, we have .m2/repository/groupId/artifactId/version structure. The GAC's structure is process_architecture/artifactId/version_culture_publickey. The process architecture would typically be handled by a maven classifier. Replacing the equivalent GAC values into a maven repo structure would yield: publickey/arifactId/version/culture_process_architecture. So we have a rough equivalence here. If we are only concerned with compiling assemblies (no third-party downloaded executables, no unit tests) then using the GAC buys us exactly nothing. For the runtime, it is very different.
Currently, NMaven places all of the dependent assemblies of an executable assembly into the executable assembly's repo location (the following line of reasoning also applies for running NUnit tests). This has a few implications: First, we need to manage these copies, which can get out of date. For example, say I have assembly B dependent on assembly A. Now say, I have executable C dependent on assembly B. When I compile executable C, NMaven copies over A and B, provided they are newer than the local ones. Now if I recompile A, C does not know about it. Any application using C will also be using an out-of-date A. Of course, just replacing A, without recompiling C could be just as dangerous; but this is still a runtime issue that people need to consider. The second issue is that the current implementation doesn't have an application base structure for the executable to be able to handle running two versions of the same assembly name. Say, one part of my application needs MyAssembly.dll version 2.0 from apache. Now say that I am dependent on SF.dll, which is dependent on MyAssembly.dllversion 2.0 from sourceforge. The current NMaven implementation wouldn't know how to handle this loading. So if we look at the purpose of the repository as 1) providing compile-time artifacts; and 2) executing programs by using the artifact directory as an application base, then we have a lot more work in deciding the runtime structure. There may be grounds to say that (2) should not be a consideration, but it's a constraint that I am operating under. I also maintain that the repository structure should not be considered a public schema, it's really an implementation detail. From a technical standpoint, I think it makes a lot of sense to explore direct use of the GAC as one possible solution; I do not know whether it will pan out, so I am not going to advocate this approach without some viable prototypes. The more fundamental issue in my mind is the potential bifurcation of Maven and NMaven code since so much revolves around repo structure and its implict assumptions. Maven core seems about 80% there in terms of having a configurable API (the plugins being around 1%, although I still looking for it). I must lay out some of my feelings on this (and believe me the frustration definately does color the technical merits of what I am about to say) 1) The (failed) remote resolving of snapshot has been a pain. Up until that point, I felt that NMaven was stable, but this was the tipping point where I realized that copying and renaming of files just did not work. A simple concept destabilized the entire system. 2) I am concerned with the use of the artifact resolver (one of the most beneficial parts of the Maven API). NMaven has a lot of code wrapped around this API. Any changes from maven 2.1 onward can impact a large part of the NMaven code base, as NMaven does a lot of massaging of resolved results and dependencies. Since I am tied into the maven 2.1's MavenEmbedder (for the IDE part), I don't have a stable option to sit things out while the dust clears; and I have enough moving parts not to want to hit another (very architecturally significant) moving target in the form of the resolver. Since I am a downstream consumer of Maven - and have customer deliverables - my gut instinct is to put up a high context boundary on this one and not tie myself down any further. 3) Even though the core is configurable, Maven plugins don't work with NMaven. The most recent example was the maven-assembly-plugin: it did not recognize any of my custom artifact types (library, exe, winexe, etc) even though they were configured. This left me scrambling on a delivery, trying to build my own (buggy) assembly plugin at the last minute. At this point, I am left questioning how much does stuffing everything into the default repo format buy me. Naturally, I want to find the simplest way forward. Shane On 6/21/07, Brett Porter <[EMAIL PROTECTED]> wrote:
I admit to limited practical understanding of this, but it raises a couple of other concerns (if they are applicable): - won't this require system admin privileges? - isn't it possible some people won't want their gac touched? - can this impact other applications on the system? Cheers, Brett On 22/06/2007, at 2:10 PM, Shane Isbell wrote: > Currently, we have dual support for both GAC and maven repo > installation. > This is to experiment with just using the GAC. There are some > potential > benefits, including: 1) not needing to copy dependent assemblies into > executable addin and netplugin directories (within the repo); 2) > not needing > to copy dependent assemblies into the target directory for unit > testing; 3) > simpilfication and readability of code. The current way (1) is > handled does > not allow the application to use two different versions of the same > assembly > during execution. This may be required for assemblies with strong > names. > > Shane > > On 6/21/07, Evan Worley <[EMAIL PROTECTED]> wrote: >> >> Brett, >> >> I believe the GAC does allow multiple versions of the same artifact, >> http://en.wikipedia.org/wiki/Global_Assembly_Cache#Side-by- >> side_versioning >> >> -Evan >> >> On 6/21/07, Brett Porter < [EMAIL PROTECTED]> wrote: >> > >> > In addition to, or instead of? >> > >> > Sounds like a contradiction with Maven philosophy of being able to >> > use different versions for different applications (IIUC, the GAC >> > doesn't permit duplicates of an artifact with different versions). >> > >> > - Brett >> > >> > On 21/06/2007, at 3:55 PM, [EMAIL PROTECTED] wrote: >> > >> > > Author: sisbell >> > > Date: Wed Jun 20 22:55:03 2007 >> > > New Revision: 549393 >> > > >> > > URL: http://svn.apache.org/viewvc?view=rev&rev=549393 >> > > Log: >> > > Copy of trunk. Branch deals with experimental work with using the >> > > GAC instead of the maven repo for storing artifacts. >> > > >> > > Added: >> > > incubator/nmaven/branches/SI_GAC/ >> > > - copied from r549392, incubator/nmaven/trunk/ >> > >>
