orrectly.
>> >
>> > +*** {Version Ranges}
>> > +
>> > + Version Ranges used for the <> element have the following
>> > syntax (TODO only examples??):
>> > + * 1.0: "Soft" requirement on 1.0 (just a recommendation - helps
>> s
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Re-Version-ranges-and-snapshots-tp5825997p
> 5830193.html Sent from the Maven Developers mailing list archive at
> Nabble.com.
>
> ---
5.nabble.com/Re-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
requirement on 1.0
> > + * [1.2,1.3]: 1.2 <= x <= 1.3
> > + * [1.0,2.0): 1.0 <= x < 2.0
> > + * [1.5,): x >= 1.5
> > + * (,1.0],[1.2,): x <= 1.0 or x >= 1.2. Multiple sets are
> comma-separated
> > + * (,1.1),(1.1,): This excludes 1.1 if
f worm :)
> >
> > > Can anyone direct me to someone who is interested in
> > > working on this issue ?
> >
> > I can try to work on this once more: perhaps we'll manage to improve
> > something
> >
> > > For info, the docs have been
:)
>
> > Can anyone direct me to someone who is interested in
> > working on this issue ?
> I can try to work on this once more: perhaps we'll manage to improve
> something
>
> >
> > For info, the docs have been saying the following for 7+ years:
> > "grou
ement is *not* self-explanatory, 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
s are self-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 wrote:
> Hi,
> I&#x
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:
http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616&page=com.atlassian.jira.plugin
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 curre
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 b
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 a
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 Hobs
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 do
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'
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 flexi
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 u
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 CI
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 arriv
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
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
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 wan
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 des
2) You wish a dev build with all snapshots enabled so you enable a
>>> project
>>> > configured in your settings.xml that exposes you snapshot repositories
>>> > Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994
>>&g
#1
>> >
>> >
>> > If we were to fix MNG-3092 then 2 would not be possible... as you would
>> > have
>> > to go and edit all your poms to enable snapshots... i have well over
>> 100
>> > artifacts and many dependencies that exist in 40 or mo
. i have well over 100
> > artifacts and many dependencies that exist in 40 or more projects... it
> > seems
> > to be that decent continuous integration would not be possible if you fix
> > MNG-3092
> >
> > Can we start a vote for this issue here I
; Michael McCallum
> Enterprise Engineer
> mailto:[EMAIL PROTECTED]
>
> -------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAI
"..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 PROTE
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
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 wou
> 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 ev
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 f
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
--
> Michael McCallum
> Enterprise Engineer
> mailto:[EMAIL PROTECTED]
>
> ---------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this
> 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-tp11464715s177p147
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
--
M
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
> 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
> r
--
> 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.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 sn
esterday!"
>
> For stable artifacts the rate of commits/checkin to releases is close to
> 1:1.
> For developing artifacts its much higher.
>
> In any case My vote would be for maintaining the current behaviour and
> allowing an option to change it at runtime or on the comma
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
gt; >
>> >> > Mark
>> >> >
>> >> >
>> -------------
>> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > For additional commands, e-mail: [EMAIL PROTECTED]
&g
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 th
>
>> > Mark
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> --
> Michael McCallum
>
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 u
ECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14642183.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---
roducable. they depend on the current
> state of the local repository.
>
>
> regards
>
> ossi
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROT
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.
t
e could just 'assume' that when people specify version ranges
> they don't want
> snapshots and apply this change. I'm just worried about the side effects,
> since A (using snapshots
> in ranges) is possible now and B (excluding snapshots in ranges) is
> cumbersome,
>
SNAPSHOT, etc?
>
> Controlling this through snapshot repo presence/absence would be rather
> suboptimal, because you couldn't pull in a snapshot for one particular
> artifact without possibly getting unwanted snapshots for other
> dependency artifacts
t repositories
>>> at build time.
>>>
>>> Any thoughts?
>>>
>>> Mark
>>>
>>> -------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For a
Max Bowsher wrote:
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 wit
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 w
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 sn
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
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 fe
57 matches
Mail list logo
