Hi,
I opened https://issues.apache.org/jira/browse/MNGSITE-300 to improve the
documentation of the version order.
Cheers,
Jon
Jon
On Mon, Mar 23, 2015 at 6:39 PM, Jon Harper wrote:
> Hi Hervé,
> thanks. I agree that the intro is now better, but I think we need to
> describe the order more preci
>
>
>
> --
> 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
Hi Hervé,
thanks. I agree that the intro is now better, but I think we need to
describe the order more precisely. The problem is that the order is quite
complex, so maybe this can be moved to another main apt page (different
than the designs docs (they are not documentation)
http://docs.codehaus.or
Hi Jon,
Thank you for your great proposal.
I fixed some formatting issues and integrated it: I think the intro is now
better
Regards,
Hervé
Le vendredi 20 mars 2015 19:28:24 Jon Harper a écrit :
> Hi Hervé,
> what do you think of the following first patch ? I haven't generated the
> correspond
Hi Hervé,
what do you think of the following first patch ? I haven't generated the
corresponding html yet, just throwing some ideas..
Regards,
Jon
Index: pom.apt
===
--- pom.apt (révision 1668105)
+++ pom.apt (copie de travai
Hi Jon,
Le dimanche 15 février 2015 21:41:52 Jon Harper a écrit :
> Hi,
> since there were no answers, I'm not sure I wrote to the correct mailing
> list for this problem.
good mailing list, but can of worm :)
> Can anyone direct me to someone who is interested in
> working on this issue ?
I can
Hi,
since there were no answers, I'm not sure I wrote to the correct mailing
list for this problem. Can anyone direct me to someone who is interested in
working on this issue ?
For info, the docs have been saying the following for 7+ years:
"groupId, artifactId, version:
These elements are self-ex
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
Mark,
I added more files to MNG-3351 (since I'm not sure what will be needed).
This issue also relates to MIDEA-84 (I don't know if you use IntelliJ or
not).
Regards,
-Dave
dhoffer wrote:
>
> Mark,
>
> That sounds wonderful. I want to help any way I can!
>
> I attached some test files to
Mark,
That sounds wonderful. I want to help any way I can!
I attached some test files to MNG-3351 today (pom and settings files). I
don't know if this is enough, if you need more just let me know I will try
to get it for you.
I stumbled across MNG-2431 recently, this fix will get this one for
I agree with David's comments. Responding to his latest comment on
MNG-3092 here to keep discussion out of JIRA:
I totally empathise with your situation David. It seems that we're
both wishing to use version ranges in the same way, the only
difference is that you've bit the bullet already wherea
I feel this is the most important bug that needs to be fixed. We make heavy
use of version ranges and without this fix they are unusable (we have to
manually apply a patch to each maven release).
"1) You wish a release build with no snapshots which is the normal behaviour
and so you just build t
"..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 th
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
Does maven-enforcer-plugin just stop a build from including a snapshot or
does it force it to find a release? You know what I mean? Is it a
after-the-fact filter or does it change the behavior of maven?
Michael McCallum-3 wrote:
>
> On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote:
>> > I
We have thought about this but since it cannot prevent local snapshots it is
not really a solution only a technique to limit the problem. BTW, we use
TeamCity for CI, builds get farmed out to many build agents so what is in
their local repo is quite random; sometimes it works sometimes it doesn't
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
"...But at the same time I would never want another department to break my
build
by deploying a snapshot I'm not ready for. "
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 val
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
"...but anything that i share with other developers has a
release version. Each of our artifacts that in active development will get
released at least once a day."
That strikes me as working against the grain of agile development. Our
developers work across components and need to link in that
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
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
that everything, in development, is always a sn
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
Which maven release/build is this in?
Based on my understanding I don't think this is sufficient to resolve this
issue. It needs to exclude 1.0.4-SNAPSHOT as well, let me try to explain.
If I specify a version range of [1.0,2.0) for a dependency, what I am saying
is that I will accept any RELEA
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
What is the status of this? This issue is very serious (highest priority)
for us; every time we update maven we have to apply a patch to fix this else
releases fail.
Can we come to some conclusion on how to fix this?
-Dave
mihobson wrote:
>
> Hi,
>
> Whilst attempting to fix MNG-2994,
...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 reposit
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
>Quote:
I think snapshots are a different aspect, outside of version ranges. Version
ranges are meant to specify a range of versions. Snapshots fit perfectly
in a version range.
>
The problem with the statement that 'snapshots fit perfectly in a version
range' is that it missing the point. You ar
You can't fix this by disallowing repos because snapshots may be in the local
repo.
Max O 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.
>>>
>>
This approach will not work because one would then have to continually
specify what snapshots to exclude. We use version ranges to specify the
range of valid released versions. I.e. when building get the latest
released version (in most all cases). What is need is to somehow disallow
all snapsh
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
56 matches
Mail list logo
