dependency in order to work correctly.
>> >
>> > +*** {Version Ranges}
>> > +
>> > + Version Ranges used for the <> element have the following
>> > syntax (TODO only examples??):
>> > + * 1.0: "Soft" requirement on 1.0 (just a recomm
.nabble.com/Re-Version-ranges-and-snapshots-tp5825997p
5830193.html Sent from the Maven Developers mailing list archive at
Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h
-Version-ranges-and-snapshots-tp5825997p5830193.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h
, especially regarding
interactions between version ranges and *-SNAPSHOTs artifacts.
you're right: version *in dependencies* is not self explanatory
(version
in
Maven coordinates is self explanatory)
It has a lot of subtle features: preferred vs exact match, version
range
manage to improve
something
For info, the docs have been saying the following for 7+ years:
groupId, artifactId, version:
These elements are self-explanatory
The version element is *not* self-explanatory, especially regarding
interactions between version ranges
we'll manage to improve
something
For info, the docs have been saying the following for 7+ years:
groupId, artifactId, version:
These elements are self-explanatory
The version element is *not* self-explanatory, especially regarding
interactions between version ranges and *-SNAPSHOTs
-explanatory
The version element is *not* self-explanatory, especially regarding
interactions between version ranges and *-SNAPSHOTs artifacts.
Any thoughts on this matter would be appreciated.
Regards,
Jon
On Thu, Feb 5, 2015 at 5:52 PM, Jon Harper jon.harpe...@gmail.com wrote:
Hi,
I'm
version ranges and *-SNAPSHOTs artifacts.
you're right: version *in dependencies* is not self explanatory (version in
Maven coordinates is self explanatory)
It has a lot of subtle features: preferred vs exact match, version range, then
the question of SNAPSHOTS
Any thoughts on this matter would
Hi,
I'm resurrecting this old thread to ask if it's possible to change
http://maven.apache.org/pom.html to document the current implementation
behavior (7+ years old).
Please see my comment on MNG-3092:
Well ask us to do something rather than blabber on and we shut up...
I lost two managers and a developer which has chewed up all my time...
On Thu, 31 Jan 2008 02:14:59 Stephen Connolly wrote:
IMHO
I think a vote with the two positions clearly identified (perhaps with pros
and cons for both
I am only speaking in regard to MNG-3092, there are several other related
issues which I think all should be fixed
Cons
--
1) Continuous integration of trunks
I would like to be able to run the tests of all of my artifacts against a
build of trunk of every other. How I
On 29/01/2008, Michael McCallum [EMAIL PROTECTED] wrote:
How about for MNG-3092 we make it configurable per repository whether the
metadata resolution includes snapshots in ranges... you could even default to
false to keep Dave and yourself happy and I can turn it on where i need it.
I'm not
On 30/01/2008, Mark Hobson [EMAIL PROTECTED] wrote:
I don't think that linking this level of artifact resolution
uncertainty to its source repository is a good idea. How version
ranges are resolved should be completely deterministic and independent
from where the artifact was actually
IMHO
I think a vote with the two positions clearly identified (perhaps with pros
and cons for both if the pair of ye can agree on the pros and cons). (unless
somebody else has a third position)
-Stephen.
On Jan 30, 2008 12:56 PM, Mark Hobson [EMAIL PROTECTED] wrote:
On 30/01/2008, Mark Hobson
On Thu, 31 Jan 2008 01:56:09 Mark Hobson wrote:
On 30/01/2008, Mark Hobson [EMAIL PROTECTED] wrote:
I don't think that linking this level of artifact resolution
uncertainty to its source repository is a good idea. How version
ranges are resolved should be completely deterministic and
On 23/01/2008, Michael McCallum [EMAIL PROTECTED] wrote:
On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote:
There is another caveat in that it's all or nothing. Using a profile
mechanism will switch all range dependencies into snapshot mode, when
typically a developer only wishes to upgrade a
How about for MNG-3092 we make it configurable per repository whether the
metadata resolution includes snapshots in ranges... you could even default to
false to keep Dave and yourself happy and I can turn it on where i need it.
I'm not certain if its possible but would perhaps be the most
Hi Michael,
On 23/01/2008, Michael McCallum [EMAIL PROTECTED] wrote:
Firstly IMHO of MNG-3092 is that is it not the right thing for maven in
general.
I believe with MNG-2994 and appropriate use of profiles to enable and disable
snapshot repositories you can have everything that you want and
On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote:
Hi Michael,
There is another caveat in that it's all or nothing. Using a profile
mechanism will switch all range dependencies into snapshot mode, when
typically a developer only wishes to upgrade a couple. How could this
be achieved using
BTW if you want to _not_ include a snapshot on an open upper bound you can..
[1,2-!)
which will not include 1.0-SNAPSHOT, 1-SNAPSHOT
will include any version between 1 and 2 including any 1.2-SNAPSHOT or
1.4-SNAPSHOT
will not include 2.0-SNAPSHOT or 2-SNAPSHOT
On Thu, 24 Jan 2008 03:42:13 Mark
But that will bugger you up...
You are working on the version 2 branch, there is no 2.0 released, only
2.0-SNAPSHOT... you don't care as it is still new and you are happy to use
the last stable release, 1.4...
Now there is some work that is needed for the 1.4 service pack, so
1.4.1-SNAPSHOT
so you are saying that A-2.0-SNAPSHOT uses B [1,2-!) and someone deploys B
1.4.1-SNAPSHOT and that overrides B 2.0-SNAPSHOT and B 1.4 or just that it
overrides B1.4?
Depends on your use case... as to how you would deal with that. And one of the
reasons why I don't want mng-3092 because I can
(snapshots, version ranges, etc) in my pom that I need, I should not have to
do a system fix/workaround of modifying my settings.xml to get the pom to do
what it says. But even if I could do this it will not work, because it
cannot stop the build from getting snapshots from my local repo
settings.xml that exposes you snapshot repositories
Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994
first
-No, that does not work. If I have already specified what versions
(snapshots, version ranges, etc) in my pom that I need, I should not have
to
do a system fix
://jira.codehaus.org/browse/MNG-2994
first
-No, that does not work. If I have already specified what versions
(snapshots, version ranges, etc) in my pom that I need, I should not
have to
do a system fix/workaround of modifying my settings.xml to get the pom
to do
what it says. But even if I
Firstly IMHO of MNG-3092 is that is it not the right thing for maven in
general.
I believe with MNG-2994 and appropriate use of profiles to enable and disable
snapshot repositories you can have everything that you want and still
maintain the ability to allow any snapshot to be injected when
..It's crazy that version ranges are still unusable in 2.0.8..
Exactly, we really need this fixed, can we apply this patch so we can use
version ranges and snapshots. This issue is killing us.
-Dave
mihobson wrote:
On 10/01/2008, Michael McCallum [EMAIL PROTECTED] wrote:
another thought
versions
(snapshots, version ranges, etc) in my pom that I need, I should not have to
do a system fix/workaround of modifying my settings.xml to get the pom to do
what it says. But even if I could do this it will not work, because it
cannot stop the build from getting snapshots from my local repo
On 10/01/2008, Michael McCallum [EMAIL PROTECTED] wrote:
another thought...
by default you could not have snapshot repositories enabled and just enable
them with a profile...
that way all builds by default have no snapshots, you could even have separate
profiles and snapshot repos for
It's crazy that version ranges are still unusable in 2.0.8..
I disagree entirely.
I use version ranges for a very complex Project... and it works very well
* we have repeatable builds
* we can mix and match snapshots during development if we need to
* releases fail if you have snapshot deps
On Tue, 15 Jan 2008 08:43:38 Michael McCallum wrote:
It's crazy that version ranges are still unusable in 2.0.8..
* we can mix and match snapshots during development if we need to
would not appear to work, i could swear i had this working in the last year...
oh well, i can see how that would
Back to the origin of the thread
Version ranges with non-snapshot bounds can contain snapshot versions
http://jira.codehaus.org/browse/MNG-3092
I feel that the current behaviour is correct and can be managed sufficiently
by profiles. Let me render some scenarios...
1) You wish a release build
another thought...
by default you could not have snapshot repositories enabled and just enable
them with a profile...
that way all builds by default have no snapshots, you could even have separate
profiles and snapshot repos for different departments to a allow more
flexible integration
--
this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14748736.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14748696.html
Sent from the Maven Developers mailing list archive at Nabble.com
It will warn or fail the build. It's a gatekeeper not a negotiator ;-)
-Original Message-
From: dhoffer [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 10, 2008 9:49 PM
To: dev@maven.apache.org
Subject: Re: Version ranges and snapshots
Does maven-enforcer-plugin just stop a build
All fair comments. We don't release documentation for each release.
site-deploys are independent. And we have perhaps fewer people.
But at the same time I would never want another department to break my build
by deploying a snapshot I'm not ready for.
Quite possibly we could make more use of
:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14689271
IMHO, I think our approach excels in making sure this doesn't happen.
First and foremost, if this version range issue can be fixed, snapshots
will never be considered valid unless explicitly asked for. Therefore
snapshot deploys will never be a problem for me. Currently I can't even
On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote:
IMHO, I think our approach excels in making sure this doesn't happen.
First and foremost, if this version range issue can be fixed, snapshots
will never be considered valid unless explicitly asked for. Therefore
snapshot deploys will
PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14672336.html
Sent from the Maven Developers mailing list archive at Nabble.com
We just avoid that being an issue in three ways...
1) I slap anyone around who deploys a snapshot to a remote repository unless
they have a _very_ good excuse. My method is to increment the major version
if there is a breaking change and release early to avoid the need for
snapshots. Ideally
! Releases should be when you estimate you have enough 'correct'
checkins to warrant a release. It sounds like you may not be using
snapshots with version ranges simply because of this bug!?! BTW, because of
the rule that only major version changes should break the API; this is why
we really want/need
On Tue, 08 Jan 2008 14:25:06 dhoffer wrote:
Regarding 1: Well that's not normal maven operation. You apparently have
created a 'work-around' that works for you...I prefer to fix the bug so it
works as it is specified.
There are lots of reasons to deploy snapshots. Normal maven behavior is
]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14681397.html
Sent from the Maven Developers mailing list archive at Nabble.com
you can specify a range [1.0,1.1-!) which will stop 1.1-SNAPSHOT from being
included, this wont stop 1.0.4-SNAPSHOT but i think thats valid anyway...
On Sun, 06 Jan 2008 14:39:37 dhoffer wrote:
What is the status of this? This issue is very serious (highest priority)
for us; every time we
://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14642183.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
hallo
i would like to add one vote to exclude snapshots from version ranges
that do not declare them.
we encounter two problematic situations:
when using the release plugin we need to clean the local repository from
snapshots to make sure no snapshots end up in the build or any assembly
...be sure to cast your ballot for MNG-3092:)
ossi petz-2 wrote:
hallo
i would like to add one vote to exclude snapshots from version ranges
that do not declare them.
we encounter two problematic situations:
when using the release plugin we need to clean the local repository from
are technically correct; a
snapshot is a version that precedes its version number. However that is not
the point when you are specifying the version tag of a dependency. The
problem with allowing snapshots to fill version ranges unless specified in
the version range is that it is inconsistent
://www.nabble.com/Version-ranges-and-snapshots-tf4035629s177.html#a13164246
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
--
View this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tf4035629s177.html#a13164250
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL
Patrick Schneider wrote:
For now, I'm a fan of disallowing snapshots when they are not explicitly in
the boundary, as per the patch.
In my mind, the problem with a profile flag is that it's an all-or-nothing
proposition. Any released artifacts with version ranges will also start to
pull in
Kenney Westerhof wrote:
Patrick Schneider wrote:
For now, I'm a fan of disallowing snapshots when they are not
explicitly in
the boundary, as per the patch.
In my mind, the problem with a profile flag is that it's an
all-or-nothing
proposition. Any released artifacts with version
in
the version ranges,
like [1.0,2.0){snapshots=off} (or just use xml attributes ofcourse ;))
-- Kenney
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
contrary to the 2.0 design docs:
http://jira.codehaus.org/browse/MNG-3092
Brett, Kenney and myself had a brief discussion on IRC about this:
Kenney says that the behaviour is theoretically correct (which it is),
although I
For now, I'm a fan of disallowing snapshots when they are not explicitly in
the boundary, as per the patch.
In my mind, the problem with a profile flag is that it's an all-or-nothing
proposition. Any released artifacts with version ranges will also start to
pull in snapshots. There wouldn't be
57 matches
Mail list logo
