I tried using the 'api' dependency keyword in my project , but I got this error saying it cannot find method api()
I tried it on a new project. this is the build.gradle file:
plugins {
id 'java'
}
group 'com.test'
version '1.0-SNAPSHOT'
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.12'
api group: 'com.google.guava', name: 'guava', version: '27.0.1-jre'
}
I am using gradle V4.9.
when I run gradle build I get this:
Could not find method api() for arguments [{group=com.google.guava, name=guava, version=27.0.1-jre}] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler
If I replace 'api' with 'implementation' everything works fine
What am I missing here?
Is there any setting that needs to be done?
The api configuration comes from the java-library plugin, in your build script you have just applied java plugin. See https://docs.gradle.org/current/userguide/java_library_plugin.html
The key difference between the standard Java plugin and the Java Library plugin is that the latter introduces the concept of an API exposed to consumers. A library is a Java component meant to be consumed by other components. It’s a very common use case in multi-project builds, but also as soon as you have external dependencies.
Just apply the java-library plugin (which extends java plugin) and it should work:
plugins {
id 'java-library'
}
For those using kotlin build scripts use the following:
plugins {
id("org.gradle.kotlin.kotlin-dsl")
}
Related
We've been using the Eclipse #NonNull and #Nullable annotations in our code for a while.
We are now adding some Spring projects defined with Gradle to our system. These projects will share quite a bit of code with our standalone projects as well.
We are seeing a problem due the Eclipse annotations (being compile time checking) don't work when a Spring/Gradle project refers to the shared code via Gradle generated .jar file. Eclipse needs to have the source of the shared jar in order for the annotations to work. Attaching the source in the Eclipse project only works until you need to do a Gradle Refresh, as that rebuilds the eclipse .project and .classpath files.
It's also a problem that you have to explicitly rebuild the shared .jar each time you make a change to the shared code. It's not done automatically.
I haven't found a way to have the Spring/Gradle projects just use a 2nd source directory for the shared code, and not need to have the shared code as a generated .jar file.
Is there any good way to have shared code between multiple Gradle projects in Eclipse - without using an intermediate .jar file? (Or some other way to get the Eclipse annotations to work.)
Not really sure how to give a full example, as most of this is gradle and eclipse configuration.
Here are the Gradle config files: settings.gradle
pluginManagement {
repositories {
maven { url 'https://repo.spring.io/milestone' }
gradlePluginPortal()
}
}
rootProject.name = 'App1-Account-Manager'
and build.gradle
plugins {
id 'org.springframework.boot' version '2.5.0-RC1'
id 'io.spring.dependency-management' version '1.0.11.RELEASE'
id 'java'
}
group = 'com.efi'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'
repositories {
mavenCentral()
maven { url 'https://repo.spring.io/milestone' }
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
implementation 'org.springframework.boot:spring-boot-starter-security'
implementation 'org.springframework.boot:spring-boot-starter-web'
implementation group: 'io.jsonwebtoken', name: 'jjwt', version: '0.2'
implementation 'org.springframework.boot:spring-boot-starter-amqp'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
testImplementation 'org.springframework.amqp:spring-rabbit-test'
implementation files('lib/eflow/eFlowClientApi.jar',
'lib/eflow/eFlowCryptography.jar',
'lib/eflow/json-simple-1.1.1.jar',
'lib/eflow/commons-codec-1.4.jar',
'lib/eflow/commons-io-2.6.jar',
'lib/eflow/commons-lang-2.6.jar',
'lib/eflow/commons-logging-1.2.jar',
'../App1-Commons/build/libs/App1-Commons-0.0.1-SNAPSHOT.jar'
)
implementation group: 'org.eclipse.jdt', name: 'org.eclipse.jdt.annotation', version: '2.1.100'
implementation group: 'com.google.code.gson', name: 'gson', version: '2.8.7'
runtimeOnly 'org.postgresql:postgresql'
testImplementation 'org.springframework.security:spring-security-test'
}
test {
useJUnitPlatform()
}
App1-Commons is the project of shared code that multiple other projects depend on. That's where a bunch of the #NonNull annotations are.
I can set the App1-Account-Manager project to depend on the App1-Commons project in eclipse - but as soon as you run a Gradle Refresh, it looses that connection.
I'd prefer to just have the source from App1-Commons included in the App1-Account-Manager project - but I don't see how to configure Gradle to do that with Eclipse projects.
I think I found the solution. I need to add a SourceSets block to the build.gradle file like this:
sourceSets {
main {
java {
srcDir 'src/main/java'
srcDir '../App1-Commons/src/main/java'
}
}
}
And remove the reference to the App1-Commons jar file.
I have included the build.gradle for the tutorial application that I am working through. Everything works with it, the only question that I have is what the "compile group" down at the bottom does, and what the different parts of it does? I was told to just copy the code, but I wanted to know more about what this actually did. (I copied the compile group from the maven repository website, so I know that it is valid code)
group 'PledgeToVote'
version '1.0-SNAPSHOT'
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:2.1.5.RELEASE")
}
}
apply plugin: 'java'
apply plugin: 'org.springframework.boot'
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
dependencies {
compile group: 'org.springframework.boot', name: 'spring-boot-starter-web', version: '2.1.5.RELEASE'
}
Thank you for any help you can provide!
compile is a configuration in Gradle terminology.
Configurations have different roles in Gradle:
a bucket of dependencies
Resolvable: that is a dependency graph can be computed and used, for example to generate a classpath
Consumable: this is how projects share artifacts and dependencies.
For more information on these topics, I recommend the following webinar (Note: I am a co-presenter in this webinar).
In addition, compile has been deprecated in favour of implementation and api for a while. See the documentation for more details on this.
I have a java project made by some sibling modules. One of these modules is a library and I'm applying java-library plugin on it. All the other modules depend on it.
What I need to do is to automate the creation of a zip for each module, containing all the classes and all the dependencies needed for it to work (I'm deploying the zip as aws-lambda functions).
So far this is what I have achieved, but the resulting zip only contains module's classes. I thought that the problem might be the type of dependency I'm using (implementation) and I tried switching to the default one but gradle doesn't even success in building.
apply plugin: 'java'
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
task buildZip(type: Zip) {
from compileJava
from processResources
from configurations.runtime
}
dependencies {
implementation project(':utils')
testCompile group: 'junit', name: 'junit', version: '4.12'
}
After some testing, I think I have the answer.
First: the order you declared the task and the dependencies is fine! It's OK to use a configuration before it's populated. I only say this because I indicated in my comments that it might be an issue.
Second, the issue here is the use of configurations.runtime. This does not extend implementation and api, so those dependencies are not included. runtime has been superseded by runtimeOnly, which hopefully makes the behaviour clear.
The following task definition should work:
task buildZip(type: Zip) {
from compileJava
from processResources
from configurations.runtimeClasspath
}
I am trying to setup Google protobuf with netty, but when I start compilation gradle first download google protobuf (at least at the first attempt) but then at compilation it just tells me :
/src/main/java/GameMoveOuterClass.java:1536: error: package com.google.protobuf.GeneratedMessageV3 does not exist
com.google.protobuf.GeneratedMessageV3.FieldAccessorTable
here is my build.gradle :
apply plugin: 'java'
apply plugin: 'com.google.protobuf'
repositories {
mavenCentral()
}
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.0'
}
}
dependencies {
compile group: 'io.netty', name: 'netty-all', version: '4.1.5.Final'
compile group: 'com.google.protobuf', name: 'protobuf-java', version: '2.4.1'
}
jar {
manifest {
attributes("Main-Class": 'server.Server',
"Class-Path": configurations.compile.collect { it.getPath() }.join(' '))
}
}
If someone knows what's wrong, please let me know
Thanks
You're using the version 2.4.1 of protobuf which doesn't come with GeneratedMessageV3.
Update to a new version of protobuf which include this class like the 3.0.0
dependencies {
compile group: 'io.netty', name: 'netty-all', version: '4.1.5.Final'
compile group: 'com.google.protobuf', name: 'protobuf-java', version: '3.0.0'
}
Using the maven central advanced search for com.google.protobuf.GeneratedMessageV3 it seems that the class is in com.google.cloud:google-cloud-nio:xxx or maybe com.trueaccord.scalapb:protobuf-runtime-scala_yyy:zzz. I'm guessing you'll need to add one of these to your classpath.
I am not familiar with Gradle but it looks to me like you are mixing new protobuf generated code with an older protobuf library, which is not supported. The GeneratedMessageV3 class was added only recently (around 3.0 I believe), and so new generated code that references that class cannot be linked against an older library which does not include it.
In my scenario, both my app and library module should add
implementation 'com.google.protobuf:protobuf-javalite:3.9.1'
even app has a dependency on library
I am trying to migrate my maven project to gradle. I specify spring version for all the project in variable springVersion. But from some reason build fails on one particular dependency org.springframework:spring-web:springVersion. When I type the version directly org.springframework:spring-web:3.1.2.RELEASE everything compiles. Here is my build.gradle file:
subprojects {
apply plugin: 'java'
apply plugin: 'eclipse-wtp'
ext {
springVersion = "3.1.2.RELEASE"
}
repositories {
mavenCentral()
}
dependencies {
compile 'org.springframework:spring-context:springVersion'
compile 'org.springframework:spring-web:springVersion'
compile 'org.springframework:spring-core:springVersion'
compile 'org.springframework:spring-beans:springVersion'
testCompile 'org.springframework:spring-test:3.1.2.RELEASE'
testCompile 'org.slf4j:slf4j-log4j12:1.6.6'
testCompile 'junit:junit:4.10'
}
version = '1.0'
jar {
manifest.attributes provider: 'gradle'
}
}
ERROR MESSAGE:
* What went wrong:
Could not resolve all dependencies for configuration ':hi-db:compile'.
> Could not find group:org.springframework, module:spring-web, version:springVersion.
Required by:
hedgehog-investigator-project:hi-db:1.0
The same is with org.springframework:spring-test:3.1.2.RELEASE when performing tests.
Whats causing he problem and how to solve it?
You are using springVersion as the version, literally. The correct way to declare the dependencies is:
// notice the double quotes and dollar sign
compile "org.springframework:spring-context:$springVersion"
This is using Groovy String interpolation, a distinguishing feature of Groovy's double-quoted strings. Or, if you want to do it the Java way:
// could use single-quoted strings here
compile("org.springframework:spring-context:" + springVersion)
I don't recommend the latter, but it hopefully helps to explain why your code doesn't work.
Or you can define lib version via variable in dependencies like this:
dependencies {
def tomcatVersion = '7.0.57'
tomcat "org.apache.tomcat.embed:tomcat-embed-core:${tomcatVersion}",
"org.apache.tomcat.embed:tomcat-embed-logging-juli:${tomcatVersion}"
tomcat("org.apache.tomcat.embed:tomcat-embed-jasper:${tomcatVersion}") {
exclude group: 'org.eclipse.jdt.core.compiler', module: 'ecj'
}
}