Idiomatic Gradle script to build 'debug' and 'release' JAR files
I'm trying to create a Gradle build script that will build a Java .jar file in 'release' or 'debug' modes and am having trouble parametrizing the script.
The question is: What is an idiomatic way to do this in a Gradle script, using the Java plugin? (or, if there's no idiomatic way, what's a hacky solution that actually works?)
I don't mind the method of parametrization, just as long as the command-line and IDE invocations can easily choose between the two output options. The jar file will be used as a library in other projects, eg an Android app and a JavaFX app, so I would like the method of parametrization to be invokable/depended-on from their own Gradle scripts.
Ideally I'd like to 'emulate' the Android gradle plugin's ability to have a Debug/Release version of every task, ie
$ ./gradlew build
$ ./gradlew assembleRelease
$ ./gradlew checkDebug
but failing that even a top level buildDebug and buildRelease would be suitable.
Stuff I tried
This section isn't really relevant to the question.
Starting point
I have the following gradle file/project:
group 'TestGradleProjectGroup'
apply plugin: 'java'
sourceCompatibility = 1.8
version '1.0-release'
compileJava {
options.debug = false
}
repositories {
mavenCentral()
}
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.11'
}
This works fine and produces the jar file:
$ ls TestGradleModule/build/libs/
TestGradleModule-1.0-release.jar
which, when the extracted classes are inspected with javap , doesn't contain any debug information. Hurrah. No we need a way to make a debug version.
Add debug & release tasks
version '1.0-release'
compileJava {
options.debug = false
}
task buildRelease(type: GradleBuild, dependsOn: build) {
project.version = '1.0-release'
compileJava {
options.debug = false
}
}
task buildDebug(type: GradleBuild, dependsOn: build) {
project.version = '1.0-debug'
compileJava {
options.debug = true
}
}
This didn't work, as the debug project is always built, even if buildRelease is the task given on the command line. I guess this is because the code for both tasks is run at Configuration time (Gradle build lifecycle), whereas I only want one to run. So I guess I want to run them at Execution time?
Add some doLast tasks
version '1.0-release'
compileJava {
options.debug = false
}
task buildRelease(type: GradleBuild, dependsOn: build) {
doLast {
project.version = '1.0-release'
compileJava {
options.debug = false
}
}
}
task buildDebug(type: GradleBuild, dependsOn: build) {
doLast {
project.version = '1.0-debug'
compileJava {
options.debug = true
}
}
}
This is even worse. The output file is always 1.0-release, and that's because of the 'default' at the top level. If I comment that out then a versioned jar is not made, instead the default of TestGradleModule.jar is made. It seems that the contents of the doLast blocks are completely useless in their effect upon the compileJava task (but there's no warning about this?). I guess these modifications are too late to be done at execution time, or that there's something else that needs to be done so that the compileJava tasks is "configured" differently?
Using Configurations?
I noticed the manual for the Java plugin contained a reference to buildConfigName and uploadConfigName , and claimed they depend on "The tasks which produce the artifacts in configuration ConfigName.". Given that I was failing to parametrize stuff at Configuration time, the plugin's ability to do that looked promising:
group 'TestGradleProjectGroup'
apply plugin: 'java'
sourceCompatibility = 1.8
configurations {
debug
release
}
version '1.0-release'
compileJava {
options.debug = false
}
repositories {
mavenCentral()
}
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.11'
}
but:
buildRelease or buildDebug to the output of ./gradlew tasks --all , as I expected it to. But I could run those tasks. buildRelease and buildDebug , not eg assembleRelease etc buildRelease didn't seem to depend on anything when run so therefore had no useful effect. Iterating tasks?
As a final attempt I've tried to create all of the appropriate tasks and linking the dependencies for everything. I tried iterating over the tasks and adding the dependencies:
gradle.taskGraph.whenReady { taskGraph ->
taskGraph.allTasks.each { taskIter ->
println("iterating" + taskIter)
def releaseTask = project.task(taskIter.name + "Release")
def debugTask = project.task(taskIter.name + "Debug")
taskIter.dependsOn += [releaseTask, debugTask].toSet()
println("new taskIter.dependsOn:" + taskIter.dependsOn)
/*
set debug mode here,
copy over effects of task to debug/release
disable effects of task
*/
}
}
but
In short, I have no idea what I'm doing. As a last resort I could just create all of the tasks manually, but that seems to defeat the point of using the the java plugin and is very spammy?
Do you need both jars to be created with a single run of gradle? If not, it could be as easy as using some additional argument to gradle, such as
compileJava {
options.debug = project.hasProperty('debugBuild')
}
gradle assemble -PdebugBuild=true # or false
See here for documentation: https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_properties_and_system_properties
Also not that you might get better help in the gradle forums.
Not sure but perhaps my gradle-java-flavours plugin could help here. Eg:
plugins {
id "com.lazan.javaflavours" version "1.2"
}
javaFlavours {
flavour 'debug'
flavour 'release'
}
debugJar {
version = "${project.version}-debug"
}
releaseJar {
version = "${project.version}-release"
}
Each flavour gets it's own Jar and JavaCompile tasks etc and you can specify custom sources, resources, tests, dependencies for each flavour too.
See here for a bit more overview on the tasks, directories and configurations avaliable and here for a test which covers the functionality.
This approach differes from your GradleBuild style since the "flavours" can happily live together in a single project which builds multiple artifacts rather than running a project twice with two different parameters.
Your question is detailed since you made a deep analysis of the problem. Although I believe that this issue could be solved if you would think in simpler way.
So if we think simple, a possible solution to your case is to run the debug task after the release is finalized. See the example below:
compileJava {
options.debug = false
}
task buildRelease(type: GradleBuild, dependsOn: build) {
doLast {
project.version = '1.0-release'
compileJava {
options.debug = false
}
}
}
task buildDebug(type: GradleBuild, dependsOn: build) {
doLast {
project.version = '1.0-debug'
compileJava {
options.debug = true
}
}
}
// Here you are telling the buildDebug task to be executed right after the
// buildRelease task is finalized.
buildDebug.mustRunAfter buildRelease
In the above way you control the order of the task execution without introducing an explicit dependency between them.
链接地址: http://www.djcxy.com/p/40888.html