How to simplify this Gradle command line? - gradle

I am new to Gradle and have gotten a fairly sophisticated build working with it so far (runs tests, uses CodeNarc, generates API docs, generates a sources JAR, etc.). The command line for a "full build" (that is, to execute all the major tasks that the CI server should be running), I need to enter the following Gradle command at the shell:
gradle clean build check groovydoc sourcesJar createPom dist -Pversion=<version>
Where <version> is the version I want to build.
I would like to condense this and add an alias so that all of the above can be accomplished with something simple, like:
gradle full-build
Is this possible? If so, how?
My build.gradle
apply plugin: 'groovy'
apply plugin: 'maven'
apply plugin: 'codenarc'
repositories {
mavenCentral()
}
dependencies {
compile 'org.codehaus.groovy:groovy-all:2.3.3'
testCompile 'junit:junit:4.11'
}
groovydoc
task sourcesJar(type: Jar, dependsOn: classes) {
classifier = 'sources'
from sourceSets.main.allSource
}
artifacts {
archives sourcesJar
}
task wrapper(type: Wrapper) {
gradleVersion = '1.11'
}
task dist(type: Zip, dependsOn: build) {
classifier = 'buildreport'
from('build/test-results') {
include '*.xml'
into 'tests'
}
from('build/reports/codenarc') {
into 'reports'
}
from('build/docs') {
into 'api'
}
from(sourcesJar) {
into 'source'
}
from('build/libs') {
exclude '*-sources.jar'
into 'bin'
}
}
task createPom << {
pom {
project {
groupId "me"
artifactId "myapp"
version version
}
}.writeTo("build/libs/myapp-${version}.pom")
}

In the above build invocation, at least check and sourcesJar can be omitted already. (build depends on check, and from(sourcesJar) tells Gradle that dist depends on sourcesJar.) By adding further task dependencies (e.g. build.dependsOn dist), you can cut it down to gradle clean build -Pversion=.... dist should not depend on build but on the specific tasks that produce the artifacts that go into the zip (e.g. groovydoc and createPom).
Reducing gradle clean build to gradle fullBuild is more difficult, as Gradle doesn't currently have a first-class concept of "aliases", and adding build.dependsOn(clean) is usually not desirable. One way out is to implement your own aliasing mechanism by manipulating gradle.startParameter.taskNames.

Related

How can I have Teamcity Artifactory plugin invoke bootJar instead of Jar in Gradle?

We are using Gradle 4.8.1 to generate Spring Boot executable jars. This works fine locally. However, we are using Teamcity to publish our artifacts into Artifactory.
The issue is, to my understanding, that the "artifactoryPublish" task invokes the "jar" task in Gradle, which uploads artifacts from "Archives". So, irrespective of whether teamcity invokes the "assemble" task, or the "bootjar" task, or the "build" task, the artifactory plugin is taking the output of the "jar" task in the end and publishes that, whereas we'd like to have the output of the "bootjar" task (fat jar) in artifactory.
Is there any way I can force artifactoryPublish to run bootjar instead of jar ? Or for the jar task to create a fat jar as well ? Or should I consider another approach ?
Here's my build.gradle from one of the subprojects
plugins {
id "org.springframework.boot" version "2.0.4.RELEASE"
id "io.spring.dependency-management" version "1.0.6.RELEASE"
}
apply plugin: 'java'
repositories {
mavenCentral()
}
description = 'atlas-data-service'
// Dynamically insert TeamCity build number if available
if (hasProperty("teamcity")) {
version = teamcity["build.number"]
println "Release version with TeamCity build number passed into gradle is " + version
} else {
// Take the default appVersion defined in top level build.gradle when building outside of TeamCity
version = "$appVersion"
}
jar {
baseName = 'data-service'
enabled = true
}
bootJar {
mainClassName = 'c.m.f.a.dataservice.AtlasDataServiceApplication'
baseName = 'data-service'
enabled = true
classifier = 'boot'
}
dependencies {
...
}
This question is from last year, but updating in case someone else comes looking with the same issue.
I used the Maven-publish plugin to get the job done.
https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#publishing-your-application-maven-publish
apply plugin: 'maven-publish'
publishing.publications {
bootJava(MavenPublication) {
artifact bootJar
}
}

pom.xml without dependencies using maven-publish plugin in a multi module gradle project

