Version ranges: bug or feature

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Version ranges: bug or feature

Maxim Solodovnik
Hello Maven experts,

one sub-dependencies of our project has following
  <version>[6.7.0,7.0.0-SNAPSHOT)</version>
[1]

as a result metadata for all available SNAPSHOT version is being checked in
all SNAPSHOT repositories
this takes time
(full story is here https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)

this is reproducible using both local build and build at
ci-builds.apache.org

Is this expected behavior?
Is it Ok to use range dependency with SNAPSHOT in release version of
library?



[1]
https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api-elements-6.15.0.pom

--
Best regards,
Maxim
Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Tomo Suzuki
I avoid using version ranges because it introduces unexpected results in
the dependency graphs.

> [6.7.0,7.0.0-SNAPSHOT)

I felt the intention of the range is the highest version before
7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version).
As per [1], this range includes versions such as "7.0.0-alpha" and
"7.0.0-rc".

[1]:
https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
,



On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik <[hidden email]>
wrote:

> Hello Maven experts,
>
> one sub-dependencies of our project has following
>   <version>[6.7.0,7.0.0-SNAPSHOT)</version>
> [1]
>
> as a result metadata for all available SNAPSHOT version is being checked in
> all SNAPSHOT repositories
> this takes time
> (full story is here https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)
>
> this is reproducible using both local build and build at
> ci-builds.apache.org
>
> Is this expected behavior?
> Is it Ok to use range dependency with SNAPSHOT in release version of
> library?
>
>
>
> [1]
>
> https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api-elements-6.15.0.pom
>
> --
> Best regards,
> Maxim
>


--
Regards,
Tomo
Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Maxim Solodovnik
Thanks for the quick answer Tomo,

According to out build logs (available for ex. here [1])
`7.0.0-SNAPSHOT` in the range results in checking all snapshot versions in
all snapshot repositories available

so 6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT, 6.7.3-SNAPSHOT etc are being checked ...
Is this expected

https://ci-builds.apache.org/job/OpenMeetings/job/openmeetings/133/consoleFull



On Tue, 10 Nov 2020 at 21:49, Tomo Suzuki <[hidden email]>
wrote:

> I avoid using version ranges because it introduces unexpected results in
> the dependency graphs.
>
> > [6.7.0,7.0.0-SNAPSHOT)
>
> I felt the intention of the range is the highest version before
> 7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version).
> As per [1], this range includes versions such as "7.0.0-alpha" and
> "7.0.0-rc".
>
> [1]:
>
> https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
> ,
>
>
>
> On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik <[hidden email]>
> wrote:
>
> > Hello Maven experts,
> >
> > one sub-dependencies of our project has following
> >   <version>[6.7.0,7.0.0-SNAPSHOT)</version>
> > [1]
> >
> > as a result metadata for all available SNAPSHOT version is being checked
> in
> > all SNAPSHOT repositories
> > this takes time
> > (full story is here https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)
> >
> > this is reproducible using both local build and build at
> > ci-builds.apache.org
> >
> > Is this expected behavior?
> > Is it Ok to use range dependency with SNAPSHOT in release version of
> > library?
> >
> >
> >
> > [1]
> >
> >
> https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api-elements-6.15.0.pom
> >
> > --
> > Best regards,
> > Maxim
> >
>
>
> --
> Regards,
> Tomo
>


--
Best regards,
Maxim
Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Tomo Suzuki
I expect Maven to check all possible versions that match the range criteria
and to pick the highest one. (Sorry if I might not grasp your question)

The suffixes (-SNAPSHOT) in version ranges do not work as a filter.
(Probably this is not the point?)

The mentioned version strings (6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT and
6.7.3-SNAPSHOT) are all higher than “6.7.0” and lower than “7.0.0-SNAPSHOT“.


On Tue, Nov 10, 2020 at 10:34 Maxim Solodovnik <[hidden email]> wrote:

