However wouldn't some of the maven functionality work out of the box if we did encode the version in the dll on the remote repo? I am thinking particularly about artifact resolution.
On 5/9/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
my point was that you don't really care how the remote repo is layout, do you? if you request a/b/c/1.0/c-1.0.dll what really interest you is to store it locally as a/b/c/1.0/c.dll right? we should focus probably in the local repo. On 5/7/07, Shane Isbell <[EMAIL PROTECTED]> wrote: > Sometime around the 21st, I'm going to merge the SI_XPT branch over to the > trunk. The merge will add two new major features to NMaven: writing Maven > plugins in .NET and building from the IDE. After that I had planned to spend > a few week iteration cycle in June doing the feature: IDE-1 - Browse Maven > Repository and add/delete dependencies. Recently, however, I am having > second thoughts about the existing repository layout that NMaven uses for > .NET artifacts; and as IDE-1 implementation is dependent on this question, I > wanted to raise the issue. I also know that Evan is looking into a solution > so the timing looks good. > > 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 -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
