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.
Related
I am currently in the process of re-organizing and re-structuring some of the projects we use at work.
One of my goals is to integrate a project's unit tests correctly. I have upgraded the root projects Gradle to the latest version (5.6.2) and I have made all the necessary DSL changes.
Right now I'm in the process of including the project's integration tests under its source code. For this I created a new subproject.
So far so good but when I attempt to build the project it fails with following exception:
Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'StartServerTask' for project ':integration-tests' of type org.gradle.api.Project.
at org.gradle.internal.metaobject.AbstractDynamicObject.getMissingProperty(AbstractDynamicObject.java:84)
at org.gradle.groovy.scripts.BasicScript$ScriptDynamicObject.getMissingProperty(BasicScript.java:156)
at org.gradle.internal.metaobject.AbstractDynamicObject.getProperty(AbstractDynamicObject.java:61)
at org.gradle.groovy.scripts.BasicScript.getProperty(BasicScript.java:65)
Now, the task in question comes for a Gradle plugin a colleague created in the past. Said plugin is fetched from a maven repository as a dependency like so:
buildscript {
repositories {
maven { url 'maven_link' }
}
dependencies {
classpath 'fts.gradle:start-server:0.3'
}
}
plugins {
id 'java'
id 'application'
id 'eclipse'
}
And applied like
apply plugin: 'fts.gradle'
I have tried almost everything, even changing the package structure of the plugin, but I am unable to include it properly in the build file.
If I copy paste the code directly within the project's build.gradle everything works fine but it doesn't so if I try to remote fetch and include the plugin.
Can anyone provide any insight to this?
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).
(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
}
I build my Android application using Gradle.
The dependency jar files are retrieved during compiling stage and the path of these jar files are dynamic (because there is build number in the path, for example, /home/user1/workspace/myapp/libs/privatejar/build-1019/a.jar).
My gradle configue file looks like this.
apply plugin: 'android'
android {
compileSdkVersion 19
buildToolsVersion "19.1.0"
applicationVariants.all { variant ->
variant.javaCompile.dependsOn('GetJarUsingCompanyPrivateProtocol')
}
}
dependencies {
compile files('local/path/of/company/private/jar')
}
task GetJarUsingCompanyPrivateProtocol {
// This command will retrieve the jar
// into folder "local/path/of/company/private/jar"
commandLine 'get_jar_command'
}
Because the jar files do not exist before executing gradle compile command for the 1st time, it will always complain "Class * can not be found".
However, if I execute gradle compile for the 2nd time, it will work.
So I have two questions here:
I have to change the local/path/of/company/private/jar every time when there is change to the build number of my jar files
Is there any chance to make my gradle script work for the 1st time?
I know I can execute get_jar_command and then trigger gradle build, but it is annoying, can I achieve it in one shot?
I finally found solution by myself.
Gradle build has three distinct phases:
Initialization
Configuration
Execution
The dependencies block will be executed during the configuration phase. So to use dependency jar in dependencies block, dependency jar must be download, either in initialization phase, or in configuration phase but before dependencies block execution.
In my case, initialization phase is not used. So I must ensure the dependency jar be downloaded before dependencies block. It's simply, adjusting the block sequence will be OK.
apply plugin: 'android'
android {
compileSdkVersion 19
buildToolsVersion "19.1.0"
applicationVariants.all { variant ->
variant.javaCompile.dependsOn('GetJarUsingCompanyPrivateProtocol')
}
}
task GetJarUsingCompanyPrivateProtocol {
// This command will retrieve the jar
// into folder "local/path/of/company/private/jar"
commandLine 'get_jar_command'
}
dependencies {
compile files('local/path/of/company/private/jar')
}
Note: logic in doLast of task will be executed in execution phase. That's why I use
task GetJarUsingCompanyPrivateProtocol {
commandLine 'get_jar_command'
}
Neither
task GetJarUsingCompanyPrivateProtocol {
doLast {
commandLine 'get_jar_command'
}
}
nor
task GetJarUsingCompanyPrivateProtocol << {
commandLine 'get_jar_command'
}
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