I've been having this issue on and off for the past few weeks after beginning to learn how to use Gradle.
I added the dependency to my build.gradle file
compile group: 'org.apache.xmlgraphics', name: 'batik-all', version: '1.12', ext: 'pom'
I used VSCode's command palette to "refresh", cleaned the server workspace and ran gradle build but the new dependency does not show up in my "Project and External Dependencies" and I cannot import org.apache.batik.*
Hoping to find a fix for this in VSCode as I have seen some other IDE specific fixes.
So the issue was that in the map notation you were specifying the ext: 'pom' part. This effectively told Gradle to only import the POM file and not treat the dependency as a regular one.
When you moved to the different notation, you did not keep that pom element in the coordinates and so you got the right behaviour.
Note: compile has been replaced by implementation for a while now and is even deprecated in Gradle 6.x. Have a look at the documentation for more information on this.
Related
I know this has been asked multiple times but the questions have multiple answers.
I'm trying to use a Java package that's a dependency of my dependency. Let's say I've built this gradle project called "ee_tools". And that has a dependency called "my_models", which has a package called "com.mycompany.my_models.db". So in the ee_tools project build.gradle, I've got
dependencies {
// My stuff
implementation group: "com.mycompany", name: "my_models", version: "1.0.0"
}
Then in my current project, I've got
dependencies {
// My stuff
implementation group: "com.mycompany", name: "ee_tools", version: "1.0.0"
Shouldn't this mean that the public classes in my_models are accessible through ee_tools to my current project? Gradle was able to find both in my artifactory instance. And the gradle dependencies command shows ee_tools under the compileClasspath, implementation, and testCompileClasspath trees, but not with its children dependencies. It also shows up in the runtimeClasspath and testRuntimeClasspath trees with its children dependencies, including my_models.
I am also able to see that package inside the jar on the left side of IntelliJ, under the "External Libraries" tree, along with some classes.
But when I try to use the my_models package in my current project, IntelliJ can't find it and it fails a gradle build with the error
error: package com.company.my_models.db does not exist
It can't find any package in that dependency. What gives? Am I declaring the dependencies incorrectly? Or is this a gap between the gradle binary in my command line vs IntellJ and gradlew?
If ee_tools depends on my_models, then your gradle file in ee_tools should be like
implementation project(path: ":path:to:my_models", configuration: 'default')
:path:to:my_models is defined in settings.gradle in project root path like this:
include ':path:to:my_models'
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’
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 have a problem where I’m trying to include org.json as a dependency in my gradle/spring boot project. In my build.gradle I have
dependencies {
compile("org.springframework.boot:spring-boot-starter-web")
compile("org.springframework.boot:spring-boot-starter-security")
compile("org.json:json:20141113")
}
But in the editor window it looks like IntelliJ is not able to import org.json - it’s unable to find the package
What’s weird is that I can run the gradle ‘build’ task without errors in IntelliJ, and I can run
./gradlew clean build && java -jar build/libs/MyApp-0.1.0.jar
and it works fine.
Is this a ‘fat jar’ problem? I’m not sure it is because org.json is definitely not in my class path on the command line. Any advice appreciated.
I was able to successfully download json in my gradle dependencies:
implementation 'org.json:json:20171018'
As some mentioned, mvnrepository provides snippet for different Build systems.
After you choose your desired version, in the middle of the page, select Gradle as build system, copy and paste the snippet in your build.gradle file, section dependencies in your java project.
// https://mvnrepository.com/artifact/org.json/json
compile group: 'org.json', name: 'json', version: '20180813'
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.