Gradle Only Download Dependencies __HOT__
Xochitl Lorts
I tried putting it into configuration instead of action (by removing doLast) and it broke zinc. I worked around it, but the end result was the same with or without. So, I left it as an explicit state. It seems to work enough to reduce the dependencies that have to be downloaded later, but not eliminate them in my case. I think one of the Scala plugins adds dependencies later.
I was was looking for it some time ago when working on a project in which we had to download all dependencies into current working directory at some point in our provisioning script. I guess you're trying to achieve something similar.
Building on top of Robert Elliot's answer. For whatever reason, if one is interested in downloading the dependencies to Gradle cache then copying to a local repository like maven's (by default /.m2/repository):
The easiest way to do this is probably to specify a new sourceSet called 'speedTest'. This will generate a configuration called 'speedTest' which you can use to specify your dependencies within a dependencies block. It will also generate a task called compileSpeedTestJava for you.
Compile-only dependencies are distinctly different than regular compile dependencies. They are not included on the runtime classpath and they are non-transitive, meaning they are not included in dependent projects. This is true when using Gradle project dependencies and also when publishing to Maven or Ivy repositories. In the latter case, compile-only dependencies are simply omitted from published metadata.
Every dependency declared for a Gradle project applies to a specific scope.For example some dependencies should be used for compiling source code whereas others only need to be available at runtime.Gradle represents the scope of a dependency with the help of a Configuration.Every configuration can be identified by a unique name.
Configuration inheritance is heavily used by Gradle core plugins like the Java plugin.For example the testImplementation configuration extends the implementation configuration.The configuration hierarchy has a practical purpose: compiling tests requires the dependencies of the source code under test on top of the dependencies needed write the test class.A Java project that uses JUnit to write and execute test code also needs Guava if its classes are imported in the production source code.
Under the covers the testImplementation and implementation configurations form an inheritance hierarchy by calling the method Configuration.extendsFrom(org.gradle.api.artifacts.Configuration[]).A configuration can extend any other configuration irrespective of its definition in the build script or a plugin.
Configurations are intended to be used for a single role: declaring dependencies, performing resolution, or defining consumable variants.In the past, some configurations did not define which role they were intended to be used for.A deprecation warning is emitted when a configuration is used in a way that was not intended.To fix the deprecation, you will need to stop using the configuration in the deprecated role.The exact changes required depend on how the configuration is used and if there are alternative configurations that should be used instead.
Gradle provides different notations for module dependencies. There is a string notation and a map notation. A module dependency has an API which allows further configuration. Have a look at ExternalModuleDependency to learn all about the API. This API provides properties and configuration methods. Via the string notation you can define a subset of the properties. With the map notation you can define all properties. To have access to the complete API, either with the map or with the string notation, you can assign a single dependency to a configuration together with a closure.
If you declare a module dependency, Gradle looks for a module metadata file (.module, .pom or ivy.xml) in the repositories.If such a module metadata file exists, it is parsed and the artifacts of this module (e.g. hibernate-3.0.5.jar) as well as its dependencies (e.g. cglib) are downloaded.If no such module metadata file exists, as of Gradle 6.0, you need to configure metadata sources definitions to look for an artifact file called hibernate-3.0.5.jar directly.
File dependencies allow you to directly add a set of files to a configuration, without first adding them to a repository. This can be useful if you cannot, or do not want to, place certain files in a repository. Or if you do not want to use any repositories at all for storing your dependencies.
File dependencies are not included in the published dependency descriptor for your project.However, file dependencies are included in transitive project dependencies within the same build.This means they cannot be used outside the current build, but they can be used within the same build.
Software projects often break up software components into modules to improve maintainability and prevent strong coupling.Modules can define dependencies between each other to reuse code within the same project.
At runtime, the build automatically ensures that project dependencies are built in the correct order and added to the classpath for compilation.The chapter Authoring Multi-Project Builds discusses how to set up and configure multi-project builds in more detail.
The following example declares the dependencies on the utils and api project from the web-service project. The method Project.project(java.lang.String) creates a reference to a specific subproject by path.
Type-safe project accessors are an incubating feature which must be enabled explicitly.Implementation may change at any time.To add support for type-safe project accessors, add this to your settings.gradle(.kts) file:
You can declare a dependency on the TestKit API of the current version of Gradle by using the DependencyHandler.gradleTestKit() method. This is useful for writing and executing functional tests for Gradle plugins and build scripts.
You can declare repositories to tell Gradle where to fetch local or remote dependencies.
In this example, Gradle fetches dependencies from the Maven Central and Google repositories.
During a build, Gradle locates and downloads the dependencies, a process called dependency resolution.Gradle then stores resolved dependencies in a local cache called the dependency cache.Subsequent builds use this cache to avoid unnecessary network calls and speed up the build process.
You can add code to your Java project from an external library such as com.google.common.base (a Guava package) which becomes a dependency.
In this example, the theoretical project uses Guava version 32.1.2-jre and JUnit 4.13.2 as dependencies.
A build engineer can declare dependencies for different scopes. For example, you can declare dependencies that are only used at compile time.Gradle calls the scope of a dependency a configuration.
Organizations building software may want to leverage public binary repositories to download and consume open source dependencies.Popular public repositories include Maven Central and the Google Android repository.Gradle provides built-in shorthand notations for these widely-used repositories.
Under the covers Gradle resolves dependencies from the respective URL of the public repository defined by the shorthand notation.All shorthand notations are available via the RepositoryHandler API.Alternatively, you can spell out the URL of the repository for more fine-grained control.
Most enterprise projects set up a binary repository available only within an intranet.In-house repositories enable teams to publish internal binaries, setup user management and security measure and ensure uptime and availability.Specifying a custom URL is also helpful if you want to declare a less popular, but publicly-available repository.
You can define more than one repository for resolving dependencies.Declaring multiple repositories is helpful if some dependencies are only available in one repository but not the other.You can mix any type of repository described in the reference section.
The order of declaration determines how Gradle will check for dependencies at runtime.If Gradle finds a module descriptor in a particular repository, it will attempt to download all of the artifacts for that module from the same repository.You can learn more about the inner workings of dependency downloads.
Some projects might prefer to store dependencies on a shared drive or as part of the project source code instead of a binary repository product. If you want to use a (flat) filesystem directory as a repository, simply type:
For example, if Gradle finds only jmxri-1.2.1.jar in a flat directory repository, but jmxri-1.2.1.pom in another repository that supports meta-data, it will use the second repository to provide the module.
Gradle can consume dependencies available in the local Maven repository.Declaring this repository is beneficial for teams that publish to the local Maven repository with one project and consume the artifacts by Gradle in another project.
If you leverage exclusive content filtering in the pluginManagement section of the settings.gradle(.kts), it becomes illegal to add more repositories through the project buildscript.repositories.In that case, the build configuration will fail.
However, if you define a customized repository you might want to configure this behavior.For example, you can define a Maven repository without .pom files but only jars.To do so, you can configure metadata sources for any repository.
Username and password should never be checked in plain text into version control as part of your build file. You can store the credentials in a local gradle.properties file and use one of the open source Gradle plugins for encrypting and consuming credentials e.g. the credentials plugin.
When configuring a repository using HTTP or HTTPS transport protocols, multiple authentication schemes are available. By default, Gradle will attempt to use all schemes that are supported by the Apache HttpClient library, documented here. In some cases, it may be preferable to explicitly specify which authentication schemes should be used when exchanging credentials with a remote server. When explicitly declared, only those schemes are used when authenticating to a remote repository.
df19127ead