Gradle 4 - test dependency on another project's tests - java

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.

Related

include a gradle 'war' project in another project

I'm new to Gradle and trying to work out how to get my dependencies working correctly.
I have a project which builds a war using the 'war' plugin. I'd then like to use that project, and some other similar projects, to deploy those wars.
However, I can't work out how to make the project which is responsible for assembling these other projects dependent on the war projects.
The project 'war1' has a single 'war' method, I’ve tried the following
dependencies, none of which work:
dependencies {
war project(path: ':war1')
/* or */ compile project(path: ':war1')
/* or */ assemble project(path: ':war1')
}
Could not find method xxx() for arguments [DefaultProjectDependency{dependencyProject='project ':war1', configuration='default'}]
You can specify dependencies on .war artifacts in Gradle like this example...
dependencies {
runtime "org.jasig.cas:cas-server-webapp:3.5.2#war"
}
NOTE: this example is for an external dependency, not a dependency on another sub-project within the same multi-project setup. Looking at the api docs, it appears that you would do that like this...
dependencies {
runtime project(path: ':war1', configuration: 'war')
}
Also -- perhaps you could benefit from the Gradle WAR overlay plugin. This plugin allows you to "enhance" a war dependency by adding or tweaking a few files within it, and thereby provide some configuration choices that your project knows about, but the original war didn't.

Additional gradle configuration breaking compilation when using flatDir repo

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

Gradle - include class files from one project in another

So I have a multi project setup that looks something like this
Root Project
--> common
--> project1
--> project2
--> 3rd_party_api
So common obviously contains a bunch of code shared across the other projects. Projects 1 and 2 are fine because they are wars and contain the common jar file as a dependency without any issues.
The problem I have is with my 3rd_party_api project. This is quite a small jar file that we will be delivering to other teams so that they can integrate with our code. Most of the java code required is contained in this project folder however there are 3 or 4 classes that are in the common project and need to be included in this library. Because it has to be standalone I need to wrap those classes in the jar file.
I have tried various iterations of srcDirs and source but I can't for the life of me figure out an easy way to do this.
As I've said I've looked at different approaches but my latest attempt looked a bit like this:
project(':api') {
defaultTasks 'jar'
apply plugin: 'java'
sourceSets {
main {
java {
srcDir 'src/main/java'
srcDir fileTree(dir: '../common/src/main/java').matching { include 'com/my/classes/**' }
}
}
dependencies {
compile project(':common')
}
}
This compiles successfully but the extra classes from common are not included in the jar.
Any help would be greatly appreciated.
Thanks Dirk,
Didn't quite work for me but got me thinking about other approaches. I eventually got it to do what I needed using a custom jar task. Something like the following:
defaultTasks 'lib'
dependencies {
compile project(':common')
}
task lib( type: Jar, dependsOn: classes) {
from sourceSets.main.output
from (project(':common').sourceSets.main.output) {
include 'com/myclasses/stuff/**'
include 'com/specificclass/MyClass.class'
}
}
maybe something like:
jar {
baseName = 'yourJarFileName'
from('path/to/your/dir/') {
include 'local/path/from/there/**/*.jar'
}
}
didn't checked this ... so don't blame me if it does not work out of the box ;)
other possibility would be to define your custom sourceSets ... but never tried this either.

Gradle seems to ignore project dependencies

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')
}
}

Intellij Idea 13 UI Designer and automatic Gradle building

