incubator-nmaven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan Worley" <evanwor...@gmail.com>
Subject Re: Version range support
Date Wed, 19 Dec 2007 02:00:26 GMT
Do you envision range support working better in the future with the addition
of conflict resolvers (he says thinking of a talk you did on Maven 2.1)?

On Dec 18, 2007 3:01 PM, Jason van Zyl <jason@maven.org> wrote:

>
> On 18 Dec 07, at 2:49 PM 18 Dec 07, Shane Isbell wrote:
>
> > The trunk is using all of the standard Maven plumbing for resolving
> > dependencies, so version ranges are supported.
> >
>
> Only that the version range support is truly broken unfortunately. The
> code that Kenney has created in his proposal should be integrated into
> Maven proper. Ranges don't work in practice anywhere I have tried
> them. They are just unreliable. Brian Fox also has a lot of ideas as
> he's run into many problem with the dependency plugin trying to
> incorporate ranges. He just sub-classed some code to fix some issues.
>
> > Shane
> >
> > On Dec 18, 2007 12:20 PM, Evan Worley <evanworley@gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> Does the current snapshot version of NMaven support version ranges in
> >> dependencies?  I ask because our "built in-house" NMaven from a few
> >> months
> >> ago does not.
> >>
> >> Thanks,
> >> Evan
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more
> examples
> you look at, the more general your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
>
>

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