Here is quite a strange effect I get when trying to compile my project that uses groovy as scripting language. The setup is pretty simple:
I have a java application that can be configured by a groovy script. The parsing of the config file is all handled by groovy code and generate several classes that contain the extracted information from the script and which than are made available to the java app.
The configuration classes all implement interfaces, to decouple the groovy aspect so that the java app is not aware that it actually talks to groovy objects.
So, with the interfaces the only dependency i have here is from groovy to java. This should be the normal case, since the groovy plugin executes compileJava before compileGroovy by default.
This worked till today!!!
A few hours ago things started getting strange. Trying to test my app with gradle test resulted in errors telling me that the groovy classes do no see the java interfaces. I tried than to compile the java and groovy seperately with compileJava followed by compileGroovy and noticed that the latter simply deletes all class files generated by the java task. I also found a strange output when running with the --info option:
Output file /home/tomas/projects/unnecessary-wizard/build/classes/main has changed.
Output file /home/tomas/projects/unnecessary-wizard/build/classes/main/de/tlongo/unneccesarywizard/java/core/Wizard.class has changed.
Output file /home/tomas/projects/unnecessary-wizard/build/classes/main/de/tlongo/unneccesarywizard/java/core/ConstructorInjector.class has changed.
Why does the groovy task change java classes at all?
As I said, I tried to reproduce the errors with a simple showcase where a groovy class also implements a java interface, w/o success.
Here is my build.script which is pretty 9-to-5, imo:
apply plugin: 'java'
apply plugin: 'groovy'
apply plugin: 'maven'
group = 'de.tlongo'
version = '0.3-SNAPSHOT'
repositories {
mavenLocal()
mavenCentral()
}
dependencies {
compile 'org.codehaus.groovy:groovy-all:2.3.5'
compile 'commons-configuration:commons-configuration:1.7'
compile 'ch.qos.logback:logback-classic:1.1.1'
compile 'org.apache.commons:commons-lang3:3.3.2'
compile 'org.reflections:reflections:0.9.9-RC1'
testCompile 'org.hamcrest:hamcrest-all:1.3'
testCompile group: 'junit', name: 'junit', version: '4.11'
testCompile 'org.mockito:mockito-all:1.9.5'
}
Any idea what is going wrong? Or do I not understand the concept of how gradle compiles this kind of projects.
When compiling both Java and Groovy source in Gradle, you should generally put all your source in the 'src/main/groovy' directory to allow for cross-compiling. They can be separate (java in java, groovy in groovy); however, if there are cross-language dependencies you can run into compilation issues - this is what is seems you are running into.
Also, as a side note, you don't need to apply the java plugin when you apply the groovy plugin - the groovy plugin depends on the java plugin so it will already be available.
This should only ever happen after a Groovy class has been ported to Java. It's a known limitation that results from the fact that both GroovyCompile and JavaCompile delete the class files they produced on the previous run in order to prevent stale class files.
Related
I’m trying to use dl4j in my project which runs on openjdk-15.0.2.7 and I use gradle to manage my dependencies. The project builds with no errors but when the code is executed it crashes immediately with the error:
java.lang.module.InvalidModuleDescriptorException: Provider class com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReaderSpi not in module
I haven’t really worked with java modules, since I have only used java 8 so far but to me this looks like its missing a bunch of packages and I don’t know what to do about it. Do I need to put something into the module-info.java file? I have not used any dl4j classes or methods so far in the project.
Thanks in advance.
Here is how I added the dependencies:
implementation group: ‘org.deeplearning4j’, name: ‘deeplearning4j-core’, version: ‘1.0.0-beta6’
implementation group: ‘org.nd4j’, name: ‘nd4j-cuda-10.2-platform’, version: ‘1.0.0-beta6’
I'm working on a java 8 gradle project in Eclipse (2019-09) including lombok. I would love to use mapstruct for converting models into dto and vice versa.
Mapstruct works great.
Problem:
I have some trouble that Eclipse creates and compiles the mapper implementation when saving the file.
The XYMapperImpl.java/class files are only created when using ./gradlew classes.
Building it with gradle is not really an option because it takes some time and does not really work in my workflow. I need to have the .class file at the end to mount the whole /bin folder into a docker container.
I'm using the Eclipse MapStruct plugin, however this is only for Code Completion and Quick Fixes but not for generating class files.
I've done some research:
How to get Eclipse to generate MapStruct Mappers using Gradle or How to properly integrate MapStruct with Eclipse? (Including Lombok java agent) and some others without any success.
Maybe I missed something?
My build.gradle file:
plugins {
id 'java'
id "net.ltgt.apt-eclipse" version "0.21"
id "net.ltgt.apt" version "0.21"
}
apply plugin: "java"
apply plugin: "net.ltgt.apt-eclipse"
apply plugin: "net.ltgt.apt"
repositories {
mavenCentral()
}
dependencies {
compileOnly 'org.projectlombok:lombok:1.18.10'
compile "org.mapstruct:mapstruct-jdk8:1.3.0.Final"
annotationProcessor "org.mapstruct:mapstruct-processor:1.3.0.Final" //Must be defined before the lombok annotationProcessor
annotationProcessor 'org.projectlombok:lombok:1.18.6'
}
I've created a simple demo project as an example.
When calling gradle idea, external dependencies are ordered first in the class path relatively to local Jar inclusions. As such :
dependencies {
compile fileTree(dir: 'libs', include:['*.jar'])
compile group: 'foo', name:'bar', version:'1.0.0'
}
will include my local jars last. This is a problem in my project as these jars' purpose is to partially overwrite the external library.
The same behavior is observed when specifying the repository as a source of dependencies using flatDir and loading the jar without fileTree. It is put last in the classpath.
I have found several mentions of the problem when researching, such as https://discuss.gradle.org/t/gradle-messes-up-the-classpath-order-in-generated-projects-when-there-are-mixed-dependency-types/13130, but no workarounds.
I suppose these exist, gradle being very customisable, but being very new to it my attempts to make one fail. How to proceed?
I'm not using IntelliJ on a regular basis but tried it in the context of this question and my impression is that gradle's idea plugin and IntelliJ's gradle plugin don't go well together. That is you should either use the idea gradle plugin and import as plain Java project or import as gradle project using IntelliJ's gradle plugin. Main reason is that the idea plugin and the IntelliJ plugin are generating slightly different iml-files (those files are holding the project dependencies - amongst others) which leads to lot of confusion when using both plugins together. As you specifically asked for the gradle idea plugin, I used this plugin and imported into IntelliJ as plain java project.
But to answer your question I found no evidence that the order of libraries on the classpath differs from the order as declared in the dependencies section of the gradle file, when using a flatDir repo. When using compile fileTree(dir: 'libs', include:['*.jar']) the order was actually broken as described in your question. That is, you should stick to using a flatDir repo.
I'm using gradle 4.9 and IntelliJ 2018.2.
This is my gradle file
apply plugin: 'java'
apply plugin: 'idea'
repositories {
jcenter()
flatDir {
dirs 'libs'
}
}
dependencies {
compile 'zzz:zzz-0.0.0'
compile 'aaa:aaa-0.0.0'
compile 'com.google.guava:guava:24.0-jre'
compile group: 'javax.websocket', name: 'javax.websocket-api', version: '1.1'
}
task wrapper(type: Wrapper) {
gradleVersion = '4.9'
distributionUrl = "http://services.gradle.org/distributions/gradle-${gradleVersion}-bin.zip"
}
In my libs folder there are two jars aaa-0.0.0.jar and zzz-0.0.0.jar both are copies of guava-24.0-jre.jar. That is all guava classes are present in both jars as well. As zzz:zzz-0.0.0 is the first dependency in the gradle file, the expectation would be that guava classes are being loaded from zzz-0.0.0.jar instead of guava-24.0-jre.jar or aaa-0.0.0.jar. I used the following main class to test this:
package test;
import com.google.common.math.LongMath;
public class Test {
public static void main(String[] args) throws Exception {
System.out.println(LongMath.class.getProtectionDomain().getCodeSource().getLocation().toURI());
}
}
And the output when running it from IntelliJ is
file:/C:/ws/gradle-idea-test/libs/zzz-0.0.0.jar
That is the com.google.common.math.LongMath class is indeed being loaded from the local libs/zzz-0.0.0.jar instead of the guava-24.0-jre.jar.
I noticed that the list of external dependencies in IntelliJ doesn't show the local libraries. And even more confusing the libraries are ordered alphabetically and don't reflect the actual order on the classpath which might be quite confusing:
To get the actual order of elements on the classpath you will have to look in the module dependencies section in the module settings ("Open Module Settings" > "Project" > "Modules" > "Dependencies Tab") which looks like this:
As you can see the dependencies are listed in correct order and include the local libraries as well. The order of libs in this dialog is basically the same as in the generated iml-file.
When using the IntelliJ gradle plugin instead of gradle's idea plugin, IntelliJ basically behaved the same way but the generated iml-file looked different and the external libraries were displayed in a different format. But there was no difference regarding the classpath order.
I am trying to get Gradle to select different dependencies in my multiproject build based on whether I am building for desktop or for Android. I have a common subproject (a library) I am trying to reuse. However, I cannot get Gradle to correctly switch dependency configurations.
My main settings.gradle simply includes all the dependencies:
// /settings.gradle
rootProject.name = 'myProject'
include 'androidUI'
include 'reusableLibrary'
include 'desktopUI'
Now both androidUI and desktopUI specify reusableLibrary as a dependency:
// /androidUI/build.gradle and /desktopUI/build.gradle
apply plugin: 'java'
dependencies {
compile project(path: ':reusableLibrary', configuration: 'desktop')
}
reusableLibrary itself specifies two configurations, because its dependencies are different whether it's building on desktop or Android:
// /reusableLibrary/build.gradle
apply plugin: 'java'
configurations {
desktop {
extendsFrom compile
}
android {
extendsFrom compile
}
}
dependencies {
// Just examples, the real list is longer.
// The point is that h2database is only included on desktop,
// and ormlite is only included on Android.
android 'com.j256.ormlite:ormlite-jdbc:5.0'
desktop 'com.h2database:h2:1.4.192'
}
This looks fine to me. But when I compile either desktopUI or androidUI, I can see that although the dependencies of reusableLibrary are being included on the classpath in the manner I desire, the actual JAR provided by reusableLibrary itself is not included. This of course causes the build to fail. I suspect I'm not setting up reusableLibrary correctly; I'm not clear on what the configurations {} blocks do.
Why aren't the compiled items in reusableLibrary being included on the classpaths of the UI projects? And what is the canonical way to include platform-specific dependencies in this manner?
The original configuration is pretty close to right. The key is to understand this dependency graph from the Gradle Java plugin's documentation:
This is a visualization of the Java plugin's various dependency configurations, which is Gradle-ese for "list of dependencies." When you add compile lines to a dependencies {...} block, you're adding Dependency elements to the compile dependency list.
The default dependency configuration is special; it is the one included by a compile project("path") line unless a different one is chosen with the configuration: argument. This means that when you build the library, the runtime dependency list (which includes the compiled jar from the library itself) is added to the classpath of the client project.
The original configuration creates two new nodes, desktop and android in this graph, and couples them both to compile by using extendsFrom. They are not otherwise connected to the graph! Now the problem with the original configuration is apparent: by switching the upstream project to either of these, it is missing the compiled code from runtime. This explains the classpath omission.
The solution is a bit more subtle than just aiming desktop and android at runtime. In order to ensure that everything is correctly decoupled when we add tests, we need one extra layer of dependency configurations to keep testCompile from indirectly depending on runtime. Additionally, the library's source code itself may need things on its classpath just to typecheck; we can use compileOnly for this. The end solution looks like this:
configurations {
desktopCompile
androidCompile
compileOnly.extendsFrom desktopCompile
testCompile.extendsFrom desktopCompile // Assuming tests run on the desktop
desktop {
extendsFrom desktopCompile
extendsFrom runtime
}
android {
extendsFrom androidCompile
extendsFrom runtime
}
}
dependencies {
androidCompile "some.android:dependency"
desktopCompile "other.desktop:dependency"
}
What would be the easiest way to tell Gradle the following:
Retrieve 'junit' dependency and take its latest 'release' version.
Managing Maven and Ivy repositories is sort of new to me. I tried the following steps and they result in Could not resolve dependency ... error:
Write compile "junit:junit:latest.release" with repositories set to only mavenCentral() (however, it works if I say "junit:junit:4.10").
Write compile "junit:junit:latest.release" with repository set the following way:
ivy {
// I also tried 'http://maven.org' and other possible variants.
url "http://repo1.maven.org"
layout "maven"
}
Attempted to use Spring Source Ivy repository:
ivy {
artifactPattern "http://repository.springsource.com/ivy/libraries/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
ivyPattern "http://repository.springsource.com/ivy/libraries/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
}
Maybe I misunderstand something. Why would getting the latest version of the dependency be such a hard task?
It can be quite useful sometimes to get the latest release - if for example you release often your own dependencies.
You can get the latest version like
compile "junit:junit:+"
or better specify at least the major version like
compile "junit:junit:4.+"
Gradle currently does not support Maven's RELEASE (which is rarely used and deprecated) but it does support Ivy's latest.release (and for snapshots latest.integration). However, the general recommendation is to build against exact versions. Otherwise, the build can become a lottery.
Check out the Gradle-Versions-Plugin. It does exactly what you want: https://github.com/ben-manes/gradle-versions-plugin
For the installation, see the github page. Basically you need to add these two lines to your build.gradle - project file:
apply plugin: 'com.github.ben-manes.versions'
buildscript {
[...]
dependencies {
classpath 'com.github.ben-manes:gradle-versions-plugin:0.8'
[...]
}
}
[...]
Then you can use the plugin, by running this command in terminal in your project dir:
./gradlew dependencyUpdates -Drevision=release
And it will show you which dependencies are outdated!
Latest Gradle User Guide mentions and explains plus sign in versions:
From 7.2. Declaring your dependencies:
dependencies {
compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
... The build script also states that any junit >= 4.0 is required to compile the project's tests.
From 23.7. How dependency resolution works:
If the dependency is declared as a dynamic version (like 1.+), Gradle will resolve this to the newest available static version (like 1.2) in the repository. For Maven repositories, this is done using the maven-metadata.xml file, while for Ivy repositories this is done by directory listing.
In Android Studio:
If you're using + for the version, and want to know which version is actually being used, select Project in the sidebar, and then under External Libraries you will see the actual version number in use.
Another similar notation for Kotlin DSL (build.gradle.kts):
dependencies {
implementation("or.jsoup", "jsoup") {
version {
require("1.14.+")
}
}
// OR simply
// implementation("or.jsoup:jsoup:1.14.+")
}
Read more about this in Gradle documentations.
An excerpt from the docs:
A dynamic version can be either a version range (e.g. 2.+) or it can be a placeholder for the latest version available e.g. latest.integration.