> Thanks for the quick answer Tomo,
>
> According to out build logs (available for ex. here [1])
> `7.0.0-SNAPSHOT` in the range results in checking all snapshot versions in
> all snapshot repositories available
>
> so 6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT, 6.7.3-SNAPSHOT etc are being checked ...
> Is this expected
>
>
> https://ci-builds.apache.org/job/OpenMeetings/job/openmeetings/133/consoleFull
>
>
>
> On Tue, 10 Nov 2020 at 21:49, Tomo Suzuki <[hidden email]>
> wrote:
>
> > I avoid using version ranges because it introduces unexpected results in
> > the dependency graphs.
> >
> > > [6.7.0,7.0.0-SNAPSHOT)
> >
> > I felt the intention of the range is the highest version before
> > 7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version).
> > As per [1], this range includes versions such as "7.0.0-alpha" and
> > "7.0.0-rc".
> >
> > [1]:
> >
> >
> https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
> > ,
> >
> >
> >
> > On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik <[hidden email]>
> > wrote:
> >
> > > Hello Maven experts,
> > >
> > > one sub-dependencies of our project has following
> > >   <version>[6.7.0,7.0.0-SNAPSHOT)</version>
> > > [1]
> > >
> > > as a result metadata for all available SNAPSHOT version is being
> checked
> > in
> > > all SNAPSHOT repositories
> > > this takes time
> > > (full story is here https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)
> > >
> > > this is reproducible using both local build and build at
> > > ci-builds.apache.org
> > >
> > > Is this expected behavior?
> > > Is it Ok to use range dependency with SNAPSHOT in release version of
> > > library?
> > >
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api-elements-6.15.0.pom
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
> >
> >
> > --
> > Regards,
> > Tomo
> >
>
>
> --
> Best regards,
> Maxim
>
--
Regards,
Tomo
Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Maxim Solodovnik
So ranges can't be used in release artifacts?

I thought maybe `SNAPSHOT` in range will turn on some Maven magic
and it will check snapshots in addition to releases ...

On Wed, 11 Nov 2020 at 06:29, Tomo Suzuki <[hidden email]>
wrote:

> I expect Maven to check all possible versions that match the range criteria
> and to pick the highest one. (Sorry if I might not grasp your question)
>
> The suffixes (-SNAPSHOT) in version ranges do not work as a filter.
> (Probably this is not the point?)
>
> The mentioned version strings (6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT and
> 6.7.3-SNAPSHOT) are all higher than “6.7.0” and lower than
> “7.0.0-SNAPSHOT“.
>
>
> On Tue, Nov 10, 2020 at 10:34 Maxim Solodovnik <[hidden email]>
> wrote:
>
> > Thanks for the quick answer Tomo,
> >
> > According to out build logs (available for ex. here [1])
> > `7.0.0-SNAPSHOT` in the range results in checking all snapshot versions
> in
> > all snapshot repositories available
> >
> > so 6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT, 6.7.3-SNAPSHOT etc are being checked
> ...
> > Is this expected
> >
> >
> >
> https://ci-builds.apache.org/job/OpenMeetings/job/openmeetings/133/consoleFull
> >
> >
> >
> > On Tue, 10 Nov 2020 at 21:49, Tomo Suzuki <[hidden email]>
> > wrote:
> >
> > > I avoid using version ranges because it introduces unexpected results
> in
> > > the dependency graphs.
> > >
> > > > [6.7.0,7.0.0-SNAPSHOT)
> > >
> > > I felt the intention of the range is the highest version before
> > > 7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version).
> > > As per [1], this range includes versions such as "7.0.0-alpha" and
> > > "7.0.0-rc".
> > >
> > > [1]:
> > >
> > >
> >
> https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
> > > ,
> > >
> > >
> > >
> > > On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik <[hidden email]
> >
> > > wrote:
> > >
> > > > Hello Maven experts,
> > > >
> > > > one sub-dependencies of our project has following
> > > >   <version>[6.7.0,7.0.0-SNAPSHOT)</version>
> > > > [1]
> > > >
> > > > as a result metadata for all available SNAPSHOT version is being
> > checked
> > > in
> > > > all SNAPSHOT repositories
> > > > this takes time
> > > > (full story is here
> https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)
> > > >
> > > > this is reproducible using both local build and build at
> > > > ci-builds.apache.org
> > > >
> > > > Is this expected behavior?
> > > > Is it Ok to use range dependency with SNAPSHOT in release version of
> > > > library?
> > > >
> > > >
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api-elements-6.15.0.pom
> > > >
> > > > --
> > > > Best regards,
> > > > Maxim
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Tomo
> > >
> >
> >
> > --
> > Best regards,
> > Maxim
> >
> --
> Regards,
> Tomo
>


--
Best regards,
Maxim
Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

John Patrick
Ranges can be used in released artifacts which I have done myself, but
it means you won't have reproducible builds. So be careful and be
aware if you use them...

From your version range I assume you want any v6.7.x and newer but not
any v7.x release. So I would have done
<version>[6.7.0,6.999.999)</version>

I have used open source projects that got it wrong, so my project
worked for a few years then started due to a dependency getting ranges
wrong. So I was depending upon a v4.0.x implementation, then a v4.x.1
release was made and the v4.0.x implementation picked up the v4.1.x
api and they were not compatible so build failures.

