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 > >
