Re: Proposed change to handling of dependency version ranges

On Fri, 12 Dec 2008 09:59:33 Chris Maki wrote: When you say you get unstable builds you mean untested right? Because appropriate use of ranges will prevent you from assembling (war, ear, etc) artifacts that conflict. Ultimately the goal is stable software... right? In which case you want to use

Re: Proposed change to handling of dependency version ranges

On Dec 12, 2008, at 3:26 AM, Jörg Schaible wrote: Hi Ralph, Ralph Goers wrote at Freitag, 12. Dezember 2008 04:23: I agree with this. But even with managed dependencies there are still problems. Even though you have dictated the version you really have no idea if it is compatible with the

Re: Proposed change to handling of dependency version ranges

Hi Ralph, Ralph Goers wrote at Freitag, 12. Dezember 2008 04:23: > I agree with this. But even with managed dependencies there are still > problems. Even though you have dictated the version you really have no > idea if it is compatible with the version needed by the artifact > trying to use it.

Re: Proposed change to handling of dependency version ranges

2008/12/12 Ralph Goers > I agree with this. But even with managed dependencies there are still > problems. Even though you have dictated the version you really have no idea > if it is compatible with the version needed by the artifact trying to use > it. > > I have been advocating for some time t

Re: Proposed change to handling of dependency version ranges

I agree with this. But even with managed dependencies there are still problems. Even though you have dictated the version you really have no idea if it is compatible with the version needed by the artifact trying to use it. I have been advocating for some time that 3.0 support "requires" an

Re: Proposed change to handling of dependency version ranges

On Fri, Dec 12, 2008 at 7:45 AM, Stephen Connolly wrote: > H you've just given me an idea for a mojo for the > versions-maven-plugin As Stephen points out in the JIRA, the correct way is to add a dependencyManagement section. Dependencies need to be MANAGED. Someone needs to take this own

Re: Proposed change to handling of dependency version ranges

H you've just given me an idea for a mojo for the versions-maven-plugin http://jira.codehaus.org/browse/MVERSIONS-16 2008/12/11 Chris Maki > Hi Everyone > > In the spirit of full-disclosure, I work with Ian at Overstock.com, but I > wanted to chime in on this discussion because of issu

Re: Proposed change to handling of dependency version ranges

Hi Everyone In the spirit of full-disclosure, I work with Ian at Overstock.com, but I wanted to chime in on this discussion because of issues I've had with various projects. Given this scenario: com.foo:my-artifact:jar:1.0:compile org.hibernate:hibernate:3.1.1:compile com.foo:anothe

Re: Proposed change to handling of dependency version ranges

2008/12/9 Jörg Schaible <[EMAIL PROTECTED]>: > > Therefore it is always the developers task to take care of the complete > dependency tree of a product/project. > > [snip] > > - Jörg > A very big +1 ! -- Gilles Scokart - To uns

Re: Proposed change to handling of dependency version ranges

2008/12/8 Ian Robertson <[EMAIL PROTECTED]>: > On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote: >> On Thu, Dec 4, 2008 at 11:06 AM, Ian Robertson <[EMAIL PROTECTED]> wrote: >> > I would propose that the semantics change to "Of the overlapping ranges, >> > the *lowest* soft requirement is t

Re: Proposed change to handling of dependency version ranges

On Tue, 2008-12-09 at 00:25 -0700, Jörg Schaible wrote: > Hi Ian, [snip > Nothing can really keep you save from such incompatibilities and problems > anyway. You silently imply that a higher version is always compatible, but > that's also not true (you know). In really worse cases it is like the >

Re: Proposed change to handling of dependency version ranges

Hi Ian, Ian Robertson wrote at Montag, 8. Dezember 2008 20:35: > On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote: [snip] >> I think the short answer is, if you want repeatable builds then don't >> use range syntax. >> By defining a range you are saying that everything that fits in this

Re: Proposed change to handling of dependency version ranges

On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote: > On Thu, Dec 4, 2008 at 11:06 AM, Ian Robertson <[EMAIL PROTECTED]> wrote: > > I would propose that the semantics change to "Of the overlapping ranges, > > the *lowest* soft requirement is the version to be used." Consequently, > > new re

Re: Proposed change to handling of dependency version ranges

If I understand the web page correctly, if Mercury sees a dependency of 1.23, it will interpret that to mean "any version 1.23 or or greater". What I'm unable to discern from the links below is which version will actually be chosen when the versions available are, say, 1.23 and 1.24. Is there

Re: Proposed change to handling of dependency version ranges

2008/12/4 Barrie Treloar <[EMAIL PROTECTED]> > There is talk about a plugin (can't recall which) that can lock down > the version of plugins and also tell you if newer versions are > available, so you can selectively decide to upgrade. But I am not > sure if such a plugin exists yet. > > That wo

Re: Proposed change to handling of dependency version ranges

On Thu, Dec 4, 2008 at 11:06 AM, Ian Robertson <[EMAIL PROTECTED]> wrote: > I would propose that the semantics change to "Of the overlapping ranges, the > *lowest* soft requirement is the version to be used." Consequently, new > releases of a project would not change builds of other projects dep

Re: Proposed change to handling of dependency version ranges

Dear All, Jason van Zyl wrote: We cannot change the behavior, or really even attempt to fiddle with the code in 2.0.x. We are also planning on entirely replacing this code with Mercury in the 3.x line. Apache SVN is down so I'll point you to Mercury when it comes back. Oleg is the one who has

Re: Proposed change to handling of dependency version ranges

We cannot change the behavior, or really even attempt to fiddle with the code in 2.0.x. We are also planning on entirely replacing this code with Mercury in the 3.x line. Apache SVN is down so I'll point you to Mercury when it comes back. Oleg is the one who has implemented Mercury so he ca

Re: Proposed change to handling of dependency version ranges

Ian Robertson schrieb: > > I would propose that the semantics change to "Of the overlapping ranges, the > *lowest* soft requirement is the version to be used." Consequently, new > releases of a project would not change builds of other projects depending on > it (assuming that version numbers i

Proposed change to handling of dependency version ranges

I would like to propose a change to how maven handles version ranges such as [1.0,), as described in http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict