incubator-nmaven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Isbell" <shane.isb...@gmail.com>
Subject Re: Merging New Work into Trunk
Date Wed, 12 Dec 2007 17:19:59 GMT
For the resolution, we are going to need to add in artifact handlers (most
likely programmatically, unless this has been fixed within the latest
version of Maven). This is straight forward.

We will also need to recompile the NUnit source to have its version in the
filename. I think we can wait for NUnit support until version 0.15.
Shane
On Dec 12, 2007 8:59 AM, Evan Worley <evanworley@gmail.com> wrote:

> 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 <shane.isbell@gmail.com> wrote:
>
> > On Dec 11, 2007 9:20 PM, Brett Porter <brett@apache.org> 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
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message