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&#x
eg Gusakov [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
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
http://docs.codehaus
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 tr
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: ht
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:
20
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
> nev
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,
includin
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,
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 - re
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 resolut
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
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 t
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
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
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 i
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 def
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
>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
>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.
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 ramific
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 yo
> >
> > 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 sayi
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
an
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
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/
http://devmanua
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
[1.2-SNAPSHOT,2.
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/
> > http://devmanual.gentoo.org/gene
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 re
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
http
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 [1.0,1
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 release
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,
an
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
http://devmanual.gentoo.org/
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
http://devmanual.gentoo.org/general-concepts/slotting/in
> 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 3.0-al
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 p
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 ramification
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,
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 Ma
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). Declaratio
41 matches
Mail list logo