To get around the speed if using version ranges etc... I have;
- stopped deploying snapshots into repositories
- each build workspace gets its own local repository
- if a project has dependencies, and the dependency has a branch of
the same name then it is built 1st so that SNAPSHOT version in the
workspace local repository. this save needing to deploy snapshots and
also needing to do extra releases

John

On Wed, 11 Nov 2020 at 00:06, Maxim Solodovnik <[hidden email]> wrote:

>
> So ranges can't be used in release artifacts?
>
> I thought maybe `SNAPSHOT` in range will turn on some Maven magic
> and it will check snapshots in addition to releases ...
>
> On Wed, 11 Nov 2020 at 06:29, Tomo Suzuki <[hidden email]>
> wrote:
>
> > I expect Maven to check all possible versions that match the range criteria
> > and to pick the highest one. (Sorry if I might not grasp your question)
> >
> > The suffixes (-SNAPSHOT) in version ranges do not work as a filter.
> > (Probably this is not the point?)
> >
> > The mentioned version strings (6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT and
> > 6.7.3-SNAPSHOT) are all higher than “6.7.0” and lower than
> > “7.0.0-SNAPSHOT“.
> >
> >
> > On Tue, Nov 10, 2020 at 10:34 Maxim Solodovnik <[hidden email]>
> > wrote:
> >
> > > Thanks for the quick answer Tomo,
> > >
> > > According to out build logs (available for ex. here [1])
> > > `7.0.0-SNAPSHOT` in the range results in checking all snapshot versions
> > in
> > > all snapshot repositories available
> > >
> > > so 6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT, 6.7.3-SNAPSHOT etc are being checked
> > ...
> > > Is this expected
> > >
> > >
> > >
> > https://ci-builds.apache.org/job/OpenMeetings/job/openmeetings/133/consoleFull
> > >
> > >
> > >
> > > On Tue, 10 Nov 2020 at 21:49, Tomo Suzuki <[hidden email]>
> > > wrote:
> > >
> > > > I avoid using version ranges because it introduces unexpected results
> > in
> > > > the dependency graphs.
> > > >
> > > > > [6.7.0,7.0.0-SNAPSHOT)
> > > >
> > > > I felt the intention of the range is the highest version before
> > > > 7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version).
> > > > As per [1], this range includes versions such as "7.0.0-alpha" and
> > > > "7.0.0-rc".
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> > https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
> > > > ,
> > > >
> > > >
> > > >
> > > > On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik <[hidden email]
> > >
> > > > wrote:
> > > >
> > > > > Hello Maven experts,
> > > > >
> > > > > one sub-dependencies of our project has following
> > > > >   <version>[6.7.0,7.0.0-SNAPSHOT)</version>
> > > > > [1]
> > > > >
> > > > > as a result metadata for all available SNAPSHOT version is being
> > > checked
> > > > in
> > > > > all SNAPSHOT repositories
> > > > > this takes time
> > > > > (full story is here
> > https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)
> > > > >
> > > > > this is reproducible using both local build and build at
> > > > > ci-builds.apache.org
> > > > >
> > > > > Is this expected behavior?
> > > > > Is it Ok to use range dependency with SNAPSHOT in release version of
> > > > > library?
> > > > >
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> > https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api-elements-6.15.0.pom
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Maxim
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Tomo
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
> > --
> > Regards,
> > Tomo
> >
>
>
> --
> Best regards,
> Maxim

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Hervé BOUTEMY
In reply to this post by Maxim Solodovnik
as Tomo said:
1. version ranges make dependencies selection unstable: is it really
necessary? (I personnally never use because of the build instability it adds,
given I'm trying to go even beyond stable build: I'm working hard on
Reproducible Builds [1]. Then my experience on detailed behaviour of such
configuration is limited, sorry...)

2. this range includes versions such as "7.0.0-alpha" and "7.0.0-rc": from my
experience on working on code for version comparison and version range, I
imagine that when people write [..., 7.0.0-SNAPSHOT), what they really intent
is to avoid even 7.0.0-alpha, beta, rc, then they should probably better write
[..., 7.0.0-alpha-alpha)
I know this is not fully intuitive.
I remember some old discussions on defining some more precise semantics for
version ranges, both for effective vs declared limits and SNAPSHOT inclusion of
not, but IIRC this never went to an implementation
My thoughts at that time is that Maven currently implements version ranges as
pure mathematical range, where what people expect is not really math but
something that will match an intent.

Changes on version range use cases and semantic evolution are hard, we need to
define what are the different intents, then how to express them, then implement,
and avoid that Central Repository contains unusable libraries when we update
version range semantics (= what we are currently tackling with Maven 3.7 work
in progress): I know there are MNG issues and perhaps MRESOLVER ones, perhaps
Wiki. Summarising links would already be a hard job...

