We have a multi-project build with a intra-project dependencies between the 'included' projects in the settings.gradle. There are a number of interdependencies between the various projects expressed as project dependencies included in the moderately sized list of the project's dependencies.
While this approach works fine in several other multi-project builds, in this particular project, the project dependencies are not being honored, therefore sub projects are being built in the wrong order and the build fails.
So, for starters, how do we diagnose what's going on here in order to determine if it is a bug?
We're running:
Gradle (Wrapper) Version: 3.1
Operating System: Windows 8.1 6.3 amd64
JDK: Oracle 1.8.0_65
So - we eventually determined that the problem was this - there was code in a configurations.all block that was setting the useVersion on various dependencies. If one of these dependencies happened to be a project dependency, the project dependency piece is broken.
It's hard to answer without seeing the relevant snippets of build.gradle and also an overview of how the offending projects include one another. Here's a couple of likely candidates
Sometimes the evaluation of one project is dependent upon the evaluation of another, in these cases you can use evaluationDependsOn
project(':projectA') {
evaluationDependsOn(':projectB')
}
project(':projectB') {
project(':projectA').tasks.create(...)
}
In cases where there's a circular reference between project dependencies you might be able to break the loop by adding extra configuration(s)
project(':projectA') {
configurations {
base
compile.extendsFrom base
}
dependencies {
base 'aaa:bbb:1.0'
compile project(path: ':projectB', configuration: 'base')
}
}
project(':projectB') {
configurations {
base
compile.extendsFrom base
}
dependencies {
base 'ccc:ddd:1.0'
compile project(path: ':projectA', configuration: 'base')
}
}
Related
It's probably very simple, but only to people who know what they are doing.
I have a Java program that imports these two:
import org.apache.commons.lang.StringUtils;
import org.apache.commons.lang.exception.ExceptionUtils;
As an aside, I don't want to use the lang3 package but the lang package.
I do not have anything in my Gradle file about these. When I try to build the file, it gives me errors for these two, saying the packages do not exist.
My questions are:
Do I need to add them as "compile" or as "api"?
What is the exact syntax? I have lines that look like this:
api group: 'commons-httpclient', name: 'commons-httpclient', version: '3.1'
How do I find the right name (or should I just invent one)? and the version?
Anything your code needs (besides basic JRE classes) is a dependency for your code. Gradle manages these dependencies, usually downloading them from a repository.
First you need to find such a repository. You probably have repositories already configured in your build.gradle, like so:
buildscript {
repositories {
mavenCentral()
// maybe more repositories
}
}
That means Gradle will try to download dependencies from Maven Central. You can either do a web search for "gradle" and your dependency, or go to repository and search, or check the dependency's homepage.
You'll end up with a dependency name and version like 'org.apache.commons:commons-lang3:3.12.0'. This needs to go in your build.gradle.
Gradle has different dependencies:
buildscript dependencies provide code that Gradle needs to execute to build your project, e.g., a tool to pull in version control system information or generate code
implementation dependencies are dependencies your code needs to run, like a logging framework or JSON parser or PDF generator
test dependencies are dependencies needed to run your automated tests, like JUnit
Depending on where you need the dependency, you put it in the buildscript or the dependencies block.
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'org.tmatesoft.svnkit:svnkit:1.9.+'
}
}
dependencies {
implementation 'pdfbox:pdfbox:0.7.3'
testImplementation 'junit:junit:4.+'
}
You don't need to repeat the implementation dependencies for the testImplementation btw, as it inherits them automatically.
You can define your own configurations as need; see the Gradle manual on dependencies, for example if you have different test suites (unit, integration, performance, ...) that need different dependencies.
you'll have to go to their official website and get the implementations then add those to the dependencies(you'll find it at the bottom of the file) in the build.gradle(module) it would look something like -
the $lifecycle_version might be somethiing like 1.2.3 or some version number.
this is what I got (not exactly sure if this is right)-
implementation 'org.apache.commons:commons-lang3:3.12.0'
got from library website in the gradle short tab
in the build.gradle(project), look for maven repo.
Once done, you'll be able to import the respective libraries.
I'm writing Minecraft Plugin using IntelliJ IDEA Ultimate with gradle. I have added dependency org.spigotmc:spigot-api:1.13.2-R0.1-SNAPSHOT as compileOnly. During development, I noticed that gradle compiles my code in different way than IntelliJ does. For example, IntelliJ was unable to accept addPassenger on Boat, but gradle compiled it. In the opposite way, if I changed it into setPassenger, IntelliJ didn't mark it as error, but gradle failed to compile. I tried to invalidate caches, reimport, clean, even remove %userprofile%\.gradle directory, nothing helped. As a POC I changed compileOnly to compile and it worked well, IntelliJ and gradle compilation results were consistent. What's the reason?
Ok, I found the solution (and forgot about this question).
I had been using multiple dependencies, and one load another with older version that I loaded implicitly in my build.gradle. However, they weren't exactly the same dependencies, but parallel ones. So gradle could not choose higher version of one dependency. Solution was to exclude this one explicitly loaded dependency and everything worked well.
Before:
dependencies {
compileOnly 'com.sk89q.worldedit:worldedit-bukkit:7.0.1'
compileOnly group: 'org.spigotmc', name:'spigot-api', version: '1.15.1-R0.1-SNAPSHOT'
}
After:
dependencies {
compileOnly('com.sk89q.worldedit:worldedit-bukkit:7.0.1') {
exclude `org.bukkit:bukkit:1.15.1-R0.1-SNAPSHOT`
}
compileOnly group: 'org.spigotmc', name:'spigot-api', version: '1.15.1-R0.1-SNAPSHOT'
}
I have the following multi project structure:
/
build.gradle
common/
build.gradle
src/main/
resources/common.properties
java/...
src/test/
resources/common.properties
java/...
app/
build.gradle
src/main/java/...
src/test/java/...
admin/
build.gradle
src/main/java/...
src/test/java/...
common project contains some common methods and they have their own unit tests and one CommonDefs class which contains data loaded from common.properties. When running unit tests, the common.properties file from the test resources supposedly overrides the one in the main resources, and the tests do work as expected.
The problem begins when running unit tests for app and admin projects - which contain tests that use CommonDefs from the common project.
Up until now I've used a generic solution similar to the method described in the following SO answer and it has worked perfectly for a couple years. This is what the root build.gradle contains:
allprojects {
plugins.withType(JavaPlugin) {
configurations {
testOutput
}
dependencies {
testOutput sourceSets.test.output
}
}
}
and app/build.gradle & admin/build.gradle both contain:
dependencies {
compile project(":common")
testCompile project(path: ":common", configuration: "testOutput")
// ...
}
I've decided it was time to upgrade Gradle (previously used 2.14.1), so I started testing the project against Gradle 4.2.1. Now every time I run the tests for app and admin, CommonDefs loads data from src/main/resources/common.properties instead of src/test/resources/common.properties.
I've tried printing the test classpath for the app project and it seems that Gradle 4.2.1 takes the common's main JAR first:
path\to\app\build\classes\java\test
path\to\app\build\resources\test
path\to\app\build\classes\java\main
path\to\app\build\resources\main
path\to\common\build\libs\common.jar
path\to\common\build\classes\java\test
path\to\common\build\resources\test
with Gradle 2.14.1 the result was:
path\to\app\build\classes\test
path\to\app\build\resources\test
path\to\app\build\classes\main
path\to\app\build\resources\main
path\to\common\build\classes\test
path\to\common\build\resources\test
path\to\common\build\libs\common.jar
Is there a way to tell the newer version of Gradle to prioritize the test output of common over its main output?
N.B
I also tried using the following in app/build.gradle:
evaluationDependsOn(":common")
dependencies {
compile project(":common")
testCompile project(":common").sourceSets.test.output
}
which seems to work, but it looks rather hacky and I'd like to stick to the solution with the configuration if possible.
I'm using the approach from Gradle - extract file from depended jar to extact a .so file from inside a native JAR.
configurations {
special
}
dependencies {
special('org.jogamp.jogl:jogl-all:2.3.2:natives-linux-i586')
}
task extract(type: Copy) {
from({ zipTree(configurations.special.singleFile) })
include 'natives/linux-i586/*.so'
into "$buildDir/extracted"
}
This works fine, however it appears to break compilation of code that depends on org.jogamp.jogl:jogl-all:2.3.2, the non-native Java part.
TestJogl.java:1: error: package com.jogamp.opengl does not exist
import com.jogamp.opengl.GL;
The compilation fails if the project is built with clean extract build but not clean build
I've simplified the code to
import com.jogamp.opengl.GL;
public class TestJogl {
private GL gl;
}
and corresponding build.gradle
apply plugin: "java"
dependencies {
compile "org.jogamp.jogl:jogl-all:2.3.2"
}
I've isolated this issue to the usage of "flatDir" repo. The exact same project compiles fine when using mavenCentral(). Note using a legacy corporate network without artifactory or direct Internet access.
allprojects {
repositories {
flatDir {
dirs "$rootProject.projectDir/local-repo"
// contains jogl-all-2.3.2-natives-linux-i586.jar
// jogl-all-2.3.2.jar
}
}
}
I've managed to work around the issue by changing the dependency to explicity specify #jar, which should be implicit
compile "org.jogamp.jogl:jogl-all:2.3.2#jar"
The same problem occurs in both single and multi project layouts.
My analysis: This is a bug in Gradle. Somehow when using flatDir Gradle gets confused and thinks that the dependency has been setup, but uses the native JAR instead of the Java JAR.
Questions: Am I doing something wrong? Is this a bug? Is there another way to workaround it?
Environment: Gradle 3.5, JDK 1.8u144
I have been trying to find the correct settings for IntelliJ's annotation processing in order for it to co-exist with Gradle's build process.
Whenever I build from IntelliJ I cannot get it to recognise the generated sources from the gradle-apt-plugin.
My requirements for my project are:
Building between IntelliJ and Gradle should be seamless and not interfere with the process of each other
I need to use IntelliJ's Create separate module per source set option
I need to use IntelliJ's folder based structure
IntelliJ needs to be able to recognise and autocomplete AutoValue classes
Here are the steps for a MCVE in order to reproduce the issue with IntelliJ 2017.2.4 and Gradle 3.5:
Create a new Gradle project from IntelliJ
Check the Create separate module per source set option
Open build.gradle file:
Add the following plugins block:
plugins {
id 'java'
id 'net.ltgt.apt' version '0.12'
}
Add the following dependencies block
dependencies {
compileOnly 'com.google.auto.value:auto-value:1.5'
apt 'com.google.auto.value:auto-value:1.5'
}
Go to Settings → Build, Execution, Deployment → Annotation Processors
Check the Enable Annotation Processing
Create a class:
#AutoValue
public abstract class GeneratedSourcesTest {
static GeneratedSourcesTest create(String field) {
return new AutoValue_GeneratedSourcesTest(field);
}
public abstract String field();
}
On IntelliJ run Build → Build Project
Open the GeneratedSourcesTest class, on the static factory method, everything compiles fine but I get the error:
cannot resolve symbol ‘AutoValue_GeneratedSourcesTest’
How can I make the AutoValue_GeneratedSourcesTest class accessible from IntelliJ?
After importing your Gradle project under IDEA do the following steps:
Set annotation processing configuration as follows:
Run menu: Build - Build Project
Right click on each new generated folder and select: Mark Directory as - Generated Sources Root so it was marked as follows:
Add /generated to project's .gitignore file
That's a minimal viable configuration which will provide full IDE support for generated classes.
The drawback is, whenever Gradle project gets re-imported the generated folders will need be marked as Generated Sources Root again.
Perhaps this can be improved with adding these paths as source sets under build.gradle.
Sometimes it happens that IDEA modules lose their compiler output path settings in result of the above. It's sufficient to just set it back to their default folders.
The answers are (should be) in the README for the gradle-apt-plugin: https://github.com/tbroyer/gradle-apt-plugin
Namely, also apply the net.ltgt.apt-idea plugin.
Btw, I recommend delegating build/run actions to Gradle in IntelliJ. Sure it's a bit slower, but requires zero setup in the IDE and works reliably. That said, it should also work OK if you don't.
Just have your build.gradle with these and it works fine, no need of touching intellij, source set etc..
plugins {
id 'java'
id "net.ltgt.apt" version "0.20"
}
apply plugin: 'idea'
apply plugin: 'net.ltgt.apt-idea'
group 'abc'
version '1.0-SNAPSHOT'
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.12'
compile "com.google.auto.value:auto-value-annotations:1.6.2"
annotationProcessor "com.google.auto.value:auto-value:1.6.2"
}
I didn't have to do anything to intellij using maven by adding the optional true tag.
<dependency>
<groupId>com.google.auto.value</groupId>
<artifactId>auto-value</artifactId>
<version>1.9</version>
<optional>true</optional>
</dependency>