I think it's a great idea to merge it over. Additionally the other only component we'd need would be the nunit-runner, and then we'd be ready to use the latest release. Does all of the snapshot depoyment and resolution work already?
Cheers, Evan On Dec 11, 2007 9:32 PM, Shane Isbell <[EMAIL PROTECTED]> wrote: > On Dec 11, 2007 9:20 PM, Brett Porter <[EMAIL PROTECTED]> wrote: > > > On 12/12/2007, at 3:36 PM, Shane Isbell wrote: > > > > > The current work in the branch only supports compiling and > > > installing of C# > > > projects for Mono and Microsoft. There are no versionless file > > > names, so > > > many of the existing maven plugins should work. All other plugins > > > are gone, > > > no resource generation, no nmaven settings, no private assembly bin, > > > no > > > Visual Studio addin, no RDF. The idea is to get a version into the > > > trunk > > > that is in line with Maven and then start adding back in the > > > functionality > > > that we need. Given that we have the current trunk to mine from, we > > > should > > > be able to go at a good pace, with frequent releases. > > > > Yep - I think I caught all that. As you know from our chat on IM > > yesterday (and probably my nagging all year :), I'm definitely in > > favour of making releases already and of getting things using what > > Maven already provides. This is the right approach. > > > > I understand that there are less plugins and features (and I'm very > > glad to see the majority of the above go). What I was really asking is > > what the migration path will be. > > > > The following are the things I want to see continue to work: > > - artifacts deployed with NMaven 0.14 should be usable by the new code > > (this should be a no brainer, as it uses the current deploy plugin > > already) > > Both NMaven 0.14-SNAPSHOT and the branch code both use the default > repository format for resolving and deploying from/to a remote repo. We > are > okay here. > > > > > - POMs for projects for NMaven 0.14 should continue working when these > > other releases go out. To that end, I suggest using a new group ID > > where there is an incompatible replacement plugin. > > > The plugin parameters change a bit since there is no capability matching, > so > most of the plugins are going to be incompatible. No problem changing the > group ids on the new plugins. > > Shane > > > > > > > Does this make sense? > > > > - Brett > > > > >