Hope this helps

Regards,

Hervé

[1] https://issues.apache.org/jira/secure/ViewProfile.jspa?name=abrarovm

Le mardi 10 novembre 2020, 16:34:21 CET Maxim Solodovnik a écrit :

> Thanks for the quick answer Tomo,
>
> According to out build logs (available for ex. here [1])
> `7.0.0-SNAPSHOT` in the range results in checking all snapshot versions in
> all snapshot repositories available
>
> so 6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT, 6.7.3-SNAPSHOT etc are being checked ...
> Is this expected
>
> https://ci-builds.apache.org/job/OpenMeetings/job/openmeetings/133/consoleFu
> ll
>
>
>
> On Tue, 10 Nov 2020 at 21:49, Tomo Suzuki <[hidden email]>
>
> wrote:
> > I avoid using version ranges because it introduces unexpected results in
> > the dependency graphs.
> >
> > > [6.7.0,7.0.0-SNAPSHOT)
> >
> > I felt the intention of the range is the highest version before
> > 7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version).
> > As per [1], this range includes versions such as "7.0.0-alpha" and
> > "7.0.0-rc".
> >
> > [1]:
> >
> > https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven
> > /artifact/versioning/ComparableVersion.html ,
> >
> >
> >
> > On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik <[hidden email]>
> >
> > wrote:
> > > Hello Maven experts,
> > >
> > > one sub-dependencies of our project has following
> > >
> > >   <version>[6.7.0,7.0.0-SNAPSHOT)</version>
> > >
> > > [1]
> > >
> > > as a result metadata for all available SNAPSHOT version is being checked
> >
> > in
> >
> > > all SNAPSHOT repositories
> > > this takes time
> > > (full story is here https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)
> > >
> > > this is reproducible using both local build and build at
> > > ci-builds.apache.org
> > >
> > > Is this expected behavior?
> > > Is it Ok to use range dependency with SNAPSHOT in release version of
> > > library?
> > >
> > >
> > >
> > > [1]
> >
> > https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api
> > -elements-6.15.0.pom>
> > > --
> > > Best regards,
> > > Maxim
> >
> > --
> > Regards,
> > Tomo





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Florian Schmaus
In reply to this post by Maxim Solodovnik
On 11/10/20 2:54 PM, Maxim Solodovnik wrote:
> Hello Maven experts,
>
> one sub-dependencies of our project has following
>    <version>[6.7.0,7.0.0-SNAPSHOT)</version>

I think you may want to use

[6.7.0, 6.9999.9999)

instead.

- Florian

OpenPGP_0x8CAC2A9678548E35.asc (18K) Download Attachment
OpenPGP_signature (505 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Maxim Solodovnik
Thanks for your answers

Unfortunately I feel the main question remains unanswered :(
I'll try to re-phrase it:

Is it possible to specify the range in a way it will check release versions
only

So if [1.0.0, 10.0.0) is specified

2.1.0-SNAPSHOT, 3.1.1-SNAPSHOT, etc. will NOT be checked?

by checking I mean downloading metadata every day etc.


On Wed, 11 Nov 2020 at 17:47, Florian Schmaus <[hidden email]> wrote:

> On 11/10/20 2:54 PM, Maxim Solodovnik wrote:
> > Hello Maven experts,
> >
> > one sub-dependencies of our project has following
> >    <version>[6.7.0,7.0.0-SNAPSHOT)</version>
>
> I think you may want to use
>
> [6.7.0, 6.9999.9999)
>
> instead.
>
> - Florian
>


--
Best regards,
Maxim
Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Florian Schmaus
On 11/11/20 2:47 PM, Maxim Solodovnik wrote:

> Thanks for your answers
>
> Unfortunately I feel the main question remains unanswered :(
> I'll try to re-phrase it:
>
> Is it possible to specify the range in a way it will check release versions
> only
>
> So if [1.0.0, 10.0.0) is specified
>
> 2.1.0-SNAPSHOT, 3.1.1-SNAPSHOT, etc. will NOT be checked?
>
> by checking I mean downloading metadata every day etc.
I am not aware that this is possible.

See
https://maven.apache.org/pom.html#dependency-version-requirement-specification

- Florian

OpenPGP_0x8CAC2A9678548E35.asc (18K) Download Attachment
OpenPGP_signature (505 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version ranges: bug or feature

Mark Prins
In reply to this post by Maxim Solodovnik
You may be able to configure/improve this by setting up your
repositories (eg the updatePolicy and type of artifacts) see
https://maven.apache.org/pom.html#repositories

-M



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]