version numbers in gradle - gradle

Anyone know how to get this working in gradle for a SUBPROJECT so that running the left hand size results in the right hand archive name...
gradle assemble -> databus-Developer-Build.zip
gradle -DmyVersion=1.0.2 assemble -> databus-1.0.2.zip
OR
gradle -PmyVersion=1.0.2 assemble -> databas-1.0.2.zip
I have tried and tried with a variable myVersion but it always says it does not exist....and in half the cases, it shouldn't exist because I didn't supply it!!!!!
How to get this working in a subproject?
thanks,
Dean

Add following snippet to allprojects configuration section of root build.gradle:
allprojects {
if (project.hasProperty('myVersion')) {
project.version = project.myVersion
} else {
project.version = 'Developer-Build'
}
}
and than pass your version in command line as -PmyVersion=1.0.2. Tested with rather old Gradle 1.0-milestone-3

proper way to do it in newer versions worked...(notice the ext addition).
if (project.hasProperty('myVersion')) {
project.ext.xVersion = project.myVersion
} else {
project.ext.xVersion = 'Developer-Build'
}
and interestingly enough this one does NOT work because 'version' seems to be some sort of reserverd property and is set to unspecified on startup...
if (project.hasProperty('version')) {
project.ext.xVersion = project.version
} else {
project.ext.xVersion = 'Developer-Build'
}
Seeing as version seems to be a reserved property, it is most likely used in publishing artifacts so the best solution then maybe the following
if (project.hasProperty('myVersion')) {
project.version = project.myVersion
} else {
project.version = 'Developer-Build'
}
and the automated build passes in myVersion and developers of course don't.

Related

How do I create distributions with different dependencies using Gradle application/distribution plugin?

