--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/d84e3c96-039d-4cab-ade0-417e3762ba0en%40googlegroups.com.
I see what you are saying from the perspective of compiling my library, but what I am more interested in (sorry for not making this clear) is how the library is documented in a repository such as Maven Central. In that context, my library needs guava-jre or guava-android, but I don't think there is any way to say that in the POM.
Ideally, Guava could also publish Gradle Metadata so Gradle could automatically detect that both versions are variants of the same, and Gradle could possibly automatically upgrade a guava-android dependency to guava-jre when targeting JDK 8+.
--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/821a2261-2d72-4ba6-aa70-7342c069b42bo%40googlegroups.com.
I'm guessing that the fact that the APIs of the two variants are not identical is why the option of a separate API artifact was not considered and explicitly rejected in your otherwise thorough design document.
Actually, I would test my library on both JRE and Android, so neither variant is unexpected as long as the version number matches.Unfortunately, there is no way in the deployed POM to declare a dependency on the version number but not on the jre/android variant.(In case it is not obvious, I do not assume that the POM in the repository is the same POM used to build the library, or even thatthe library is built using Maven.) I'm not sure whether is better to pick a version (with variant) somewhat arbitrarily (as recommended) or notmention any version in the deployed POM.
classifier: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 Java 11 but at the same time also an artifact that still supports Java 1.8. The first artifact could be equipped with the classifier
jdk11
and the second one withjdk8
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
andjavadoc
are used to deploy the project source code and API docs along with the packaged class files.
--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/d84e3c96-039d-4cab-ade0-417e3762ba0en%40googlegroups.com.
FWIW, Guice uses "classifier" for this (https://maven.apache.org/pom.html#Dependencies):classifier: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 Java 11 but at the same time also an artifact that still supports Java 1.8. The first artifact could be equipped with the classifier
jdk11
and the second one withjdk8
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
andjavadoc
are used to deploy the project source code and API docs along with the packaged class files.
On Wed, Sep 16, 2020 at 10:45 AM Alan Snyder <alan.th...@gmail.com> wrote:
Now that there are two flavors of guava (jre and android), how should a library that depends on guava document its dependency?I've looked at two examples, and they both depend upon guava-jre.Is that the recommended solution?How does that affect users of the library who want android?--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-...@googlegroups.com.
Am 24.09.20 um 10:44 schrieb Thomas Broyer:
> Using different classifiers for the same version means sharing the same
> POM, sharing the same dependencies.
Agreed.
> That means people choosing to use the no_aop variant will have the
> aopalliance dependency even though they don't need it, unless they
> explicitly exclude it (and know that they can/should exclude it).
As far as I understand Maven's dependency handling, a dependency without
<type> will give you just the standard jar, with <type>no_aop</type> you
get the no_aop artifact instead.
Caveat: I have never used <type> in a <dependency>, so I'm going by theory.
Am 28.09.20 um 16:50 schrieb 'Chris Povirk' via guava-discuss:
> (at least under Maven -- we should
> look at the Gradle-specific approach sometime).
I suspect there's little hope in that.
Gradle reuses Maven's dependency information (at least when consuming
Maven artifacts). This dependency information is designed for Maven's
consumption, so other build tools can't do anything that the
already-available metadata doesn't already provide.