I could see a problem with the second option of basing the layout on group ids. It could be the case that a developer uses the same group Id for different languages. In fact, currently, Maven .NET plugins uses the same group id for a .NET AbstractMojo instance and for the corresponding Java AbstractMojo binding instance (which is an adapter from Maven to .the NET Mojo). Still open to the idea though.
Regards, Shane On 5/9/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
about the local repo layout some possible solutions we talked about time ago were - single layout for the whole local repo configurable in the settings.xml - layout based on groupIds, maybe in the maven-metadata files? I think that the first option being simpler could be too simple. On 5/9/07, Shane Isbell <[EMAIL PROTECTED]> wrote: > 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. > > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
