I've implemented the solution to the problem - please see Solution to
the above problem - Quality Range in the http://docs.codehaus.org/x/twDPBQ
The solution turned to be a very nice feature to also use in the
Repository, I am exploring that option, please keep an eye on
[mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 10:02 AM
To: Maven Developers List
Subject: Re: Mercury Version Ranges
I've implemented the solution to the problem - please see Solution to
the above problem - Quality Range in the http://docs.codehaus.org/x/twDPBQ
The solution turned
Woops, sorry all. I meant to send this just to Oleg.
Still good work though.
-Original Message-
From: Clark, Gil W. [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 10:22 AM
To: Maven Developers List
Subject: RE: Mercury Version Ranges
Hi Oleg,
This is great stuff. I've
2008/8/13 Michael McCallum [EMAIL PROTECTED]:
I wish you would stop pointing that out ;-).
Hehe, forgive me if I'm repeating myself, I'm sure you're more than
aware that this discussion has been going on for quite some time in
many shapes and forms :)
I only use snapshots in local and
never
I think Oleg's suggestion here of putting the spec in the wiki makes
the most sense. I've followed the thread and I think we need to
comment on proposed behavior in one page so we can all see them. I've
already lost track in the mail thread.
On 14-Aug-08, at 2:19 AM, Mark Hobson wrote:
Jason van Zyl wrote:
I think Oleg's suggestion here of putting the spec in the wiki makes
the most sense. I've followed the thread and I think we need to
comment on proposed behavior in one page so we can all see them. I've
already lost track in the mail thread.
Guys, please use the page:
On 15/08/2008, at 12:56 AM, Oleg Gusakov wrote:
Jason van Zyl wrote:
I think Oleg's suggestion here of putting the spec in the wiki
makes the most sense. I've followed the thread and I think we need
to comment on proposed behavior in one page so we can all see them.
I've already lost
Michael McCallum wrote:
On Wed, 13 Aug 2008 17:42:17 Ralph Goers wrote:
To be honest, even with this I'd still probably not use version ranges.
But I sure would like for Maven to be able to fail the build because two
artifacts need incompatible versions of the same thing.
it does if
Hi Oleg,
2008/8/13 Oleg Gusakov [EMAIL PROTECTED]:
Working on Mercury I faced the necessity to use some standard definition of
a version range, so I took OSGi definition: OSGi core specs 4.1, page 39
in April-2007 PDF available on OSGi site - http://osgi.org.
Some interesting ramifications
1). Declaration 1.2.3 means any version X, greater or equal to 1.2.3:
1.2.3 = X. We are used to a soft version of that in Maven builds -
version can be replaced by a more applicable dependency. But spec states
ANY version: i.e. found in any scanned repository.
I'm not sure about this one.
I have to disagree here: developers should not care what repositories
they have, or what dependency plugin shows them. They should, instead,
simply say what they want - and get it. That is why, imho, the core,
including dependency resolution, should be smarter :)
I agree. The problem with
A slightly unrelated question:
Will there be support for version ranges with many parts (not just the three
parts that maven currently has) so that
[1.0.0.0.22,) will not pick up 1.0.0.0.9
-Stephen working for a company that insists on 5 number version numbers
Connolly
On Wed, Aug 13, 2008 at
Milos Kleint wrote:
no tool can substitute people and people should be in power.
This does not cast any doubt in me as well. Power to people. But people
interested to be in power.
Will
there be ways to override the smartness of the tool?
Tools have to have configurable behavior and
Mark Hobson wrote:
Hi Oleg,
2008/8/13 Oleg Gusakov [EMAIL PROTECTED]:
Working on Mercury I faced the necessity to use some standard definition of
a version range, so I took OSGi definition: OSGi core specs 4.1, page 39
in April-2007 PDF available on OSGi site - http://osgi.org.
Some
2008/8/13 Oleg Gusakov [EMAIL PROTECTED]:
Mark - this is the same if one excludes repositories and lives within
pre-existing version set: like Maven having only local repo and OSGi having
one OBR file.
If we add a variable - repositories that constantly change, then we start
wondering what
Mark Hobson wrote:
2008/8/13 Oleg Gusakov [EMAIL PROTECTED]:
Mark - this is the same if one excludes repositories and lives within
pre-existing version set: like Maven having only local repo and OSGi having
one OBR file.
If we add a variable - repositories that constantly change, then we
Stephen Connolly wrote:
A slightly unrelated question:
Will there be support for version ranges with many parts (not just the three
parts that maven currently has) so that
[1.0.0.0.22,) will not pick up 1.0.0.0.9
I picked up the VersionRange code from maven-artifact for now. Whatever
is
On Wed, 13 Aug 2008 20:52:31 Mark Hobson wrote:
For example, say I need to fix a bug in Project A 3.0 that depends on
Project B 2.0, amongst many other dependencies. I take A 3.0 and
determine that the bug is in B 2.0, so I want to update the dependency
of B in A to 2.1-SNAPSHOT. Assuming
On Thu, 14 Aug 2008 00:09:59 Brian E. Fox wrote:
I have to disagree here: developers should not care what repositories
they have, or what dependency plugin shows them. They should, instead,
simply say what they want - and get it. That is why, imho, the core,
including dependency resolution,
On Thu, 14 Aug 2008 02:03:36 Mark Hobson wrote:
2008/8/13 Oleg Gusakov [EMAIL PROTECTED]:
Mark - this is the same if one excludes repositories and lives within
pre-existing version set: like Maven having only local repo and OSGi
having one OBR file.
If we add a variable - repositories
Stephen - please see you use case addressed on
http://docs.codehaus.org/display/MAVEN/Mercury+Version+Ranges
Stephen Connolly wrote:
A slightly unrelated question:
Will there be support for version ranges with many parts (not just the three
parts that maven currently has) so that
[1.0.0.0.22
Michael McCallum wrote:
On Thu, 14 Aug 2008 00:09:59 Brian E. Fox wrote:
I have to disagree here: developers should not care what repositories
they have, or what dependency plugin shows them. They should, instead,
simply say what they want - and get it. That is why, imho, the core,
Working on Mercury I faced the necessity to use some standard definition
of a version range, so I took OSGi definition: OSGi core specs 4.1,
page 39 in April-2007 PDF available on OSGi site - http://osgi.org.
Some interesting ramifications for Maven users:
1). Declaration 1.2.3 means any
Oleg Gusakov wrote:
Working on Mercury I faced the necessity to use some standard definition
of a version range, so I took OSGi definition: OSGi core specs 4.1,
page 39 in April-2007 PDF available on OSGi site - http://osgi.org.
Some interesting ramifications for Maven users:
1). Declaration
Igor Fedorenko wrote:
Oleg Gusakov wrote:
Working on Mercury I faced the necessity to use some standard
definition of a version range, so I took OSGi definition: OSGi core
specs 4.1, page 39 in April-2007 PDF available on OSGi site -
http://osgi.org.
Some interesting ramifications for
Oleg Gusakov wrote:
What do you think about snapshots in ranges? Or - better - prohibiting
snapshot in ranges.
I don't know. In a dev environment you might want the latest, whatever
that is.
Ralph
-
To unsubscribe,
On 13/08/2008, at 10:51 AM, Oleg Gusakov wrote:
Working on Mercury I faced the necessity to use some standard
definition of a version range, so I took OSGi definition: OSGi
core specs 4.1, page 39 in April-2007 PDF available on OSGi site - http://osgi.org
.
Some interesting ramifications
On 13/08/2008, at 12:31 PM, Oleg Gusakov wrote:
Current implementation (let's call it 2.0) is promiscuous inside the
dirty dependency tree - all possible versions before conflict
resolution. But for plugins - the first plugin found wins. I would
say - we should be consistent and *treat
3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include
2.1-alpha-1, etc
Should most definitely not inlude 2.1-alpha-1 consider this scenario...
module Z released as 2.X
a dependent module Y specifies X [2,3)
you now make a breaking change and release the alpha version of Z
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and slots...
http://www.gentoo.org/
http://devmanual.gentoo.org/general-concepts/dependencies/index.html
Michael McCallum wrote:
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and slots...
http://www.gentoo.org/
http://devmanual.gentoo.org/general-concepts/dependencies/index.html
Ralph Goers wrote:
Oleg Gusakov wrote:
What do you think about snapshots in ranges? Or - better -
prohibiting snapshot in ranges.
I don't know. In a dev environment you might want the latest,
whatever that is.
For me there is a code quality boundary between release and snapshot,
and
Michael McCallum wrote:
3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include
2.1-alpha-1, etc
Should most definitely not inlude 2.1-alpha-1 consider this scenario...
module Z released as 2.X
a dependent module Y specifies X [2,3)
you now make a breaking change and
On Wed, 13 Aug 2008 16:58:37 Oleg Gusakov wrote:
2). I strongly feel that failing any explicit ranges, containing
snapshots is a good thing. For instance, dependency declaration
1.2-SNAPSHOT is a range by definition, so I'd rather fail anything like
[1.2-SNAPSHOT,2.0) or
Ralph Goers wrote:
Michael McCallum wrote:
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and
slots...
http://www.gentoo.org/
http://devmanual.gentoo.org/general-concepts/dependencies/index.html
Oleg Gusakov wrote:
Ralph Goers wrote:
Oleg Gusakov wrote:
What do you think about snapshots in ranges? Or - better -
prohibiting snapshot in ranges.
I don't know. In a dev environment you might want the latest,
whatever that is.
For me there is a code quality boundary between
On Wed, 13 Aug 2008 16:35:38 Ralph Goers wrote:
Michael McCallum wrote:
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and
slots... http://www.gentoo.org/
Michael McCallum wrote:
On Wed, 13 Aug 2008 16:58:37 Oleg Gusakov wrote:
2). I strongly feel that failing any explicit ranges, containing
snapshots is a good thing. For instance, dependency declaration
1.2-SNAPSHOT is a range by definition, so I'd rather fail anything like
Michael McCallum wrote:
On Wed, 13 Aug 2008 16:35:38 Ralph Goers wrote:
Michael McCallum wrote:
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and
slots... http://www.gentoo.org/
On Wed, Aug 13, 2008 at 7:34 AM, Oleg Gusakov
[EMAIL PROTECTED] wrote:
Michael McCallum wrote:
On Wed, 13 Aug 2008 16:58:37 Oleg Gusakov wrote:
2). I strongly feel that failing any explicit ranges, containing
snapshots is a good thing. For instance, dependency declaration
1.2-SNAPSHOT
On Wed, 13 Aug 2008 17:42:17 Ralph Goers wrote:
To be honest, even with this I'd still probably not use version ranges.
But I sure would like for Maven to be able to fail the build because two
artifacts need incompatible versions of the same thing.
it does if you use version ranges
and
I have to disagree here: developers should not care what repositories
they have, or what dependency plugin shows them. They should, instead,
simply say what they want - and get it. That is why, imho, the core,
including dependency resolution, should be smarter :)
thats like saying i
42 matches
Mail list logo
