Comments below On 5/9/07, Dan Fabulich <[EMAIL PROTECTED]> wrote:
Hi Shane... I'm slightly confused by your remarks below. As I understand your email, although previously you had thought that creating a new repository layout for .NET was the best strategy, it sounds like you have changed your mind since then... specifically, you fear that integrating Archiva, the deploy plugin, the release plugin and snapshots will be way harder with a new layout. Is that right?
That's correct. If so, what do you imagine we should do instead? What work exactly
would take up to two months? The bugs linked there don't go into much detail.
Right now the plan is to have the default format on the remote repo. After NMaven resolves the artifact, it renames it, removing the version info from the artifact file name. The deploy plugin would be responsible for reversing the transformation. It has always been my position that we shouldn't have a special
*alternative* repository layout just for .NET stuff, but that the *default* repository layout for Maven should be changed. Java is unusually friendly about allowing arbitrary library names; everything else (including .NET but also others) can have much more strict naming requirements in their libraries. If the default repository layout changed, wouldn't that make things a lot easier all around? Get everybody on the same page with a repository layout that everyone can work with?
By having a remote file-system repo - regardless of the format - we are exposing the internal schema to the client. Thus, the existing format has become an implied contract. I think is the core of the problem. Clearly, the existing default layout is not Java specific, but rather JSE/JEE specific. In particular, the way that maven handles classifiers is troubling because it is inadequate for targeting mobile platforms (J2ME, .NET Compact) applications, which may have a large set of platform requirements or classifiers: consider a classifier: mono-1.2.1-framework1.1-linux-FC5-withSharpDevelop2.1-GTK and so on, as you try to enumerate the platform capabilities within the classifier. This is one reason I would prefer to move to direct use of DBs (with obvious front-end layers for the client API), where the build platform just sends it platform capabilities and the repository sends back the appropriate artifacts. NMaven handles sophisticated platform capability/requirement matching, provided that the developer is building the project locally; but for dependent artifacts that reside remotely, there is nothing other than a concept of classifier. This is a key area that I would like to address: applying capability/requirement matching to the discovery of remote artifacts. Then the question turns to: is there an adequate default local repository format that handles general cases? Here is where I would agree with you that this would be a good thing, as it would lower the entry barrier for new languages that are incompatible with the existing conventions. Shane
-Dan > -----Original Message----- > From: Shane Isbell [mailto: [EMAIL PROTECTED] > Sent: Monday, May 07, 2007 6:05 PM > To: [email protected]; [EMAIL PROTECTED] > Subject: New Remote Repo Layout for .NET Artifacts? > > Frankly, I don't care how the artifacts are stored on the server. My core > motivation in the design has been to create the simplest solution that > works > in a .NET world. Originally I was looking at this issue from a resolve > perspective, as it's quite easy to resolve the artifacts with a new repo > layout, and in fact would require much more work to do a mapping of > a standard layout to a .NET layout locally. From what I can determine now, > including features to support the the .NET layout - such as using Archiva, > the deploy plugin, the release plugin, snapshots - make it much more > complicated to support the total solution with a new layout. > > http://jira.codehaus.org/browse/NMAVEN-19 > http://jira.codehaus.org/browse/NMAVEN-43 > http://jira.codehaus.org/browse/NMAVEN-44 > http://jira.codehaus.org/browse/NMAVEN-46 > > Getting these feature implemented could take upwards of 2 months, which is > not a problem if it is the right solution; so I wanted to go ahead and > kick > off a discussion about the repo format. Does it make sense, as Carlos has > suggested, to use a database and a web service for the repo? I'm not > exactly > sure how this would work, so I will let Carlos chime in. > > Thanks, > Shane Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