I've a gradle project with subprojects. Every subproject produces a jar and a pom that it's published on a repository
1) In the main project gradle file there's a subprojects section that I used to define what and where to publish:
snippet from rootproject.gradle:
subprojects {
apply plugin: 'maven-publish'
publishing {
publications {
mavenJava(org.gradle.api.publish.maven.MavenPublication) {
from components.java
}
}
repositories {
maven {
url 'file://c:/temp/repo'
}
}
}
}
2) In the gradle file of one of my subprojects, I've added some dependencies:
snippet from subproject.gradle:
dependencies {
compile group: 'my-group', name: 'my-module', version:'1.1.0'
}
If I run "gradle publish" from the rootproject it will correctly publish every subproject. However, I noticed that the dependency defined in the subproject is missing from the pom publication related to the subproject.
If I cut and paste the content of the subprojects section in each subproject, the generated pom file contains the correct dependency.
It seems that “from components.java” is not a reference to something that should be used by the publish task to produce the pom, but the task will publish exactly what components.java contains when you call the “from” method.
As a workaround, I moved the subprojects code in a method defined in the root:
rootproject.gradle
def configurePublishing(project) {
project.apply plugin: 'maven-publish'
…
}
And I called it from each subproject:
subproject.gradle
dependencies {
compile group: 'my-group', name: 'my-module', version:'1.1.0'
}
configurePublishing(project)
Another solution could be adding a switch in the subprojects section and centralize everything in the gradle file of the root project:
subprojects { subProject ->
switch(subproject.name) {
case: ‘my-subproject-with-dependencies’ {
dependencies {
compile group: 'my-group', name: 'my-module', version:'1.1.0'
}
break;
}
}
apply plugin: 'maven-publish'
}
Is it an acceptable approach? Is there a best practice to follow? Is there an easier way to do it?

Skip building jar in Gradle groovy scripts project

I have a gradle groovy project where I only have groovy scripts that are not in a source dir, but a separate dir. Additionally I have groovy junit tests that test the scripts invoking them using groovy shell.
I have a gradle build that runs the tests, then zips the scripts into separate zip files and uploads them into maven repo. The problem is, that gradle also creates and uploads a jar file. Since there are no files in source dirs, the jar contains only a generated manifest file.
In reality I don't need the jar at all.Is it possible to configure gradle to not create a jar file for a groovy project?
I upload the artifacts using uploadArchives task.
My full gradle config:
group 'groupName'
version '1.0-SNAPSHOT'
apply plugin: 'groovy'
apply plugin: 'java'
apply plugin: 'maven'
repositories {
mavenCentral()
}
dependencies {
compile 'org.codehaus.groovy:groovy-all:2.3.11'
testCompile group: 'junit', name: 'junit', version: '4.11'
}
task scriptsZip(type: Zip) {
from 'scripts'
}
artifacts {
archives file: scriptsZip.archivePath, type: 'zip', classifier: 'scripts', builtBy: scriptsZip
}
uploadArchives {
repositories {
mavenDeployer {
repository(url: "file://C:\\testRepo")
}
}
}
You can modify the jar task with an onlyIf condition, to skip building the jar when some condition is met (or not met)
jar {
onlyIf { /*some condition*/ }
}
In your case, it might make sense to check if there are any source files in your main sourceset:
jar {
onlyIf { !sourceSets.main.allSource.files.isEmpty() }
}

How to force artifact/module name with Gradle build

