Download JAR files tagged by older with all dependencies

A backport for java.util.function to be used in java versions older than 1.8. As there are no default methods before 1.8 the backport is very limited. It only allows to create libraries with modern APIs to allow 1.8 code to use nice and natural lambdas without locking out users with older java versions. ATTENTION: This only works with -Xbootclasspath. Also it is inofficial and invalid according to JCP/JSR. However, we need a working update-path to 1.8.

Clirr is a tool that checks Java libraries for binary compatibility with older releases. Basically you give it two sets of jar files and Clirr dumps out a list of changes in the public api. Clirr provides an Ant task that can be configured to break the build if it detects incompatible api changes. In a continuous integration process Clirr can automatically prevent accidental introduction of binary compatibility problems in Java libraries.

An empty artifact that Guava depends on to signal that it is providing ListenableFuture -- but is also available in a second "version" that contains com.google.common.util.concurrent.ListenableFuture class, without any other Guava classes. The idea is: - If users want only ListenableFuture, they depend on listenablefuture-1.0. - If users want all of Guava, they depend on guava, which, as of Guava 27.0, depends on listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-... version number is enough for some build systems (notably, Gradle) to select that empty artifact over the "real" listenablefuture-1.0 -- avoiding a conflict with the copy of ListenableFuture in guava itself. If users are using an older version of Guava or a build system other than Gradle, they may see class conflicts. If so, they can solve them by manually excluding the listenablefuture artifact or manually forcing their build systems to use 9999.0-....

This is a specialized version of the Clirr Maven Plugin. It adds capabilities for excluding specific error types, as well as separating code into three, rather than two, subgroups: Internal code (no checks) Externally invoked code (Annotated with an "externally invoked" annotation, same as Externally implemented, but adding methods to interfaces and abstract classes is allowed) Externally implemented code (Assumed default. Full backwards compatibility required *unless* an interface is annotated with a defined adaptor annotation, in which case full backwards compatibility is required for the adaptor class, but the rules of @ExternallyInvoked apply to the interface itself) Clirr is a tool that checks Java libraries for binary and source compatibility with older releases. Basically you give it two sets of jar files and Clirr dumps out a list of changes in the public API. The clirr-maven-plugin can be configured to break the build, if it detects incompatible api changes. In a continuous integration process, the clirr-maven-plugin can automatically prevent accidental introduction of binary or source compatibility problems. Additionally, the plugin can generate a report as part of the generated site.