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

Reply via email to