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
2008/12/12 Ralph Goers ralph.go...@dslextreme.com
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
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.
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
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
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 chrism...@mac.com
Hi Everyone
In the spirit of full-disclosure, I work with Ian at Overstock.com, but I
wanted to chime in on this discussion
On Fri, Dec 12, 2008 at 7:45 AM, Stephen Connolly
stephen.alan.conno...@gmail.com 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.
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 and
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
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 the version to
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 unsubscribe,
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 a
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 releases of
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
range
I would like to propose a change to how maven handles version ranges such as
[1.0,), as described in
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
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
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
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 depending
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 would be
20 matches
Mail list logo
