Right. The resolver works fine and the repository layout is easy enough to change so no changes needed there. I think the idea of having a separate repository per language/platform is a good one. One reason having a separate repo is beneficial is that you can run a format converter that copies artifacts from the language/platform specific repo (say .NET) to the standard local repository. In that way, most of the standard plugins built for Java will still work. At least in .NET's case, a simple pom for meta-data will also suffice in the separate repo.
For .NET, we also need an execution area (pab) for executing of assemblies. I am wondering whether it would be a good idea to have event notification within Maven that would notify listeners when an artifact is resolved. In this way, app developers could easily deploy a resolved artifact to the GAC, to a different repo or to an artifact execution area with little development effort? This would make syncing everything easy. Shane On Nov 15, 2007 2:28 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 14 Nov 07, at 5:51 PM 14 Nov 07, James Carpenter wrote: > > > I think it is fair to argue that the current maven requirement to > > have versions in the repository artifact filenames is fundamentally > > deficient. > > I think it's the Window's linker that's fundamentally deficient no?. > Any system that will not allow you to look at an artifact and tell > exactly what is immediately is fundamentally deficient. > > > Just as .NET assemblies must maintain the same filename regardless > > of version, there are bound to be other exotic artifacts which have > > the same requirement. > > Things work fine in Java, and fine in C. > > > > > > > I would therefore recommend the DefaultArtifactResolver within maven > > simply be enhanced to make versions in the artifact names optional. > > It's controlled with a layout which has already been tried by Dan > Fabulich. It's not a problem with the resolver, it's how it's laid out > in the file system which is controlled by the ... > ArtifactRepositoryLayout. Having both systems running at the same time > would need a change, maybe a layout per language and we might even > want per language local repositories. For the C stuff that's been done > it used the standard layout. Maybe it's just local repository per > layout used. > > > I expect the maven core maintainers would willingly conceed this > > change as long as a good explanation is provided. To make this > > actually happen an NMaven developer should simply work out and > > implement the actual changes within the maven source and submit a > > patch with an explanation. I have successfully contributed maven > > patches in the past and find that any reasonable change is generally > > accepted. (See http://jira.codehaus.org/browse/MSANDBOX-23 for an > > example.) > > > > Some mechanism to enforce the current conventions for java artifacts > > should probably be put in place. As appropriate the definition of a > > type could include a filename pattern. The default pattern being > > the standard one which includes versions in the filename, with > > the .NET artifact types explicitly specifying filename patterns > > without versions. > > > > I would suggest that a given artifact type always follow a specific > > filename pattern. So java artifacts should always have version > > numbers in their filenames, and .NET artifacts should never have > > version numbers in their filenames. In typical maven spirt, > > convention should be favored over configuration. The more flexible > > the artifact repository structure becomes, the greater the > > complexity and maintenance cost. > > > > Some additional discussion of this issue can be found on a JIRA > > issue I created over a year ago, when still actively writing .NET > > code built with maven. > > http://jira.codehaus.org/browse/MSANDBOX-26 > > The JIRA proposes post-processing maven artifacts. Although this > > will work, I expect teaching the DefaultArtifactResolver to handle > > alternative artifact filename patterns (as described above) is > > likely a better choice. > > > > The implementation effort required to make these changes within the > > DefaultArtifactResolver is probably at least a few days if not a > > week or two. As I don't have this time to spend myself, I'm just > > acting as a really bad back seat driver. As I have not actively > > worked with nmaven as of late I expect I am restating the obvious at > > times, or failing to account for certain functionality that is now > > in place. It is my hope, that by the time I next work with .NET all > > of the nmaven goodness will be worked into standard maven and all > > the little kinks worked out. Its already far far better than what I > > worked with a year and a half ago. > > > > Sincerely, > > James Carpenter > > email: [EMAIL PROTECTED] > > > > On Nov 14, 2007, at 5:00 PM, Shane Isbell wrote: > > > >> Currently, NMaven supports not having versions in the file name, > >> but the > >> implementation is creating a divergence from Maven. From the > >> response here, > >> it does look as though we are going to need to continue supporting no > >> versions in the assembly file name. The issue now becomes how we do > >> it in > >> such a way as to bring the implementation more in line with Maven. > >> > >> If we do away with capabilities/requirements, we could do away with > >> RDF, but > >> we are still left with a fairly big implementation divergence. > >> Throwing out > >> some half-baked thoughts here: the copying of assembly files within > >> the same > >> repo is a nightmare to deal with, so we would still need some uac > >> concept > >> (or shadow repo) that also contains the poms and assemblies w/o > >> versions in > >> file name. If we require pom + additional meta data file, then > >> this will > >> likely be more complicated to manage than RDF. > >> > >> Shane > >> > >> On Nov 14, 2007 2:32 PM, <[EMAIL PROTECTED]> wrote: > >> > >>> I agree with James - let's?put the?versioning in the directory > >>> structure > >>> or a separate file - in the large corporate environment I work in, > >>> we've got > >>> a lot of third-party proprietary binaries that will need to be > >>> included in > >>> the repository, and recompiling is not feasible. > >>> > >>> > >>> -----Original Message----- > >>> From: James Carpenter <[EMAIL PROTECTED]> > >>> To: [email protected] > >>> Sent: Tue, 13 Nov 2007 4:33 pm > >>> Subject: Re: Technical Decisions Regarding NMaven? > >>> > >>> > >>> 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.? > >>> ? > >>> 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.)? > >>> ? > >>> Please forgive me if what I am discussing is overly obvious.? > >>> ? > >>> On Nov 12, 2007, at 3:15 PM, Shane Isbell 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? > >>> ? > >>> > >>> > >>> > ________________________________________________________________________ > >>> Email and AIM finally together. You've gotta check out free AOL > >>> Mail! - > >>> http://mail.aol.com > >>> > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > >
