You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by John Patrick <nh...@gmail.com> on 2019/11/24 19:46:30 UTC
2 issues with maven version range
i'm trying to start using maven version range more but having issues
with things like guava and also it not excluding version i believe
should be excluded.
1) i don't think this is possible but it might be, take a look a
google guava, it has a jre and a android version. using maven version
range how can i say any newer jre version, or any newer android
version?
https://search.maven.org/artifact/com.google.guava/guava
something like [25,) but only the jre maybe [25*-jre,)
2) i'm trying to use the version range "[4.7.0,5) "for
io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
-Dincludes=io.cucumber
https://search.maven.org/artifact/io.cucumber/cucumber-core
what do i need to change "[4.7.0,5)" to do it excludes anything starting 5?
or are other people having similar issue so gave using trying to use
maven version ranges when declaring dependencies?
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: 2 issues with maven version range
Posted by Thomas Broyer <t....@gmail.com>.
On Tue, Nov 26, 2019 at 7:17 PM Karl Heinz Marbaise <kh...@gmx.de>
wrote:
> Hi John,
>
> On 24.11.19 20:46, John Patrick wrote:
> > i'm trying to start using maven version range more but having issues
> > with things like guava and also it not excluding version i believe
> > should be excluded.
> >
> > 1) i don't think this is possible but it might be, take a look a
> > google guava, it has a jre and a android version. using maven version
> > range how can i say any newer jre version, or any newer android
> > version?
> >
> > https://search.maven.org/artifact/com.google.guava/guava
> >
> > something like [25,) but only the jre maybe [25*-jre,)
>
>
> Let us start with Guava.
>
> The issue with Guava is that they made the `-jre` part of the version
> number which is from a Maven point of view simply wrong. This should
> have been done via a clas^sifier. Because -jre, -android are specialized
> packages which are valid for only particular environments.
>
> From the documentation[1]:
> ```
> The classifier distinguishes artifacts that were built from the same POM
> but differ in content. It is some optional and arbitrary string that -
> if present - is appended to the artifact name just after the version
> number.
> As a motivation for this element, consider for example a project that
> offers an artifact targeting JRE 1.5 but at the same time also an
> artifact that still supports JRE 1.4. The first artifact could be
> equipped with the classifier jdk15 and the second one with jdk14 such
> that clients can choose which one to use.
>
> Another common use case for classifiers is to attach secondary artifacts
> to the project's main artifact. If you browse the Maven central
> repository, you will notice that the classifiers sources and javadoc are
> used to deploy the project source code and API docs along with the
> packaged class files.
> ```
> So an android package could simply be namind by using:
>
> g: com.google.guava
> a: guava
> v: 27.1
> classifier: jre
>
> etc.
> classifier: android
>
> Unfortunately they had decided to put this into the version which causes
> the issues. This in result means you can not select the version correctly.
>
Fwiw, and afaict, they did this for 2 reasons:
- android and jre flavors don't have the same dependencies (checker-qual
vs checker-compat-qual), so they can't just be differentiated by a
classifier alone, they need separate POMs, which means different GAVs or
different versions;
- you cannot declare that two GAVs conflict with each other; if they had
separate GAVs, dependencies could transitively bring both flavors, and the
only way around that (after you detect it) would be to add exclusions.
Using separate versions means that you only have one flavor at a time in
your dependency tree, and dependencyManagement can be used to pin the
version you want to actually use.
See https://github.com/google/guava/issues/2914 and
https://docs.google.com/document/d/1NYGbfz56C0Oh4IGymXjeQUVK4FcRiqDbpc4vGLnDMrY/edit?usp=sharing
(which I found out after writing the above, and didn't read in full yet)
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
Re: 2 issues with maven version range
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi John,
On 24.11.19 20:46, John Patrick wrote:
> i'm trying to start using maven version range more but having issues
> with things like guava and also it not excluding version i believe
> should be excluded.
>
> 1) i don't think this is possible but it might be, take a look a
> google guava, it has a jre and a android version. using maven version
> range how can i say any newer jre version, or any newer android
> version?
>
> https://search.maven.org/artifact/com.google.guava/guava
>
> something like [25,) but only the jre maybe [25*-jre,)
Let us start with Guava.
The issue with Guava is that they made the `-jre` part of the version
number which is from a Maven point of view simply wrong. This should
have been done via a clas^sifier. Because -jre, -android are specialized
packages which are valid for only particular environments.
From the documentation[1]:
```
The classifier distinguishes artifacts that were built from the same POM
but differ in content. It is some optional and arbitrary string that -
if present - is appended to the artifact name just after the version number.
As a motivation for this element, consider for example a project that
offers an artifact targeting JRE 1.5 but at the same time also an
artifact that still supports JRE 1.4. The first artifact could be
equipped with the classifier jdk15 and the second one with jdk14 such
that clients can choose which one to use.
Another common use case for classifiers is to attach secondary artifacts
to the project's main artifact. If you browse the Maven central
repository, you will notice that the classifiers sources and javadoc are
used to deploy the project source code and API docs along with the
packaged class files.
```
So an android package could simply be namind by using:
g: com.google.guava
a: guava
v: 27.1
classifier: jre
etc.
classifier: android
Unfortunately they had decided to put this into the version which causes
the issues. This in result means you can not select the version correctly.
[1]: https://maven.apache.org/pom.html
>
> 2) i'm trying to use the version range "[4.7.0,5) "for
> io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
> 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
> -Dincludes=io.cucumber
>
> https://search.maven.org/artifact/io.cucumber/cucumber-core
>
> what do i need to change "[4.7.0,5)" to do it excludes anything starting 5?
So next checking for version comparison:
This can be checked via command line: (from the Apache Maven installation):
$ java -jar maven-artifact-3.6.2.jar 4.7.0 5
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 4.7.0 == 4.7
4.7.0 < 5
2. 5 == 5
This will show the obvious as you already know. Now let us check
something different:
lib$ java -jar maven-artifact-3.6.2.jar 5.0.0-alpha 5.0.0
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 5.0.0-alpha == 5-alpha
5.0.0-alpha < 5.0.0
2. 5.0.0 == 5
So based on that your version range: [4,5) will include everything which
starts with "5.0.0", "5.0", or "5" this will also include "-RC??",
"-alpha" and "-SNAPSHOT" because they are less than "5", "5.0" or
"5.0.0" etc.
Furthermore I would say "5" < "5-SNAPSHOT" is from a Maven point of view
is very intuitve cause the "SNAPSHOT" is on the timeline before
releasing final release "5". (This is also true for "5.0.0" <
"5.0.0-SNAPSHOT").
To prevent having "RC"'s etc. in your range the only way is to use
"[4,4.9999999.99999)" (Yes it looks strange.) for given example
cucumber-core...
Also see the discussion on the users list:
https://lists.apache.org/thread.html/888730bd2479a9ae247e12b1f7ae6a85285feb395bdfe99c2e435a46@<users.maven.apache.org>
Unfortunately I agree that from a user point of view this should be done
better.
This could be changed for Maven 4.X but never for Maven 3.X.
In the end my opinion (and experience) is simply not to use version
ranges at all cause that could break your build without knowing why
..(I've seen that several times already)...
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: 2 issues with maven version range
Posted by Tomo Suzuki <su...@google.com.INVALID>.
> thoughts?
(I don't design or use Maven version ranges)
I agree that the behavior below, such as "5.0.0-SNAPSHOT" < "5", is not
intuitive for users.
Our team in Google recently articulated good practices of maintaining
dependencies. One of the topics is "not to use version range":
https://jlbp.dev/JLBP-14.html .
On Tue, Nov 26, 2019 at 7:09 AM Maarten Mulders <ma...@mulders.it> wrote:
> I've recently had the same line of thought...
>
> Many projects publishing "release candidates" or "milestone releases". I
> understand
> this is great for having feedback from their user base, but sometimes
> I'd rather use
> a "stable" version. Although this brings a new question to the table:
> who determines
> what is stable? In the end, it's the author(s) of those projects who
> decide that.
>
> Unfortunately, there seems not to be a default for releasing "release
> candidates"
> or "milestone releases".
>
> Cheers,
>
> Maarten
>
> On November 26, 2019 at 12:57, John Patrick wrote:
>
> > cheers for the information.
> >
> > I expect this might be asking space vs tabs, but do others feel the
> > version range of "[4,5)" should exclude anything starting 5, include
> > 5....-SNAPSHOT and any 5...-RC* or 5...-alpha
> >
> > It seams wrong to have to use "[4,4.9999999)".
> >
> > I understand from a maths point of view and from a order point of view
> > the ordering is correct but from an ease of use, end developers point
> > of view, i should just be able to use "[4,5)"
> >
> > thoughts?
> >
> > On Mon, 25 Nov 2019 at 20:40, Tomo Suzuki <su...@google.com.invalid>
> > wrote:
> > I believe your cases do not work with version ranges. Version ranges
> > depend
> > on the order of the versions, and thus you cannot filter "-guava".
> >
> > The ordering of version is defined in
> > org.eclipse.aether.util.version.GenericVersion in maven-resolver-util.
> >
> > Example code to check:
> >
> > // GenericVersionScheme is in
> > org.apache.maven.resolver:maven-resolver-util:1.3.3
> > GenericVersionScheme scheme = new GenericVersionScheme();
> > List<Version> list = new ArrayList<>();
> > list.add(scheme.parseVersion("4.7.0"));
> > list.add(scheme.parseVersion("4.99999.0"));
> > list.add(scheme.parseVersion("5"));
> > list.add(scheme.parseVersion("5.0.0"));
> > list.add(scheme.parseVersion("5.0.0-RC1"));
> > list.add(scheme.parseVersion("5.0.0-SNAPSHOT"));
> > Collections.sort(list);
> > System.out.println(list); // [4.7.0, 4.99999.0, 5.0.0-RC1,
> > 5.0.0-SNAPSHOT, 5, 5.0.0]
> >
> > So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0,
> > 4.9999999]".
> >
> > Regards,
> > Tomo
> >
> > On Sun, Nov 24, 2019 at 2:46 PM John Patrick <nh...@gmail.com>
> > wrote:
> >
> > i'm trying to start using maven version range more but having issues
> > with things like guava and also it not excluding version i believe
> > should be excluded.
> >
> > 1) i don't think this is possible but it might be, take a look a
> > google guava, it has a jre and a android version. using maven version
> > range how can i say any newer jre version, or any newer android
> > version?
> >
> > https://search.maven.org/artifact/com.google.guava/guava
> >
> > something like [25,) but only the jre maybe [25*-jre,)
> >
> > 2) i'm trying to use the version range "[4.7.0,5) "for
> > io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
> > 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
> > -Dincludes=io.cucumber
> >
> > https://search.maven.org/artifact/io.cucumber/cucumber-core
> >
> > what do i need to change "[4.7.0,5)" to do it excludes anything
> > starting 5?
> >
> > or are other people having similar issue so gave using trying to use
> > maven version ranges when declaring dependencies?
> >
> > John
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> > --
> > Regards,
> > Tomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Regards,
Tomo
Re: 2 issues with maven version range
Posted by Maarten Mulders <ma...@mulders.it>.
I've recently had the same line of thought...
Many projects publishing "release candidates" or "milestone releases". I
understand
this is great for having feedback from their user base, but sometimes
I'd rather use
a "stable" version. Although this brings a new question to the table:
who determines
what is stable? In the end, it's the author(s) of those projects who
decide that.
Unfortunately, there seems not to be a default for releasing "release
candidates"
or "milestone releases".
Cheers,
Maarten
On November 26, 2019 at 12:57, John Patrick wrote:
> cheers for the information.
>
> I expect this might be asking space vs tabs, but do others feel the
> version range of "[4,5)" should exclude anything starting 5, include
> 5....-SNAPSHOT and any 5...-RC* or 5...-alpha
>
> It seams wrong to have to use "[4,4.9999999)".
>
> I understand from a maths point of view and from a order point of view
> the ordering is correct but from an ease of use, end developers point
> of view, i should just be able to use "[4,5)"
>
> thoughts?
>
> On Mon, 25 Nov 2019 at 20:40, Tomo Suzuki <su...@google.com.invalid>
> wrote:
> I believe your cases do not work with version ranges. Version ranges
> depend
> on the order of the versions, and thus you cannot filter "-guava".
>
> The ordering of version is defined in
> org.eclipse.aether.util.version.GenericVersion in maven-resolver-util.
>
> Example code to check:
>
> // GenericVersionScheme is in
> org.apache.maven.resolver:maven-resolver-util:1.3.3
> GenericVersionScheme scheme = new GenericVersionScheme();
> List<Version> list = new ArrayList<>();
> list.add(scheme.parseVersion("4.7.0"));
> list.add(scheme.parseVersion("4.99999.0"));
> list.add(scheme.parseVersion("5"));
> list.add(scheme.parseVersion("5.0.0"));
> list.add(scheme.parseVersion("5.0.0-RC1"));
> list.add(scheme.parseVersion("5.0.0-SNAPSHOT"));
> Collections.sort(list);
> System.out.println(list); // [4.7.0, 4.99999.0, 5.0.0-RC1,
> 5.0.0-SNAPSHOT, 5, 5.0.0]
>
> So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0,
> 4.9999999]".
>
> Regards,
> Tomo
>
> On Sun, Nov 24, 2019 at 2:46 PM John Patrick <nh...@gmail.com>
> wrote:
>
> i'm trying to start using maven version range more but having issues
> with things like guava and also it not excluding version i believe
> should be excluded.
>
> 1) i don't think this is possible but it might be, take a look a
> google guava, it has a jre and a android version. using maven version
> range how can i say any newer jre version, or any newer android
> version?
>
> https://search.maven.org/artifact/com.google.guava/guava
>
> something like [25,) but only the jre maybe [25*-jre,)
>
> 2) i'm trying to use the version range "[4.7.0,5) "for
> io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
> 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
> -Dincludes=io.cucumber
>
> https://search.maven.org/artifact/io.cucumber/cucumber-core
>
> what do i need to change "[4.7.0,5)" to do it excludes anything
> starting 5?
>
> or are other people having similar issue so gave using trying to use
> maven version ranges when declaring dependencies?
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> --
> Regards,
> Tomo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: 2 issues with maven version range
Posted by John Patrick <nh...@gmail.com>.
cheers for the information.
I expect this might be asking space vs tabs, but do others feel the
version range of "[4,5)" should exclude anything starting 5, include
5....-SNAPSHOT and any 5...-RC* or 5...-alpha
It seams wrong to have to use "[4,4.9999999)".
I understand from a maths point of view and from a order point of view
the ordering is correct but from an ease of use, end developers point
of view, i should just be able to use "[4,5)"
thoughts?
On Mon, 25 Nov 2019 at 20:40, Tomo Suzuki <su...@google.com.invalid> wrote:
>
> I believe your cases do not work with version ranges. Version ranges depend
> on the order of the versions, and thus you cannot filter "-guava".
>
> The ordering of version is defined in
> org.eclipse.aether.util.version.GenericVersion in maven-resolver-util.
>
> Example code to check:
>
> // GenericVersionScheme is in
> org.apache.maven.resolver:maven-resolver-util:1.3.3
> GenericVersionScheme scheme = new GenericVersionScheme();
> List<Version> list = new ArrayList<>();
> list.add(scheme.parseVersion("4.7.0"));
> list.add(scheme.parseVersion("4.99999.0"));
> list.add(scheme.parseVersion("5"));
> list.add(scheme.parseVersion("5.0.0"));
> list.add(scheme.parseVersion("5.0.0-RC1"));
> list.add(scheme.parseVersion("5.0.0-SNAPSHOT"));
> Collections.sort(list);
> System.out.println(list); // [4.7.0, 4.99999.0, 5.0.0-RC1,
> 5.0.0-SNAPSHOT, 5, 5.0.0]
>
> So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0,
> 4.9999999]".
>
> Regards,
> Tomo
>
> On Sun, Nov 24, 2019 at 2:46 PM John Patrick <nh...@gmail.com> wrote:
>
> > i'm trying to start using maven version range more but having issues
> > with things like guava and also it not excluding version i believe
> > should be excluded.
> >
> > 1) i don't think this is possible but it might be, take a look a
> > google guava, it has a jre and a android version. using maven version
> > range how can i say any newer jre version, or any newer android
> > version?
> >
> > https://search.maven.org/artifact/com.google.guava/guava
> >
> > something like [25,) but only the jre maybe [25*-jre,)
> >
> > 2) i'm trying to use the version range "[4.7.0,5) "for
> > io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
> > 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
> > -Dincludes=io.cucumber
> >
> > https://search.maven.org/artifact/io.cucumber/cucumber-core
> >
> > what do i need to change "[4.7.0,5)" to do it excludes anything starting 5?
> >
> > or are other people having similar issue so gave using trying to use
> > maven version ranges when declaring dependencies?
> >
> > John
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> --
> Regards,
> Tomo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: 2 issues with maven version range
Posted by Tomo Suzuki <su...@google.com.INVALID>.
I believe your cases do not work with version ranges. Version ranges depend
on the order of the versions, and thus you cannot filter "-guava".
The ordering of version is defined in
org.eclipse.aether.util.version.GenericVersion in maven-resolver-util.
Example code to check:
// GenericVersionScheme is in
org.apache.maven.resolver:maven-resolver-util:1.3.3
GenericVersionScheme scheme = new GenericVersionScheme();
List<Version> list = new ArrayList<>();
list.add(scheme.parseVersion("4.7.0"));
list.add(scheme.parseVersion("4.99999.0"));
list.add(scheme.parseVersion("5"));
list.add(scheme.parseVersion("5.0.0"));
list.add(scheme.parseVersion("5.0.0-RC1"));
list.add(scheme.parseVersion("5.0.0-SNAPSHOT"));
Collections.sort(list);
System.out.println(list); // [4.7.0, 4.99999.0, 5.0.0-RC1,
5.0.0-SNAPSHOT, 5, 5.0.0]
So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0,
4.9999999]".
Regards,
Tomo
On Sun, Nov 24, 2019 at 2:46 PM John Patrick <nh...@gmail.com> wrote:
> i'm trying to start using maven version range more but having issues
> with things like guava and also it not excluding version i believe
> should be excluded.
>
> 1) i don't think this is possible but it might be, take a look a
> google guava, it has a jre and a android version. using maven version
> range how can i say any newer jre version, or any newer android
> version?
>
> https://search.maven.org/artifact/com.google.guava/guava
>
> something like [25,) but only the jre maybe [25*-jre,)
>
> 2) i'm trying to use the version range "[4.7.0,5) "for
> io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
> 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
> -Dincludes=io.cucumber
>
> https://search.maven.org/artifact/io.cucumber/cucumber-core
>
> what do i need to change "[4.7.0,5)" to do it excludes anything starting 5?
>
> or are other people having similar issue so gave using trying to use
> maven version ranges when declaring dependencies?
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Regards,
Tomo