Currently I'm trying to migrate my project to gradle from maven and to do so I'm creating a custom script which generates gradle build files from pom files taking into account all project specifics.
Script generates "build-generated.gradle" file which is meant to be executed on configuration phase from build.gradle file.
//Text of common build.gradle:
println "Configuring ${project.name}"
apply from: 'build-generated.gradle'
The problem is that when I try to run "gradle build" the result is not what I'm expecting:
An initialization phase all subprojects are included and futhermore I can print names of all subprojects using
subprojects{
println "I'm ${project.name}"
}
but at configuration and execution phase the subproject's build.gradle files are not executed.
What am I doing wrong?
The issue was adding root project into include chain in settings.gradle
Related
I'm using the latest version (7.1.2) of the ShadowJar (Gradle) plugin to build the application's JAR. I'm trying to exclude some dependencies from the resultant JAR, so I have configured the plugin like:
import com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar
...
tasks.withType(ShadowJar) {
final def attributes = [
// ...all the attributes here
]
dependencies {
// Dependencies that are already provided in the lib/ folder of Apache Flink
exclude(dependency("org.apache.flink:flink-clients_2.12"))
exclude(dependency("org.apache.flink:flink-java"))
exclude(dependency("org.apache.flink:flink-streaming-java_2.12"))
}
manifest.attributes(attributes)
mergeServiceFiles()
minimize()
setZip64(true)
}
It's not clear to me what dependencies are actually begin excluded/included — when unzipping and visually analyzing the generated ZIP file(s). I've been trying to compare the generated (ZIP) -shadow file with the one generated by the distZip task, but the -shadow one doesn't have a single JAR on it...only classes.
So I'm wondering if there is a way to print the effective group of dependencies that are going to be part of the final JAR file.
Based on the ShadowJar's documentation, the default configuration is to merge all dependencies from the project's runtimeClasspath, but ./gradlew dependencies --configuration runtimeClasspath doesn't account for the excluded ones.
After I started using the spring boot gradle plugin in my gradle.build file, the build fails on jenkins.
classpath("org.springframework.boot:spring-boot-gradle-plugin:2.0.2.RELEASE")
Things work fine locally including build, test and webapp runs fine with Jetty. The only problem is the build fails on Jenkins in the task artifactoryPublish. It says:
File '/var/lib/jenkins/jobs/release-my-project/workspace/build/libs/workspace-0.2.1-SNAPSHOT.jar' does not exists, and need to be published!
Not sure what's going with the gradle artifactoryPublish task. I think the task comes from Jenkins.
Before using the spring boot gradle plugin, my jar task in gradle.build is as follows:
jar {
baseName = 'my-project'
from {
configurations.compile.collect {
it.isDirectory() ? it : zipTree(it)
}
configurations.runtime.collect {
it.isDirectory() ? it : zipTree(it)
}
}
manifest {
attributes 'Main-Class':'com.example.Application'
}
// Exclude manifest signature files
exclude 'META-INF/*.SF', 'META-INF/*.DSA', 'META-INF/*.RSA', 'META-INF/LICENSE'
}
Since the spring boot gradle plugin disables the jar task, and replaces it with the bootJar task, so I configured the bootjar task as follows:
bootJar {
baseName = 'my-project'
mainClassName = 'com.example.Application'
// Exclude manifest signature files
exclude 'META-INF/*.SF', 'META-INF/*.DSA', 'META-INF/*.RSA', 'META-INF/LICENSE'
}
One thing I noticed from jenkins log is that it says the file workspace-0.2.1-SNAPSHOT.jar does not exist. Seems like it is looking for the wrong file. Previously, it looked for the correct file my-project-0.2.1-SNAPSHOT.jar. When I built locally, this jar file was created. Not sure what made jenkins look for workspace-0.2.1-SNAPSHOT.jar. It is supposed to be my-project as I did define baseName inside the bootJar task.
Any idea what's wrong here? Thanks.
Unless you explicitly define the name of the project, Gradle will use the directory name as the project name. On Jenkins, the project directory is called "workspace". artifactoryPublish is presumably using the project name to determine the name of the JAR file to publish. That's not good practice if that's the case.
Anyway, you really should set the name of your project. You won't have to explicitly set baseName on the Jar tasks then. Simply add a settings.gradle file in the root of the project, i.e. next to the build.gradle file, and set its content to:
rootProject.name = "my-project"
That should hopefully fix the problem, although it really depends on what the artifactoryPublish task is doing.
I would want to extend Peter's answer, it is recommended by the authors of Gradle that we should use settings.gradle
Define the root project name in the settings file: The ´rootProject.name´ effectively assigns a name to the build as a whole, which is used in reports like build scans. If the root project name is not set, the name will be the container directory name, which can be unstable (i.e. you can check out your project to any directory).
I'm playing around with a Gradle java project, and I'm having a difficult time getting annotation processor's to run. For some reason when I run an intellij configuration (pictured below), the annotation processors aren't running. I'm assuming this is because the configuration has the Make command configured to run before launch. The annotation processors seem to run when assemble or build is called.
The issue is reproducible when calling ./gradlew clean make. I don't have that issue when calling ./gradlew clean assemble, or ./gradlew clean build. What's the best practice for getting around this?
IntelliJ needs Annotation Processing enabled for the project. Here is an image that details where you can enable Annotation Processing for IntelliJ:
Preferences > Build, Exection, Deployment > Compiler > Annotation Processors > Check "Enable annotation processing"
make sure that Annotation Processing is enabled for your project (as described by #spierce7)
also make sure that apply plugin: 'idea' is in your build.gradle
sample build.gradle snippet:
plugins {
id "net.ltgt.apt" version "0.5"
}
apply plugin: 'java'
apply plugin: 'idea'
...
dependencies {
compile 'com.google.dagger:dagger:2.10'
apt 'com.google.dagger:dagger-compiler:2.10'
}
from: https://github.com/tbroyer/gradle-apt-plugin (github for net.ltgt.apt plugin)
IntelliJ IDEA
When the idea plugin is applied, the idea task will auto-configure the
generated files to enable annotation processing in intelliJ IDEA.
When using the Gradle integration in IntelliJ IDEA however, rather
than the idea task, you'll have to manually enable annotation
processing: in Settings… → Build, Execution, Deployment → Compiler →
Annotation Processors, check Enable annotation processing and Obtain
processors from project classpath. To mimic the Gradle behavior and
generated files behavior, you can configure the production and test
sources directories to build/generated/source/apt/main and
build/generated/source/apt/test respectively and choose to Store
generated sources relative to: Module content root.
Note that starting with IntelliJ IDEA 2016.1, you'll have to uncheck
Create separate module per source set when importing the project.
In any case, the idea plugin has to be applied to the project.
An alternative, starting with IntelliJ IDEA 2016.3, is to delegate the
IDE build actions to Gradle itself:
https://www.jetbrains.com/idea/whatsnew/#v2016-3-gradle
You are not applying the APT plugin
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.3.0'
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
And
apply plugin: 'com.neenbedankt.android-apt'
Or for the core, its pure-Java alternative:
https://plugins.gradle.org/plugin/net.ltgt.apt
Also try using apt instead of providedCompile
(this is using gradle 2.4)
For one of my projects, split into several submodules, I use the shadow plugin which works very well for my needs; it has a main, and as recommended by the plugin's README, I use the application plugin in conjuction with it so that the Main-Class is generated in the manifest, all works well.
Now, this is a SonarQube plugin project, and I also use (successfully!) the gradle sonar packagin plugin. And what this plugin does is, when you ./gradlew build, generate the sonar plugin instead of the "regular" jar.
I wish to do the same for my subproject here, except that I want it to generate only the shadow jar plugin instead of the "regular" plugin... Right now I generate both using this simple file:
buildscript {
repositories {
jcenter();
}
dependencies {
classpath(group: "com.github.jengelman.gradle.plugins",
name:"shadow", version:"1.2.1");
}
}
apply(plugin: "application");
apply(plugin: "com.github.johnrengelman.shadow");
dependencies {
// whatever
}
mainClassName = //whatever
artifacts {
shadowJar;
}
// Here is the hack...
build.dependsOn(shadowJar);
How do I modify this file so that only the shadow jar is generated and not the regular jar?
You could disable the jar task by adding the following lines to your gradle script:
// Disable the 'jar' task
jar.enabled = false
So, when executing the gradle script, it will show
:jar SKIPPED
If you wish to configure all sub-projects, then you can add the following into your root build.gradle
subprojects {
// Disable the 'jar' task
tasks.jar.enabled = false
}
My build.gradle looks like:
apply plugin: 'war'
war {
...
}
I build using gradle war
In the configuration phase, I want to run git submodule update --init --recursive
so I changed my build.gradle to:
apply plugin: 'war'
task configured(type: Exec) {
commandLine "git submodule update --init --recursive"
}
war {
...
}
when I do gradle war:
FAILURE: Build failed with an exception.
What went wrong:
Could not determine the dependencies of task ':war'.
I do not see my submodules being updated. What is wrong?
EDIT:
I put following line in settings.gradle
exec {
commandLine "git", "submodule", "update", "--init", "--recursive"
}
I removed task configured from build.gradle.
Do you thing thats a good solution??
In the configuration phase, I want to run git submodule update --init --recursive
Your current build is doing this in the execution phase. Why do you want to do it in the configuration phase? Note that this will slow down every single invocation of Gradle.
I do not see my submodules being updated. What is wrong?
Only tasks specified on the command line and their task dependencies will be run. If you don't specify configured on the command line, nor make (say) war depend on it, it won't be run.
What went wrong: Could not determine the dependencies of task ':war'.
Apparently there is some problem in the remainder of your build script (which you didn't show). Perhaps you were trying to do something like war.dependsOn(configured), and didn't get it quite right.