Download JAR files tagged by conflicts with all dependencies

This bill of materials (BOM) POM covers all the Metrics artifacts related to a particular version. By importing this BOM, you fix the version of all of Metrics-related artifacts to the versions associated with a particular release. This prevents the overriding of Metrics transitive dependencies which in turn could cause version conflicts between libraries. To use this BOM, add the following in your POM: <dependencyManagement> <dependencies> <dependency> <groupId>com.covisint.core</groupId> <artifactId>metrics-bom</artifactId> <version>3.0.2</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> And then declare your dependency on the Metrics artifacts *without* a version.

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-....

--------------------------------------------------------------------------- Version for VIVO 1.9 This uses the source and test code from the Version for VIVO 1.10, edited to make it compatible with VIVO 1.9. It also borrows some code from VIVO 1.10 itself, changes the package name to avoid conflicts, and adds it here. * Vitro 1.9 uses Jena 2, not Jena 3, and Commons Lang 2, not 3, so modify the "import" statements in the Data Distribution code accordingly. * Vitro 1.9 has an earlier version of "...webapp.utils.sparqlrunner" package, so borrow the source from Vitro 1.10, move it to a different package so it won't conflict with the 1.9 version, modify it to use Jena 2 and Commons Lang 2, and modify the Data Distribution API code to use this sparqlrunner package. * Vitro 1.9 has an earlier version of "...webapp.utils.configuration" package, so borrow the source from Vitro 1.10, move it to a different package so it won't conflict with the 1.9 version, modify it to use Jena 2 and Commons Lang 2, and modify the Data Distribution API code to use this configuration package. Make these modifications, compile, JAR it up, and deploy. ---------------------------------------------------------------------------

This is an endorsed version of the original Deployment Client for Oracle GlassFish Open Source Edition. The purpose of the endorsement is to provide a shaded JAR which has the OSGI meta data removed because it causes the original Deployment Client to fail when used within a module running within a GlassFish container due to some class loader configuration conflicts between the container and the deployed module. This issue has been reported to the GlassFish project at https://java.net/jira/browse/GLASSFISH-20856 . It is hoped that it can get fixed so that this workaround project can get deprecated soon.

This repository contains various third party sources required by the main retepTools repository. The reason for this is when they are only available in SNAPSHOT format and we require a release version to enable us to run a release. Although not ideal, this is sometimes necessary if some critical bug needs to be fixed. Currently this contains docbkx-tools. Rules for this repository: * Projects must follow the same licensing as the main project :- BSD, Apache2 etc but not GPL, LGPL etc * groupId's must be within the uk.org.retep.third-party namespace - and not the projects original namespace (so we don't have version conflicts) * Must be disabled/removed once those projects become stable

--------------------------------------------------------------------------- Version for VIVO 1.8 This uses the source and test code from the Version for VIVO 1.10, edited to make it compatible with VIVO 1.8. It also borrows some code from VIVO 1.10 itself, changes the package name to avoid conflicts, and adds it here. * Vitro 1.8 uses Jena 2, not Jena 3, and Commons Lang 2, not 3, so modify the "import" statements in the Data Distribution code accordingly. * Vitro 1.8 does not have a "...webapp.utils.sparqlrunner" package, so borrow the source from Vitro 1.10, move it to a different package (just for compatibility with the 1.9 version), modify it to use Jena 2 and Commons Lang 2, and modify the Data Distribution API code to use this sparqlrunner package. * Vitro 1.9 has an earlier version of "...webapp.utils.configuration" package, so borrow the source from Vitro 1.10, move it to a different package so it won't conflict with the 1.9 version, modify it to use Jena 2 and Commons Lang 2, and modify the Data Distribution API code to use this configuration package. Make these modifications, compile, JAR it up, and deploy. --------------------------------------------------------------------------- Because VIVO 1.8 is not available as a Maven package, we have extracted the class files, JARed them up, and stored them in a file-based repository within this project. But that doesn't include any transitive dependencies, so any package that this code requires must be explicitly listed as a dependency. ---------------------------------------------------------------------------