Is there a way that makes gradle download dependency libraries to the project directory, just like maven does? I know that gradle keeps its own cache in local machine directory, but how can I know what libraries will be used for my project, especially the library I defined in the build.gradle file has its own dependency?
To know what libraries will be used for your project you can use dependencies task. It will help you to find out the dependencies of your module and its recursive dependencies.
If your module name is app, then you can try gradle :app:dependencies in the project directory. You'll get something like below as output.
compile - Classpath for compiling the main sources.
\--- com.android.support:appcompat-v7:22.2.0
\--- com.android.support:support-v4:22.2.0
\--- com.android.support:support-annotations:22.2.0
Here com.android.support:appcompact-v7:22.2.0 is dependency of the module and the one below is its recursive dependency.
If you really what to get the dependencies in your project directory, then you can create a task for it like this.
task copyDependencies(type: Copy) {
from configurations.compile
into 'dependencies'
}
now you can run gradle :app:copyDependencies to get all the dependencies in location <projectDir>/app/dependencies. Note that this just give you the dependencies in your project directory and gradle is still resolving the dependencies from the local cache.
Related
I am using Gradle 6.1 in a multimodule project. I am also using two plugins: kotlin("jvm") and id("com.google.cloud.tools.jib"), and they are loaded in the following modules:
root/
build.gradle.kts loads kotlin("jvm")
services/
my-service/
rest/
build.gradle.kts loads id("com.google.cloud.tools.jib")
(There are more modules, files etc. but these are the relevant ones.)
The build fails:
$ ./gradlew clean jibDockerBuild
...
* What went wrong:
Execution failed for task ':services:driver:rest:jibDockerBuild'.
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: 'org.apache.http.client.config.RequestConfig$Builder
org.apache.http.client.config.RequestConfig$Builder.setNormalizeUri(boolean)'
I identified the issue: both the Kotlin and JIB plugins have a transitive dependency on org.apache.httpcomponents:httpclient: Kotlin requires 4.5.3 and JIB 4.5.10. The problem is, in this project setup only 4.5.3 is loaded, and JIB fails as the new method is not available. This can be checked with ./gradlew buildEnv.
I've found a workaround, I need to load both plugins at the root level (which one is first seems to be irrelevant) in the main Gradle file; now ./gradlew buildEnv shows that the higher dependency version is used, also for Kotlin (output shortened and incomplete):
classpath
+--- org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.3.61
| \--- org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.61
| +--- de.undercouch:gradle-download-task:3.4.3
| | \--- org.apache.httpcomponents:httpclient:4.5.3 -> 4.5.10
It works in this case, but it could be that the new library version breaks the Kotlin plugin. The problem is that the plugins and their dependencies are on the classpath without separation, something that was normal on Java before Jigsaw etc. Is there any way for Gradle to be able to separate the dependencies so that each plugin uses exactly the version it declares? I am building on Java 11, so the module system could be utilized, but does Gradle have an option to turn it on?
EDIT: updating to Kotlin 1.3.70 also fixes the issue as it doesn't depend on the library any longer. The general question is still valid, though.
Is there any way for Gradle to be able to separate the dependencies so that each plugin uses exactly the version it declares
No.
All plugins share the same build script configuration: classpath
It follows the same dependency resolution that application dependencies follow. So you can enforce that for this particular dependency only use a specific version always:
buildscript {
configurations {
classpath {
resolutionStrategy {
force("org.apache.httpcomponents:httpclient:4.5.10")
}
}
}
}
That's just one of many ways you can take control of dependency resolution for build script dependencies. You could also use a platform to advise on the dependency versions:
buildscript {
dependencies {
classpath(enforcedPlatform("org.springframework.boot:spring-boot-dependencies:2.2.5.RELEASE"))
}
}
Refer to the docs for more info:
https://docs.gradle.org/current/userguide/resolution_rules.html
https://docs.gradle.org/current/userguide/platforms.html
I'm struggling with Gradle and the build configuration of the following project structure (pretty simple...):
/projA
/projB
/projC
projC using classes from projB.
In projA/settings.gradle:
include 'projB'
include 'projC'
In projC/build.gradle:
dependencies{
compile project(':projB')
}
In IntelliJ I have no problem of dependency resolution, but when I'm running a ./gradlew build in projA, I'm facing a compilation error:
ClassC: Unresolved reference: ClassB
(where ClassC is the class of projC which is failing on the use of ClassB which is a class from projB, obviously...)
Notice that the code is in Kotlin language, that I do not have any problem to run the app in IntelliJ (spring boot run), but any build with Gradle give me an error (both in Intellij and command line).
What am I missing?
Regards,
Adrien
It's a common Gradle idiom to have an additional top level directory for your rootProject. That's a special project that's the parent to all other projects in your build, in a multi-project build.
That's where your settings.gradle file goes:
include ':projA:projB'
include ':projA:projC'
Then, I'd recommend having projA as a subdirectory of your rootProject, so your hierarchy would look as follows:
/myProject
settings.gradle
/projA
build.gradle
/projB
build.gradle
/projC
build.gradle
Also, in projC/build.gradle, you'll want instead:
dependencies {
compile project(':projA:projB')
}
That should do it.
I have a library A that uses a library B. These two libraries are then used by application C.
Both library A and B can be found in a maven repository.
I have tried to add B as a dependency to A by adding it into A's POM file.
I'm not sure if this is the correct approach or there is a standard way to do this.
I am looking for either the standard way of doing this or a reference guide to point me into the right direction.
Please let me know if there is any other information I can provide.
The term for such relationship is called a transitive dependency. In your application, you define just the direct dependencies, the transitive ones are handled by a particular build system (Gradle, Maven, Ant + Ivy).
For example, considering following Gradle build script:
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.0.2'
}
You can list this project dependencies with the command:
$ gradle dependencies
This should provide result similar to (depends on the Gradle version, this one is 4.4.1):
testCompileClasspath - Compile classpath for source set 'test'.
\--- org.junit.jupiter:junit-jupiter-api:5.0.2
+--- org.opentest4j:opentest4j:1.0.0
\--- org.junit.platform:junit-platform-commons:1.0.2
Therefore, opentest4j and junit-platform-commons are transitive dependencies of the junit-jupiter-api library, which is the only direct dependency of the project.
It's equivalent for Maven. E.g. you can list Maven dependencies with:
$ mvn dependency:tree
I have a multi-project Gradle build (Gradle 4.4).
And I encountered the following issue.
Let's say I have proj1 project with the following build.gradle:
repositories {
flatDir {
dirs 'libs'
}
}
dependencies {
compile name: 'lombok-edge'
}
proj1 has libs folder with lombok-edge.jar. Project is built successfully.
And I have proj2 that imports proj1:
dependencies {
compile project(':proj1')
}
When I try to build the whole project proj1 is build but Gradle fails to build proj2 with an error:
What went wrong:
Could not resolve all files for configuration ':proj2:compileClasspath'.
Could not find :lombok-edge:.
Required by:
project :proj2 > project :proj1
Please advise.
Well, Gradle supports transitive dependencies, but the way how to get a dependency (and therefor any repository information) is not transitive. Gradle (like Maven) does not care where a dependency comes from, as long as it matches a given signature (group, id, version).
In your example, project 1 defines a Maven dependency and can resolve it via the given flatDir repository. Project 2 has dependencies on both project 1 (which is resolved by Gradle) and the transitive Maven dependency. It's the responsibility of project 2 to resolve this dependency and it will check any defined repository, but cannot find it, because the local repository is unkown. This is the reason why the build fails.
If the two projects are related, as they should be if they are both parts of a multi-project build, you should define the local repository in a top-level build.gradle file and a subprojects closure.
I am trying out Gradle, and am wondering, what is supposed to happen to a project's dependencies after you run gradle build? For example, my sample projects don't run on the command line after they are built, because they are missing dependencies. They seem to compile fine, as gradle doesn't give me errors or warnings about finding the dependencies.
Gradle projects I've made in IntelliJ Idea have the same problem. They compile and run inside the IDE, but are missing dependencies and can't run on the command line.
So what is supposed to happen to the dependencies I declare in the build.gradle file? Shouldn't they be output somewhere together with my .class files? Otherwise, what is the point of gradle when I could manage this by editing my classpath?
Edit: Here is my build.gradle file:
apply plugin: 'java'
jar {
manifest {
attributes('Main-Class': 'Animals')
}
}
repositories {
flatDir{
dirs "D:\\libs\\gradleRepo"
}
}
dependencies {
compile name: "AnimalTypes-1.0-SNAPSHOT"
}
sourceSets{
main{
java {
srcDirs=['src']
}
}
}
Your Gradle build only takes care of the compile time and allows you to use the specified dependencies in your code (it adds them to the compile classpath). But it does not take care of the runtime. Once the JAR is build, you need to specify the runtime classpath and provide all required dependencies.
You may think, that this is bad or a disadvantage, but actually it is totally fine and intended, because if you build a Java library, you won't need to execute it, you just want to specify it as a dependency for another project. If you would distribute your library to a Maven repository, all dependencies from Maven repositories (module dependencies) would end up in a POM descriptor as transitive dependencies.
Now, if you want to build a runnable Java application, simply use the Gradle Application Plugin (apply plugin: 'application'), which will create a ZIP file containing the dependencies and start scripts providing your runtime classpath for execution.
Third-party plugins can also produce so-called fat JARs, which are JAR files with all dependencies included. It depends on your use case if you should use them, because often dependency management via repositories is the better way to go.