I am building a small Kotlin project in IntelliJ, Idea, and trying to figure out how to create multiple tar/zip files with customizations for each OS I want to support.
It seems like the distribution plugin (which is included when you use the application plugin) is the right direction, but I can't seem to figure out how to get it to do what I want.
I have read the documentation on the plugin, which can be found here, but it's not really clear to me how to accomplish what I want to do.
Here is an example build.gradle that shows at least the idea of what I want to do, that is to have a base application setup and then have some minor tailoring for each of the 3 OSs.
For example each of the 3 OSs need a unique version of the SWT library. The macos version needs a specific JVM setting, and for the linux version, I need to tailor the startup script to add some environment variables.
Is this possible with the distribution plugin? If not can someone suggest a different solution?
plugins {
id 'org.jetbrains.kotlin.jvm' version '1.2.61'
}
apply plugin: 'application'
mainClassName = "MainKt"
version '1.0-SNAPSHOT'
repositories {
// my common required repos
}
dependencies {
// my common dependencies
}
distributions {
macos {
contents { from 'src' }
applicationDefaultJvmArgs.push("-XstartOnFirstThread")
dependencies {
implementation "org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:4.5.2"
}
}
linux {
contents { from 'src' }
dependencies {
implementation "org.eclipse.swt:org.eclipse.swt.gtk.linux.x86_64:4.5.2"
}
startScripts.doLast {
def lines = unixScript.text.readLines()
println lines.add(1, '# add some stuff')
println lines.add(2, '# add some more stuff')
unixScript.text = lines.join("\n")
}
}
windows {
contents { from 'src' }
dependencies {
implementation "org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:4.5.2"
}
}
}
compileKotlin {
kotlinOptions.jvmTarget = "1.8"
}
compileTestKotlin {
kotlinOptions.jvmTarget = "1.8"
}
Update
This is what I am doing now, but I would like to improve on this.
I have a variable
def deploy = false
if (!deploy) {
applicationDefaultJvmArgs.push("-XstartOnFirstThread")
dependencies {
implementation "org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:4.5.2"
}
} else {
dependencies {
implementation "org.eclipse.swt:org.eclipse.swt.gtk.linux.x86_64:4.5.2"
}
startScripts.doLast {
def lines = unixScript.text.readLines()
println lines.add(1, 'export foo=foo')
println lines.add(2, 'export bar=bar')
}
}
Right now I develop on my mac and set deploy to false. When I want to generate the distribution for linux I set deploy to true. I could add more code and do the same thing for windows, but I would like to just generate all the code in one task, and have it in different tar/zip files.
Opal provided some very good suggestions in the question comments that I tried, but in the end, I was not able to really get what I wanted.
Here is my current workaround solution it does pretty much what I was hoping I could have done with the distribution plugin.
Basically I create an osType property and set it's "default" to the os I am developing on, in this case macos. Then I have all my common dependencies in one dependency closure and add in the the os specific stuff in a groovy switch statement. I then just coded up a short shell script that overrides the osType property to each of the os's I want to support and calls the gradle task to build each in turn.
Here is my build.gradle file.
plugins {
id 'org.jetbrains.kotlin.jvm' version '1.2.61'
id 'application'
}
ext {
swtVersion = "4.5.2"
}
ext.osType = project.properties['osType'] ?: 'macos'
println "building for ${osType}"
mainClassName = "MainKt"
repositories {
mavenCentral()
maven { url "http://maven-eclipse.github.io/maven" }
}
dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
}
switch(osType) {
case 'macos':
dependencies {
implementation "org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:${swtVersion}"
}
applicationDefaultJvmArgs.push("-XstartOnFirstThread")
break
case 'linux':
dependencies {
implementation "org.eclipse.swt:org.eclipse.swt.gtk.linux.x86_64:${swtVersion}"
}
startScripts.doLast {
def lines = unixScript.text.readLines()
println lines.add(1, 'export FOO=foo')
println lines.add(2, 'export BAR=bar')
unixScript.text = lines.join("\n")
}
break
case 'windows':
dependencies {
implementation "org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:${swtVersion}"
}
}
version "${osType}-1.0-SNAPSHOT"
compileKotlin {
kotlinOptions.jvmTarget = "1.8"
}
compileTestKotlin {
kotlinOptions.jvmTarget = "1.8"
and here is my shell script (buildAll.sh) that I run from the terminal in Idea.
#!/bin/sh
./gradlew -PosType=macos distTar
./gradlew -PosType=linux distTar
./gradlew -PosType=windows distTar
./gradlew -PosType=windows distZip

How do I get IntelliJ to recognize gradle generated sources dir?

So I have an XJC javaExec that spins like a top but IntelliJ doesn't recognize the generated output despite having marked generated-src/java as such. Do I need to tweak the idea plug-in or something?
Note: The plug-in itself is loaded in subProjects from the root build.gradle.
XJC Project:
description = "Generates sources and compiles them into a Jar for $project"
configurations { xjc }
dependencies {
xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
xjc 'org.glassfish.jaxb:jaxb-runtime:2.2.11'
}
task xjc (type:JavaExec) {
doFirst{
File generatedSrcDir = file("$buildDir/generated-src/java")
if (!generatedSrcDir.exists()) {
generatedSrcDir.mkdirs()
}
}
main = "com.sun.tools.xjc.XJCFacade"
classpath configurations.xjc
def argsList = [
"-mark-generated",
"-no-header",
"-verbose", // or -quiet or nothing for default.
"-target", "2.1",
"-encoding", "UTF-8",
"-d", "$buildDir/generated-src/java",
"-catalog","$projectDir/src/main/resources/commons-gradle.cat",
file("$projectDir/src/main/resources/v1/") ]
args argsList
inputs.files files(file("$projectDir/src/main/resources/v1/"))
outputs.files files(file("$buildDir/generated-src/java"),file("$buildDir/classes"))
}
compileJava {
dependsOn xjc
source "${buildDir}/generated-src"
}
In the project that depends on this one I simply have:
compile project(":path:to:schemas:the-test-schema")
I've tried:
idea {
module {
def buildDir = file("$buildDir")
def generatedDir = file("$buildDir/generated-src")
def listOfDirs = []
buildDir.eachDir { file ->
if (file.name != buildDir.name && file.name != generatedDir.name)
listOfDirs.add(file)
}
excludeDirs = listOfDirs.toArray()
generatedSourceDirs += file("$buildDir/generated-src/java")
scopes.COMPILE.plus += [ configurations.xjc ]
}
}
I'll point out a solution by Daniel Dekany, from a Gradle discussion thread actually linking to this question. To quote:
apply plugin: "idea"
...
sourceSets.main.java.srcDir new File(buildDir, 'generated/javacc')
idea {
module {
// Marks the already(!) added srcDir as "generated"
generatedSourceDirs += file('build/generated/javacc')
}
}
Works well for me.
The code of this answer, rewritten using Kotlin DSL, will look like this:
plugins {
idea
}
val generatedSourcesPath = file("out/production/classes/generated")
java.sourceSets["main"].java.srcDir(generatedSourcesPath)
idea {
module {
generatedSourceDirs.add(generatedSourcesPath)
}
}
In my case, it didn't work unless I added the generate sources directory to both sourceDirs and generatedSourceDirs:
def generatedSourcesDir = file('src/generated/main/java')
idea {
module {
sourceDirs += generatedSourcesDir
generatedSourceDirs += generatedSourcesDir
}
}
in 2020 you probably did not refresh the project in IDEA
because it actually works oob.
30 mins of reading outdated solutions :(
It's happening in some versions. There are some issues that we can look at and read carefully.
But for myself, from the IntelliJ IDEA 2019 the solutions below aren't working anymore:
https://youtrack.jetbrains.com/issue/IDEA-210065 (it says Obsolete)
https://youtrack.jetbrains.com/issue/IDEA-152581 (it's saying Fixed here)
https://youtrack.jetbrains.com/issue/IDEA-117540/generated-sources-inside-output-directory-are-excluded-by-default
https://intellij-support.jetbrains.com/hc/en-us/community/posts/4906059373074-Class-defined-in-generated-sources-not-found-by-Intellij-editor-but-found-by-compiler-gradle-build-
Discussion in the Gradle forum about this: https://discuss.gradle.org/t/how-do-i-get-intellij-to-recognize-gradle-generated-sources-dir/16847
According to #Daniel Dekany, this worked in IDEA 2017.1.2, and worked for me until 2019:
plugins {
id 'idea'
}
idea {
module {
generatedSourceDirs += file('build/generated/sources/annotationProcessor')
}
}
But from 2019 to 2022, the solution that worked for me was:
def generatedDir = "${buildDir}/generated/sources"
sourceSets {
main {
java {
srcDir generatedDir
}
}
}
idea {
module {
generatedSourceDirs.addAll(file(generatedDir))
}
}
ext {
// path to IDEA generated sources directory
ideaGeneratedSourcesDir = "$projectDir/src/main/generated"
}
compileJava {
//……
options.annotationProcessorGeneratedSourcesDirectory = file(ideaGeneratedSourcesDir)
//options.headerOutputDirectory.set(file(ideaGeneratedSourcesDir)) (tested no effect)
//……
}
// above work for me, and i try all method this question mentioned it's not work! env: idea2019.3, wrapped gradle6.3-all, zh-CN, JDK8, [x] annotation processing is disabled(no effect, in global settings ), no idea plugin([x]plugins {id idea}), [x]sourceSets no need to set(genereated srcDir)
myCodeGenExample:
task vertxCodeGen(type: JavaCompile) {
group 'build'
source = sourceSets.main.java
destinationDir = file(ideaGeneratedSourcesDir)
classpath = configurations.compileClasspath
options.annotationProcessorPath = configurations.annotationProcessor
options.debugOptions.debugLevel = "source,lines,vars"
options.compilerArgs = [
"-proc:only",
"-processor", "io.vertx.codegen.CodeGenProcessor",
// where the non Java classes / non resources are stored (mandatory) - the processors requires this option to know where to place them
"-Acodegen.output=$destinationDir.absolutePath",
]
}
refresh the gradle, continously exist

Set repositories and version/revison dynamically in gradle

I have a gradle buildscript. In this script I set some publications.
Later in the script I have a task which reads the Buildnumber from a file and increases it. Than the version of the project will be changed.
Now my question: Is it possible to change the revision/version after initialising the "Publishing"-PlugIn? If I doesn't set the new version, the "Publishing"-PlugIn will throw n error. If I change the version by editing the descriptor, the Plugin says, that it's not allowed to edit the descriptor directly.
I also want to change the repository-url, based on the build number.
Does anybody know a fix or had the same problem?
publishing {
publications {
ivy(IvyPublication) {
organisation project.group
module project.name
revision project.version
descriptor.status = 'milestone'
from components.java
artifact(sourceJar) {
type "source"
conf "runtime"
}
}
maven(MavenPublication) {
groupId project.group
artifactId project.name
version project.version
from components.java
}
}
repositories {
ivy {
// change to point to your repo, e.g. http://my.org/repo
url "P:/Java/Repo/ivy"
}
maven {
// change to point to your repo, e.g. http://my.org/repo
url "P:/Java/Repo/maven"
}
}
}
Here is my script for increasing the build number
def incVersion(project) {
project.versionInced = true
def versionPropsFile = file("${project.rootDir}/version.properties")
if (!versionPropsFile.canRead()) {
versionPropsFile.createNewFile();
}
def Properties versionProps = new Properties()
versionProps.load(new FileInputStream(versionPropsFile))
if(versionProps['build_version'] == null)
{
versionProps['build_version'] = 0;
}
def code = versionProps['build_version'].toInteger()+1;
versionProps['build_version']=code.toString()
versionProps.store(versionPropsFile.newWriter(), null)
project.projectInfos.version = project.version + "." + code.toString()
project.version = project.projectInfos.version
println "Version: "+project.version
return project.version
}
If I understood well, yes it can be done dynamically. You can pass a version while running gradle via project property (-P) or via system property (-D).
It will be:
gradle <some_task> -PsomeVersion=<version>
You need to alter the gradle script to read the property, so:
publishing {
publications {
ivy(IvyPublication) {
revision project.hasProperty('someVersion') ? project.someVersion : '<HERE YOU NEED TO PUT DEFAULT VERSION OR MAYBE THROW EXCEPTION IF EMPTY>'
//...
}
}
}
If you won't check if project has the property (using hasProperty method on project instance), MissingPropertyException will be thrown.

Why do different parts of my build scripts see different values for the project.version property?

I do the following in gradle in allprojects section...
if (project.hasProperty('myVersion')) {
project.ext.realVersion = project.myVersion
project.version = project.myVersion
println("project version set")
} else {
project.ext.realVersion = 'Developer-Build'
project.version = 'Developer-Build'
println("project version set to devbuild")
}
Now, I have some code that correctly uses project.version and it works, BUT then there is other code that is ALSO using the same property project.versoin and the result is 'unspecified'. If I change both to project.realVersion, they both work. version seems to be this nasty special property that doesn't always seem to work.
The code using the properties is below....(notice where I use realVersion, version does NOT work, but it works fine in the other location :( )....how weird.
task versionFile() << {
File f = new File('output/version');
f.mkdirs()
File v = new File(f, 'version'+project.ext.realVersion)
println('v='+v.getAbsolutePath())
v.createNewFile()
}
task myZip(type: Zip) {
archiveName 'dashboard-'+project.version+'.zip'
from('..') {
include 'webserver/run*.sh'
include 'webserver/app/**'
include 'webserver/conf/**'
include 'webserver/play-1.2.4/**'
include 'webserver/public/**'
include 'webserver/lib/**'
}
from('output/version') {
include '**'
}
}
myZip.dependsOn('versionFile')
assemble.dependsOn('myZip')
The problem has nothing to do with the version property in particular. Build scripts are evaluated sequentially. If you can't guarantee that you are setting the version property before you are reading it, you have to defer reading the property until the end of the configuration phase. Otherwise you'll inevitably run into problems. One way to do this is to put the configuration code that reads the property into a gradle.projectsEvaluated {} block. task.doFirst {} is another way, but has the limitation that the configured value won't be considered for up-to-date checking.
Sometimes there is an easier solution. For example, in the case of archive tasks like Zip, you can just set baseName and extension instead of archiveName. As always, I encourage you to study the DSL reference.
Place the following in doFirst like below:
allprojects {
doFirst {
if (project.hasProperty('myVersion')) {
project.ext.realVersion = project.myVersion
project.version = project.myVersion
println("project version set")
} else {
project.ext.realVersion = 'Developer-Build'
project.version = 'Developer-Build'
println("project version set to devbuild")
}
}
}

how to get version number or something else into my zip archive in gradle

EDIT:
I am trying to run these two commands and get these results in a gradle subproject...
gradle assemble -> databus-Developer-Build.zip
gradle -DmyVersion=1.0.2 -> databus-1.0.2.zip
Currently, my output is databus-null.zip IF I use $version instead of $myVersion. When using $MyVersion, I get the error "myVersion is not a property on that task". :( :(.
EDIT
So, trying out the first answer completely failed with "Could not find property $myVersion on task ':webserver:myZip"
NOTE: I am trying to do this in a subproject right now. Here is the subproject gradle code...
project(':webserver') {
project.ext.genLibDir = file('lib')
project.ext.fixedLibDir = file('../master/libother')
dependencies {
compile project(':master')
compile fileTree(dir: '../webserver/lib', include: '*.jar')
compile fileTree(dir: '../webserver/play-1.2.4/framework/lib', include: '*.jar')
compile fileTree(dir: '../webserver/play-1.2.4/framework', include: 'play-*.jar')
}
task deleteJars(type: Delete) {
ext.collection = files { genLibDir.listFiles() }
delete ext.collection
}
task copyJars(type: Copy) {
from(configurations.compile) {}
from(fixedLibDir) {}
into genLibDir
}
copyJars.dependsOn('deleteJars')
classes.dependsOn('copyJars')
task myZip(type: Zip) {
archiveName "dashboard-"+$myVersion+".zip"
from('..') {
include 'webserver/run*.sh'
include 'webserver/app/**'
include 'webserver/conf/**'
include 'webserver/play-1.2.4/**'
include 'webserver/public/**'
}
}
assemble.dependsOn('myZip')
//playframework has it's own generation of .classpath and .project fils so do not
//overwrite their versions. NEED to call "play.bat eclipsify" here...
task eclipse(overwrite: true) {
}
gradle.taskGraph.whenReady {taskGraph ->
if (taskGraph.hasTask(assemble) && myVersion == null) {
myVersion = 'Developer-Build'
}
}
}
thanks,
Dean
I think the reason that you get the error "myVersion is not a property on that task" is, that you have to pass the property with -P instead of "-D"
ok, the correct answer is doing something like this...(add this to allprojects section)..
if (project.hasProperty('myVersion')) {
project.ext.xVersion = project.myVersion
} else {
project.ext.xVersion = 'Developer-Build'
}
and interestingly enough this below one does NOT work because 'version' seems to be some sort of reserverd property and is set to unspecified on startup...
if (project.hasProperty('version')) {
project.ext.xVersion = project.version
} else {
project.ext.xVersion = 'Developer-Build'
}
Seeing as version seems to be a reserved property, it is most likely used in publishing artifacts so the best solution then maybe the following
if (project.hasProperty('myVersion')) {
project.version = project.myVersion
} else {
project.version = 'Developer-Build'
}
and the automated build passes in myVersion and developers of course don't.

Resources