I've used the Intellij UI Designer to create forms for a project. Everything works fine when I'm building with idea as it handles compiling the forms for me, but as we recently switched to using Gradle for building it hasn't been possible to produce an executable jar file yet.
My google-fu has led me to several posts that explains that an ant script is needed to compile (eg link, link2, link3 ,and the one i ended on following: link4)
My project is a multi-module setup.
root build.gradle
subprojects {
apply plugin: 'java'
apply plugin: 'idea'
repositories {
mavenCentral()
}
}
supproject build.gradle
apply plugin:'application'
mainClassName = "dk.OfferFileEditor.OfferFileEditorProgram"
configurations {
antTask
}
dependencies {
compile 'org.json:json:20140107'
compile project(":Shared:HasOffers Api")
//dependencies for java2c
antTask files('../../lib/javac2-13.1.1.jar', '../../lib/asm4-all-13.1.1-idea.jar', '../../lib/forms_rt-13.1.1.jar')
antTask group: 'org.jdom', name: 'jdom', version: '1.1'
}
task compileJava(overwrite: true, dependsOn: configurations.compile.getTaskDependencyFromProjectDependency(true, 'jar')) {
doLast {
println 'using java2c to compile'
project.sourceSets.main.output.classesDir.mkdirs()
ant.taskdef name: 'javac2', classname: 'com.intellij.ant.Javac2', classpath: configurations.antTask.asPath
ant.javac2 srcdir: project.sourceSets.main.java.srcDirs.join(':'),
classpath: project.sourceSets.main.compileClasspath.asPath,
destdir: project.sourceSets.main.output.classesDir,
source: sourceCompatibility,
target: targetCompatibility,
includeAntRuntime: false
}
}
But even though the compilation is successfull, a Nullpointer exception is thrown the first time I try to access one of the fields the UI Designer created. So something is not being compiled correctly.
I'm probably missing some setting, but after unsuccesfully pouring several hours into forums and google I still haven't found any solution.
So I made this a lot more complicated than needs be.
To make it work you need to change two things in your project.
A setting in IDEA 13.1.5
Settings -> GUI Designer -> Generate GUI into: Java source code
This makes IntelliJ IDEA add 3 methods into the bottom of your forms:
$$$setupUI$$$()
$$$setupUI$$$()
$$$getRootComponent$$$()
If they are missing try recompiling your project after you change the setting.
Add the missing classes
Intellij has a jar called forms_rt.jar, and I found mine in {IntelliJ IDEA Root}\lib. And renamed it to "forms_rt-13.1.1.jar"
This needs to be included during compile time to your project. If you are using Gradle as I did you could copy it to {project root}/lib and add a flatfile repository like so:
repositories {
mavenCentral()
flatDir dirs: "${rootDir}/lib"
}
After that you need to include it in your project gradle file:
dependencies {
compile name: 'forms_rt', version: '13.1.1'
}
After that it should be possible to build it both in IntelliJ IDEA and Gradle.
IntelliJ IDEA 2019.1
I found this issue still exists. It's at least somehow documented now:
If your build actions are delegated to Gradle, GUI Designer will not generate Java source code.
So by disabling the according setting
Build, Execution, Deployment | Build Tools | Gradle | Runner | Delegate IDE build/run actions to gradle
I was able to build and run the project successfully. Note that I didn't need any other settings or additional libraries from the answers above. I let Generate GUI into be set to Binary class files.
The forms_rt library is in mavenCentral.
http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22forms_rt%22
Once you have configured IntelliJ to update the SourceCode it is sufficient to just add the library to the dependencies in your build.gradle.
dependencies {
compile 'com.intellij:forms_rt:7.0.3'
}
Idea 2019.2
It seems like IntelliJ changed the settings UI when updating from 2019.1 to 2019.2, as the menu entry mentioned by Tom isn't there anymore.
I got it fixed by setting Build and run using: to IntelliJ Idea. I also changed Run tests using: to IntelliJ Idea to avoid problems while testing.
Both settings are located under File | Settings | Build, Execution, Deployment | Build Tools | Gradle.
I figured out an updated version of the gradle build workaround for a new project - https://github.com/edward3h/systray-mpd/blob/master/build.gradle
Probably won't use the form designer again though.
These are the relevant parts:
repositories {
mavenCentral()
maven { url "https://www.jetbrains.com/intellij-repository/releases" }
maven { url "https://jetbrains.bintray.com/intellij-third-party-dependencies" }
}
configurations {
antTask
}
dependencies {
implementation 'com.jetbrains.intellij.java:java-gui-forms-rt:203.7148.30'
antTask 'com.jetbrains.intellij.java:java-compiler-ant-tasks:203.7148.30'
}
task compileJava(type: JavaCompile, overwrite: true, dependsOn: configurations.compile.getTaskDependencyFromProjectDependency(true, 'jar')) {
doLast {
project.sourceSets.main.output.classesDirs.each { project.mkdir(it) }
ant.taskdef name: 'javac2', classname: 'com.intellij.ant.Javac2', classpath: configurations.antTask.asPath
ant.javac2 srcdir: project.sourceSets.main.java.srcDirs.join(':'),
classpath: project.sourceSets.main.compileClasspath.asPath,
destdir: project.sourceSets.main.output.classesDirs[0],
source: sourceCompatibility,
target: targetCompatibility,
includeAntRuntime: false
}
}
The dependency versions for jetbrains libraries are found via https://plugins.jetbrains.com/docs/intellij/intellij-artifacts.html?from=jetbrains.org#using-intellij-platform-module-artifacts and https://www.jetbrains.com/intellij-repository/releases/

Categories

Resources