Heres our code:
dependencies {
implementation project(path: ':openCVLibrary3')
implementation project(path: ':DogeCV')
}
apply from: '../build.common.gradle'
It results in error:
ERROR: Could not find method implementation() for arguments [DefaultProjectDependency{dependencyProject='project ':openCVLibrary3'', configuration='default'}] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
Thank you!
The implementation configuration is also created by java plugin. So you will have to apply that plugin to be able to use that configuration. If you are applying the plugin from the build.common.gradle build file, move the line that references that to above the dependencies block so the plugin gets applied before you attempt to use the things it provides.
If you are doing this already, it could also be happening if you are on an older version of Gradle. Ensure that you are on Gradle 3.4 or later (or you have to use compile instead).
Related
I'm new to Gradle so I have awfully big problems and one of them is about the Oracle JDBC driver. I just want to get connection to DB and I already used a JDBC driver in my previous project, but that did not use Gradle. Now, I see that I have to show dependency on driver, but this just didn't work. I already used all of the advice I found:
I tried to add connector.jar to VM options,
to create dependency with implementation("com.oracle.database.jdbc:ojdbc8:21.1.0.0"), but it simply doesn't work.
After I use compile 'com.oracle:ojdbc8:21.1.0.0', I got Could not find method compile() for arguments [com.oracle:ojdbc8:21.1.0.0] and that's just killing me.
I also tried to use local Maven repository and I have downloaded .jar, but it doesn't work either.
I also just tried to add this lib dependency in IntelliJ, using File->Project Structure->+ and creating ojdbc8 class with path to this file directly.
Full version of my build.gradle file:
plugins {
// Apply the application plugin to add support for building a CLI application in
Java.id 'application'
}
repositories {
// Use Maven Central for resolving dependencies.
mavenCentral()
mavenLocal()
}
dependencies {
implementation("com.oracle.database.jdbc:ojdbc8:21.1.0.0")
compile 'com.oracle:ojdbc8:21.1.0.0'
// Use JUnit test framework.
testImplementation 'junit:junit:4.13.2'
implementation 'com.h2database:h2:1.4.199'
implementation 'org.hibernate:hibernate-core:5.4.2.Final'
// This dependency is used by the application.
implementation 'com.google.guava:guava:30.1.1-jre'
}
application {
mainClass = 'model.App'
}
I'd like to use this JDBC driver in one class, but I just can't. Can you help me, please?
can anybody help me solve this problem
Could not find method compile() for arguments [project ':moqui-util'] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
If you are using Gradle version 7.0+, then compile dependency configuration is removed from that. You might need to look for implementation dependency configuration in place of compile.
PS: Do not forget to rebuild your gradle file.
More info can be found here at my another answer for this deprecation.
https://stackoverflow.com/a/67695126/8148637
It looks pretty straightforward, but i didn't see many examples of what needs to be changed. This is what I had to do:
Anything like this, change from
compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.7.25'
to
implementation 'org.slf4j:slf4j-log4j12:1.7.25'
I also had to change the way mainClass is declared
mainClassName = 'package.MainClass'
to
application {
mainClass = 'package.MainClass'
}
To get to this, I had to delete the gradle files and folder, and do a gradle init to recreate the build configs and dependencies.
Use implementation, runtimeOnly, compileOnly etc. as the new equivalents
I have added some dependency in my build.gradle file like this
ext {
boxableVersion = '1.5.bq'
}
dependencies {
implementation group: "com.github.dhorions", name:'boxable', version:${boxableVersion}
}
This was working seamlessly until I changed my JDK version from 1.8 to 11. Now, When I am trying to build the project, the following error shows up in my build.gradle file
Could not run phased build action using Gradle distribution 'https://services.gradle.org/distributions/gradle-6.0-bin.zip'.
Build file '/home/christine/christine/projectsFromGit/pdfcreator/build.gradle' line: 43
A problem occurred evaluating root project 'pdfcreator'.
Could not find method $() for arguments [build_4fl1snfk49qgbmumnf1gg989h$_run_closure3$_closure11#d7c9f2a] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
If i give version directly like this, the project is building successfully
implementation group: "com.github.dhorions", name:'boxable', version:'1.5.bq'
How can i give versions externally like I was doing before?
The following syntax version:${boxableVersion} in your dependency declaration is not valid. It's not related to your JDK version, it's just that ${...} means nothing in Gradle DSL or Groovy syntax.
If you want to define version in an 'ext' property, you can then reference this property directly with version: boxableVersion (ext properties are made available directly in the script through the "groovy magic"), or you can use Groovy String interpolation notation (please note the double-quote ")
version: "${boxableVersion}"
Or , in a simpler way:
implementation "com.github.dhorions:boxable:${boxableVersion}"
Just try:
ext {
boxableVersion = '1.5.bq'
}
dependencies {
implementation group: "com.github.dhorions", name:'boxable', version:"${boxableVersion}"
}
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.
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.