Please note: even though this question specifically mentions Bamboo CI and the Gradle ShadowJar plugin, I believe this is a basic Gradle config question at heart, and believe it can be answered by any battle-weary Gradle Guru.
I have a Groovy app that is built with Gradle, where build.gradle is:
apply plugin: 'groovy'
apply plugin: 'maven'
apply plugin: 'application'
apply plugin: 'com.github.johnrengelman.shadow'
apply plugin: 'eclipse'
sourceCompatibility = '1.8'
targetCompatibility = '1.8'
[compileJava, compileTestJava]*.options*.encoding = 'UTF-8'
group = 'com.me.myapp'
mainClassName = "com.me.myapp.MyAppDriver"
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.github.jengelman.gradle.plugins:shadow:1.2.0'
}
}
dependencies {
// Omitted for brevity
}
jar {
manifest {
attributes 'Main-Class': mainClassName
}
}
repositories {
mavenLocal()
mavenCentral()
}
shadowJar {
classifier = ''
mergeServiceFiles {
exclude 'META-INF/*.DSA'
exclude 'META-INF/*.RSA'
}
}
artifacts {
archives(file("${buildDir}/libs/myapp-${version}.jar")) {
name "myapp"
classifier ""
builtBy shadowJar
}
}
task wrapper(type: Wrapper) {
gradleVersion = '2.3'
}
And where gradle.properties is:
group=com.me.myapp
version=1.0.0
As you can see, I'm using ShadowJar to produce a self-contained "fat JAR" for my app. When I run gradle clean build shadowJar on my local machine, Gradle produces a build/libs/myapp-1.0.0.jar artifact/archive. However, when this same command is ran from our CI server (Bamboo), Gradle produces a build/libs/MYAPP-KEY-1.0.0.jar artifact/archive, where MYAPP-KEY is the Bamboo "build key" (essentially, a unique key/label identifying the build on the server). If you're clueless as to what I'm talking about, I don't think that really matters. What is important to understand is that Bamboo will check out the source code for myapp to a folder named MYAPP-KEY on the CI server. So locally myapp/ is the root of my project, but on CI MYAPP-KEY is the root of my project.
The main point is that I am not explicitly defining something in my Gradle config, and so it seems that Gradle is using the name of the project root to produce the name of the built JAR. What is this "something" and how/where do I define it? The desired end objective is to produce a build/libs/myapp-1.0.0.jar both locally and on CI.
please, look at https://docs.gradle.org/current/dsl/org.gradle.api.tasks.bundling.Jar.html
you can specify base name or full archive name of jar
add it to your jar section

Gradle Maven plugin generates incorrect POM dependencies for custom configuration

I have a Gradle project which does a couple of orthogonal things:
Compile and run some Java.
Generate and publish an artifact.
This artifact is nothing to do with the Java; it's generated by a custom JavaExec task. However, the auto-generated POM (from the Maven plugin) seems to include the wrong dependencies. Question: How can I prevent this?
My build.gradle looks something like this:
apply plugin: "java"
apply plugin: "maven"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
uploadFoo {
repositories {
mavenDeployer { ... }
}
}
I invoke Gradle like this:
./gradlew uploadFoo
AFAICS, the foo configuration is unrelated to the Java configurations. So I expect the published POM to list no dependencies. However, I observe all the unrelated dependencies listed.
The Gradle docs for the Maven plugin hint at dependency mapping with conf2ScopeMappings, but I'm entirely unclear what (if anything) I should be doing with this.
Note: I'm using Gradle wrapper 1.6; I'll be trying the latest to see if that makes a difference...
I managed to setup similar configuration with both maven and maven-publish gradle plugins.
In my case I was using custom Jar task with custom configuration, but it should work because the artifacts { ... } are used in both cases.
With maven plugin, your build.gradle would look like:
apply plugin: "java"
apply plugin: "maven"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
uploadFoo {
repositories {
mavenDeployer {
pom.scopeMappings.with {
mappings.clear()
addMapping(300, configurations.foo, 'runtime')
}
pom.artifactId = 'other artifact id than main jar'
...
}
}
}
This solution was inspired by following thread:
http://gradle.1045684.n5.nabble.com/pom-generation-and-inherited-dependencies-td1436197.html
Note the line:
addMapping(300, configurations.foo, 'runtime')
You can add other configurations as well, or use other maven scope than the 'runtime' scope.
300 stands for priority, which is not significant in this case.
Advantage of this solution is that we have quite fine control over dependencies and their mappings. Disadvantage would be that this will not work for the install task. We would need to setup different poms for the install task, which might be possible, but it is beyond my knowledge.
Alternative with usage of maven-publish plugin:
apply plugin: "java"
apply plugin: "maven-publish"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
publishing {
publications {
foo(MavenPublication) {
from new org.gradle.api.internal.java.JavaLibrary(\
configurations.api.artifacts.toArray()[0], \
configurations.api.allDependencies)
artifactId 'other artifact id than main jar'
}
}
repositories {
maven { ... }
}
}
gradle tasks will give you possible publish commands:
publish - Publishes all publications produced by this project.
publishFooPublicationToMavenLocal - Publishes Maven publication 'foo' to the local Maven repository.
publishFooPublicationToMavenRepository - Publishes Maven publication 'foo' to Maven repository 'maven'.
publishToMavenLocal - Publishes all Maven publications produced by this project to the local Maven cache.
...
The advantege of maven-publish alternative is that it will work for both local and remote maven repositories. Disadvantage may be a fact that we are using the internal API which may change in future and that all dependencies are mapped to the 'runtime' maven scope. Also the MavenPublication snippet would be much more verbose and more internal API would be used if we would like to use some other maven scope or apply some scope mapping.
I am using Gradle 1.10

Resources