I build my project using Gradle 1.0 and I want to use the application plugin to create an application distribution package.
Instead of the generated start scripts I want to provide my own.
How can I skip the CreateStartScripts task?
It appears to be hard-coded, so I am guessing there is no easy way to override it. Maybe hacking the read-only startScripts.outputs property will work.
Either way, I would recommend you just create your own archive task. Here is one that does pretty much exactly what distZip does, but without the startScripts (borrowed from ApplicationPlugin.groovy).
task myDist(type: Zip){
def baseDir = { archiveName - ".zip" }
into(baseDir){
from(project.file("src/dist"))
into("lib") {
from(jar)
from(project.configurations.runtime)
}
}
}
Related
I have a Java application and I'm configuring the build using Gradle.
I believe this is the relevant part of my build.gradle:
apply plugin: 'application'
apply plugin: 'java'
build {
version = new JsonSlurper().parseText(file('/path/to/metadata.json').text).version
}
distZip {
archiveName project.name + "-" + project.version + ".zip"
}
So, I'm getting the version from an external source e.g. metadata.json.
I'm successful building the build/distributions/projectName-version.zip
and I'd love to be able to create antoher zip file named projectName-latest.zip along with that. How hard could that be?
My Gradle knowledge is far from great, but I've spent too much time trying to find a way to insert a simple copy command with the two params right after distZip completes.
For the copy itself, I recommend looking at the extensive documentation on the topic. But in short, you will use a copy task.
As for triggering that task, you have different options, depending on what you want to achieve:
If you are used to invoke assemble or build, you probably want that same invocation to produce this additional archive. You could do that by having the copy task dependsOn(distZip) and assemble.dependsOn(myCopyTask)
If you are used to invoke distZip, then you could (slightly ab)use the finalizedBy concept and have distZip.finalizedBy(myCopyTask). However this will run the copy task even if distZip fails.
Apply a combination of the two items above to cover all your bases.
Ideally, I would recommend going with 1, which works when invoking assemble or build.
I am new to gradle builds. I wrote a custom service for cloudera manager which needs to build a JAR file with few directories. It is a simple archive file with few directories(descriptor, images and scripts). I created it with below jar command manually.
jar -cf CSDNAME.jar descriptor images scripts
Now I want to include this as part of gradle build for which I need to write a task. I searched online where I found java related stuff which is not required in my case. Can someone help with this?
That's a code snippet using the kotlin dsl. It's based on the JAR task of the java plugin.
plugins {
java
}
tasks.jar {
doFirst {
archiveBaseName.set("CSDNAME") // By default the JAR will have the project name
from("content") // source folder where you have your content
}
}
N.B: If you already have a build file, you will need to change its extension to .kts, else you'll need of course to create one.
looks like gradle still not mature when compared to maven.many handy features not available in gradle.
is there any Gradle inbuilt feature equivalent to Maven's “copy-dependencies” without writing gradle task..?
Please check installDist task of distribution plugin.
You have to write code like this:
distributions {
main {
baseName = 'someName'
contents {
from { 'src/readme' }
into { '../../' } // <----- change destination here
}
}
}
This plugin will create distribution installation, which will also copy all runtime dependencies.
I want to have this code snippet
test {
testLogging.showStandardStreams = true
}
Shared for all my gradle projects. Is that possible? Preferrably something I add to ~/.gradle/common.gradle or similar.
Probably the best way to inject build logic into existing build scripts without touching them is using init scripts. So you can create a script like testlogging.gradle that looks like this:
allprojects {
tasks.withType(Test) {
testLogging.showStandardStreams = true
}
}
As you can see I use tasks.withType(Test) instead of test here to reference the test task by type. That has some benefits:
this script works also for builds with no task with name test. This could likely happen (e.g. in multiproject builds)
this script would also apply for any other tasks in your build that are of type Test. Some projects use integTest etc.
To auto apply this script on your machine, you can put it in the folder ~/.gradle/init.d. Gradle considers every .gradle file in there as init script and applies them to each build.
To learn more details about init scripts check the according chapter in the gradle userguide.
I'm working on a project that uses EJB2s. The created EJB Jars require additional processing by the application server before they're bundled in the war/ear and deployed.
I have created a custom task that works to do the additional processing if I invoke it explicitly (gradle ejbDeploy), but am having trouble fitting it into the gradle multi-project lifecyle. I need to somehow add it to the build graph to execute automatically after the jar task.
My first attempt was to add it to jar with
jar.doLast{
ejbDeploy.execute()
}
which seems to work for arbitrary code blocks, but not for tasks
What's the recommended solution for this? I see three approaches:
Hook into the build graph and add it explicitly after the jar
task.
Set it up somehow in jar.doLast{}
Set it up as a prerequisite for the WAR task execution
Is there a recommended approach?
Thanks!
I would go for approach #3 and set it up as a dependency of the war task, e.g.:
war {
it.dependsOn ejbDeploy
...
}
I'm new to Gradle, but I would say the answer really depends on what you're trying to accomplish.
If you want to task to execute when someone runs the command gradle jar, then approach #3 won't be sufficient.
Here's what I did for something similar
classes {
doLast {
buildValdrConstraints.execute()
}
}
task buildValdrConstraints(type: JavaExec) {
main = 'com.github.valdr.cli.ValdrBeanValidation'
classpath = sourceSets.main.runtimeClasspath
args '-cf',valdrResourcePath + '/valdr-bean-validation.json'
}
Add the following, and then ejbDeploy will be executed right after jar, but before war
jar.finalizedBy ejbDeploy
See Gradle Docs. 18.11. Finalizer tasks