Re: 2 issues with maven version range

[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/>