http://mrhaki.blogspot.com/2012/10/gradle-goodness-exclude-transitive.html
https://www.mkyong.com/gradle/gradle-display-project-dependency/
gradle {subproject}:dependencies
gradle dependencies --configuration runtime
https://stackoverflow.com/questions/12016681/how-to-change-gradle-download-location
http://mrhaki.blogspot.com/2010/09/gradle-goodness-changing-gradle-user.htmlcr
# export GRADLE_USER_HOME=/gradle
# export M2_HOME=/m2
https://discuss.gradle.org/t/is-it-possible-to-configure-the-local-gradle-cache-folder-to-non-default-location/21851
https://gist.github.com/cr7pt0gr4ph7/6cd6339eabc2056bc3e7
Using
https://github.com/gradle/gradle/issues/3317
org.gradle.tooling.GradleConnectionException: Could not create an instance of Tooling API implementation using the specified Gradle distribution 'https://services.gradle.org/distributions/gradle-4.2-bin.zip'.
Caused by: java.lang.IllegalArgumentException: Could not determine java version from '9.0.1'.
the project needs to use Gradle 4.2.1 or above. Alternatively you can start Eclipse with Java 8.
https://gradle.org/maven-vs-gradle/
https://dzone.com/articles/gradle-vs-maven
https://github.com/groovy/groovy-eclipse/wiki
https://blog.csdn.net/Calvin_zhou/article/details/78005407
- don't work ...
https://softdevbuilttolast.wordpress.com/2015/04/15/debugging-build-gradle-with-eclipse/
http://www.jasondl.ee/posts/2013/gradle-tip-attaching-a-debugger.html
$HOME/.gradle/init.gradle
allprojects {
tasks.withType(Test) {
if (System.getProperty('DEBUG', 'false') == 'true') {
jvmArgs '-Xdebug',
'-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9009'
}
}
tasks.withType(JavaExec) {
if (System.getProperty('DEBUG', 'false') == 'true') {
jvmArgs '-Xdebug',
'-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9009'
}
}
}
https://stackoverflow.com/questions/24612906/android-gradle-project-directory-variable
https://github.com/michel-kraemer/gradle-download-task
https://michelkraemer.com/recipes-for-gradle-download/
task downloadFiles(type: Download) {
src([
'http://central.maven.org/maven2/org/citationstyles/styles/1.0/styles-1.0.jar',
'http://central.maven.org/maven2/org/eclipse/jetty/jetty-server/9.1.3.v20140225/jetty-server-9.1.3.v20140225-javadoc.jar'
])
dest buildDir
overwrite true
}
https://stackoverflow.com/questions/24724383/add-resources-config-files-to-your-jar-using-gradle
https://stackoverflow.com/questions/21645071/using-gradle-to-find-dependency-tree
https://github.com/mockito/shipkit/issues/290
shadowJar
http://imperceptiblethoughts.com/shadow/
https://stackoverflow.com/questions/13565082/how-can-i-force-gradle-to-redownload-dependencies
https://stackoverflow.com/questions/13517884/nullpointerexception-org-gradle-wrapper-bootstrapmainstarter-findlauncherjarboo
NullPointerException org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:37)
https://blog.jdriven.com/2017/01/gradle-goodness-run-task-ignoring-date-checks/
To run a Gradle build as a dry run we can use the command line option
https://stackoverflow.com/questions/19396876/gradle-download-dependency-merge-into-maven-local-repository?rq=1
http://mrhaki.blogspot.com/2012/10/gradle-goodness-init-script-for-adding.html
https://docs.gradle.org/current/userguide/init_scripts.html
https://www.slideshare.net/ynnek13/4f-migrating-to-gradle
https://docs.gradle.org/current/userguide/java_plugin.html
http://www.ekiras.com/2016/12/gradle-build-life-cycle-phases-gradle.html
https://www.mkyong.com/gradle/gradle-create-java-project-structure-automatically/
https://www.michael-bull.com/blog/2016/06/04/separating-integration-and-unit-tests-with-gradle
https://gist.github.com/mychaelstyle/9826322
apply plugin: "findbugs"
apply plugin: "pmd"
findbugs {
ignoreFailures = true
}
pmd {
ignoreFailures = true
}
debug test
https://github.com/robolectric/robolectric-gradle-plugin/wiki/Debugging-the-Plugin
https://stackoverflow.com/questions/28437636/how-to-debug-a-gradle-build-gradle-file-in-a-debugger-with-breakpoints
--parallel
./gradlew clean build --profile --daemon -x test -x findbugsMain -x findbugsTest -x findbugsIntegrationTest -x pmdMain -x pmdTest -x pmdIntegrationTest -x testClasses -x integrationTestClasses -x javadoc -x javadocJar
publishToMavenLocal --dry-run --profile --daemon
https://medium.com/@kevalpatel2106/how-to-decrease-your-gradle-build-time-by-65-310b572b0c43
Gradle provides — configure-on-demand flag, that will tell gradle to only build the projects that it really needs to build. Let’s run this command.
./gradlew android:assembleDebug --dry-run --profile --configure-on-demand
Enable daemon:
Always keep your gradle up-to-date:
So, always make sure that you are using the latest version of the gradle. You can go to /gradle/wrapper/gradle-wrapper.properties and upgrade gradle version by changing distributionUrl.
org.gradle.daemon=true
# Try and findout the best heap size for your project build.
org.gradle.jvmargs=-Xmx3096m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
# Modularise your project and enable parallel build
org.gradle.parallel=true
# Enable configure on demand.
org.gradle.configureondemand=true
https://medium.com/@kuassivi/tip-work-with-third-party-projects-locally-with-gradle-961d6c9efb02
https://stackoverflow.com/questions/20128416/gradle-subproject-name-different-than-folder-name
http://mrhaki.blogspot.com/2016/09/gradle-goodness-add-but-do-not-apply.html
https://stackoverflow.com/questions/32352816/what-the-difference-in-applying-gradle-plugin
https://docs.gradle.org/current/userguide/publishing_maven.html
Start up script
All the files with .gradle extension under <USER_HOME>/.gradle/init.d directory are treated as initialization scripts.
init.gradle under <USER_HOME>/.gradle/ are treated as an initialization script
All the files with the .gradle extension under <GRADLE_HOME>/init.d/ directory.
You can even specify any Gradle file as the initialization script with -I <file name> or --init-script <file name>.
Along with project-level properties, you can also define system-level properties in the gradle.properties file. To define system-level properties, you can append properties with systemProp. So systemProp.sProp1=sVal1 will set sProp1 as a system-level property with the value sVal1.
You can define runtime properties on the command line also using the -P and -D options. Using -P, you can define project-specific properties. Using -D, you can define system-level properties. To access system-level properties, you can use System.properties['<propertyname>'].
https://medium.com/@wasyl/make-your-gradle-builds-fast-again-ea323ce6a435
http://www.gubatron.com/blog/2014/07/29/solved-gradle-how-to-increase-the-java-compilers-available-heap-memory/
compileJava {
//raise heap
options.fork = ‘true’
options.forkOptions.with {
memoryMaximumSize = “2048m”
}
}
These are the contents that made it work for both Mac and Windows (I’ve still not tested this on my linux box)
org.gradle.jvmargs=-Xms256m -Xmx1024m
https://coderwall.com/p/4g8znw/things-i-learned-while-writing-a-dockerfile
Could not create an instance of type org.gradle.invocation.DefaultGradle_Decorated
- check the ownership whether /.gradle is created correctly.
https://stackoverflow.com/questions/45387971/when-to-use-gradle-properties-vs-settings-gradle
https://www.packtpub.com/mapt/book/web_development/9781783982363/5/ch05lvl1sec29/the-settings.gradle-file
During initialization, Gradle reads the
The most common use of settings.gradle is to enlist all the subprojects participating in the build:
include ':repository', ':services', ':web-app'
https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Exec.html
https://stackoverflow.com/questions/29813189/how-do-i-extend-gradles-clean-task-to-delete-a-file
https://docs.gradle.org/current/userguide/userguide.html
https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:using_a_predicate
https://dzone.com/articles/gradle-goodness-running-single
https://stackoverflow.com/questions/18061774/run-single-integration-test-with-gradle/25442622#25442622
https://github.com/dougborg/gdub
brew install gdub
http://www.gdub.rocks/
echo "alias gradle=gw" >> ~/.bashrc source ~/.bashrc
http://trickyandroid.com/gradle-tip-1-tasks/
Closure is a standalone block of code which can take arguments, return values and be assigned to a variable.
buildscript { repositories { jcenter() } dependencies { classpath 'com.android.tools.build:gradle:1.2.3' } } allprojects { repositories { jcenter() } }
https://www.mkyong.com/gradle/how-to-use-gradle-wrapper/
https://blog.codefx.org/tools/snapshots-gradle-maven-publish-plugin/
http://blog.danlew.net/2015/09/09/dont-use-dynamic-versions-for-your-dependencies/
https://medium.com/@kuassivi/tip-work-with-third-party-projects-locally-with-gradle-961d6c9efb02
https://github.com/gradle/gradle-completion
https://www.petrikainulainen.net/programming/gradle/getting-started-with-gradle-creating-a-binary-distribution/
https://www.petrikainulainen.net/programming/gradle/getting-started-with-gradle-creating-a-multi-project-build/
./gradlew build
./gradlew idea
./gradlew allDeps --configuration compile
gradle.properties
build.gradle
apply plugin: 'idea'
idea {
project {
languageLevel = "${jdkVersion}"
}
}
subprojects {
apply plugin: 'idea'
apply plugin: 'java'
apply plugin: 'findbugs'
apply plugin: 'pmd'
sourceCompatibility = "${jdkVersion}"
findbugs {
ignoreFailures = true
}
pmd {
ignoreFailures = true
}
dependencies {
compile "com.intellij:annotations:${intellijAnnotationVersion}"
compile "org.slf4j:slf4j-api:${slf4jVersion}"
testCompile "com.google.guava:guava:${guavaVersion}"
testCompile "org.mockito:mockito-core:${mockitoVersion}"
testRuntime "log4j:log4j:${log4jVersion}"
testRuntime "org.slf4j:slf4j-log4j12:${slf4jVersion}"
}
configurations.all {
resolutionStrategy {
// We need this fix: https://github.com/netty/netty/issues/5648
force "io.netty:netty-all:4.0.41.Final"
}
}
// Allows to get the dependency tree for all modules at once with `gw allDeps`
task allDeps(type: DependencyReportTask) {}
}
http://mrhaki.blogspot.com/2016/11/gradle-goodness-replacing-operator-for.html
Gradle 3.2 deprecates the
https://solidsoft.wordpress.com/2014/11/13/gradle-tricks-display-dependencies-for-all-subprojects-in-multi-project-build/
You could think about
https://discuss.gradle.org/t/how-to-not-run-checkstyle-findbugs-tasks-automatically/7383/3
https://stackoverflow.com/questions/23527091/module-is-not-backed-by-gradle
Gradle uses a Domain Specific Language (DSL) based on Groovy to declare builds. The DSL provides a flexible language that can be extended by us.
convention-over-configuration
The Gradle Wrapper allows us to execute Gradle builds even if Gradle is not installed on a computer.
gradle -v
If we want to add JVM options to Gradle, we can use the JAVA_OPTS and GRADLE_OPTS environment variables. JAVA_OPTS is a commonly used environment variable name to pass extra parameters to a Java application. Gradle also uses the GRADLE_OPTS environment variable to pass extra arguments to Gradle
Software Development Kit Manager (SDKMAN!)
curl -s get.sdkman.io | bash
sdk install gradle
sdk use gradle 2.12
task helloWorld << {
println 'Hello world.'
}
The << syntax is, an operator shorthand for the leftShift()method, which actually means add to. Therefore, here we are defining that we want to add the closure (with the println 'Hello world' statement) to our task with the helloWorld name.
gradle --quiet helloWorld
Gradle daemon essentially keeps Gradle running in memory so that we don't get the penalty of starting the JVM each time we run Gradle.
Default Gradle tasks
gradle -q tasks
gradle -q help
gradle tasks
gradle -q properties
gradle -q projects
gradle -q model
Task name abbreviation
gradle -q hW
gradle -q hello
gradle helloWorld tasks
gradle init
project.description = 'Simple project'
Closures are basically reusable pieces of code that can be assigned to a variable or passed to a method. A closure is defined by enclosing the piece of code with curly brackets ({... }). We can pass one or more parameters to the closures. If the closure has only one argument, an implicit parameter, it, can be used to reference the parameter value.
task second {
doLast {
// Using implicit 'it' closure parameter.
// The type of 'it' is a Gradle task.
println "Running ${it.name}"
}
}
task second {
doLast { Task task ->
// Using explicit name 'task' as closure parameter.
// We also defined the type of the parameter.
// This can help the IDE to add code completion.
println "Running ${task.name}"
}
}
second.dependsOn 'first'
second.dependsOn = ['first']
task third(dependsOn: 'second') << { task ->
println "Run ${task.name}"
}
def printTaskName = { task ->
println "Run ${task.name}"
}
task second(dependsOn: first) << printTaskName
second.dependsOn {
// We use the Groovy method findAll
// that returns all tasks that
// apply to the condition we define
// in the closure: the task name
// starts with the letter 'f'.
project.tasks.findAll { task ->
task.name.contains 'f'
}
}
defaultTasks 'first', 'second'
gradle tasks --all
def taskGroup = 'base'
task second(
dependsOn: first,
description: 'Secondary task',
group: taskGroup) << {
println "I am second"
}
gradle help --task second
Gradle provides an ext namespace for the task object.
simple.ext.message = 'world'
task simple << {
println "Hello ${message}"
}
task longrunning {
// Only run this task if the
// closure returns true.
onlyIf { task ->
def now = Calendar.instance
def weekDay = now[DAY_OF_WEEK]
def weekDayInWeekend = weekDay in [SATURDAY, SUNDAY]
return weekDayInWeekend
}
// Add an action.
doLast {
println "Do long running stuff"
}
}
task listDirectory {
def dir = new File('assemble')
// Set value for enabled task property.
enabled = dir.exists()
// This is only executed if enabled is true.
doLast {
println "List directory contents: " +
dir.listFiles().join(',')
}
}
we can use the --exclude-tasks (-x) command-line option if we run the build.
check.dependsOn -= [integrationTest]
This would remove integrationTest task from check task.
task forceTest {
dependsOn "cleanTest", "cleanIntegrationTest", "test", "integrationTest"
}
// Exclude integrationTest from 'check' task
check.dependsOn -= [integrationTest]
We can exclude transitive dependencies easily from specific configurations. To exclude them from all configurations we can use Groovy's spread-dot operator and invoke the
exclude()
method on each configuration. We can only define the group, module or both as arguments for the exclude()
method.
configurations {
all*.exclude group: 'xml-apis', module: 'xmlParserAPIs'
}
// Equivalent to:
configurations {
all.collect { configuration ->
configuration.exclude group: 'xml-apis', module: 'xmlParserAPIs'
}
}
...
https://www.mkyong.com/gradle/gradle-display-project-dependency/
gradle {subproject}:dependencies
gradle :dependencyInsight --configuration compile --dependency jackson-databind
gradle dependencyInsight --dependency slf4j-api --configuration compilegradle dependencies --configuration runtime
https://stackoverflow.com/questions/12016681/how-to-change-gradle-download-location
http://mrhaki.blogspot.com/2010/09/gradle-goodness-changing-gradle-user.htmlcr
Or we can use the command-line options
$ export GRADLE_OPTS=-Dgradle.user.home=/Users/mrhaki/dev/gradle-g
and --gradle-user-home
when we run Gradle and use a different directory as a Gradle user home directory.
$ export GRADLE_USER_HOME=/Users/mrhaki/dev/gradle
$ gradle -d -r
# export M2_HOME=/m2
https://discuss.gradle.org/t/is-it-possible-to-configure-the-local-gradle-cache-folder-to-non-default-location/21851
https://gist.github.com/cr7pt0gr4ph7/6cd6339eabc2056bc3e7
The default behavior of Gradle to pick the newest version also applies if a lower version has been declared locally, but another dependency transitively pulls in a newer version. This is in contrast with Maven, where a locally declared version will always win.
For example, if your
build.gradle
specifies the dependency org.springframework:spring-tx:3.2.3.RELEASE
, and another dependency declares 4.0.5.RELEASE
as a transitive dependency, then 4.0.5.RELEASE
will take precedence:dependencies {
compile("org.springframework.data:spring-data-hadoop:2.0.0.RELEASE")
compile("org.springframework:spring-tx:3.2.3.RELEASE")
// will select org.springframework:spring-tx:4.0.5.RELEASE
}
Forcing specific versions
ResolutionStrategy.force(Object...)
:
Using
One option to force Gradle to use the specified version, thus obtaining a behavior similar to Maven, is to use
ResolutionStrategy.force(Object...)
:configurations.all {
resolutionStrategy {
force "org.springframework:spring-tx:3.2.3.RELEASE"
}
}
Using ExternalDependency.force
:
ExternalDependency.force
:
The other option is to use force
on the dependency itself:
dependencies {
compile("org.springframework.data:spring-data-hadoop:2.0.0.RELEASE")
compile("org.springframework:spring-tx:3.2.3.RELEASE") {
force = true
}
}
This is perhaps the option that is most similar to Maven.
Note that if both ResolutionStrategy.force
and ExternalDependency.force
are used, the former takes precedence over the latter.
https://github.com/gradle/gradle/issues/3317
org.gradle.tooling.GradleConnectionException: Could not create an instance of Tooling API implementation using the specified Gradle distribution 'https://services.gradle.org/distributions/gradle-4.2-bin.zip'.
Caused by: java.lang.IllegalArgumentException: Could not determine java version from '9.0.1'.
the project needs to use Gradle 4.2.1 or above. Alternatively you can start Eclipse with Java 8.
https://gradle.org/maven-vs-gradle/
Finally, Gradle provides an interactive web-based UI for debugging and optimizing builds: build scans. These can also be hosted on-premise to allow an organization to collect build history and do trend analysis, compare builds for debugging, or optimize build times.
https://github.com/gradle/gradle-completionhttps://dzone.com/articles/gradle-vs-maven
Gradle is a build automation system that is fully open source and uses the concepts you see on Apache Maven and Apache Ant. It uses domain-specific language based on the programming language Groovy, differentiating it from Apache Maven, which uses XML for its project configuration. It also determines the order of tasks run by using a directed acyclic graph.
Several developers created Gradle and first released in 2007, and in 2013, it was adopted by Google as the build system for Android projects. It was designed to support multi-project builds that are expected to be quite huge. It also allows for incrementally adding to your build, because it knows which parts of your project are updated. Tasks that are dependent on updated parts are no longer re-executed.
https://github.com/groovy/groovy-eclipse/wiki
https://blog.csdn.net/Calvin_zhou/article/details/78005407
- don't work ...
https://softdevbuilttolast.wordpress.com/2015/04/15/debugging-build-gradle-with-eclipse/
Before starting, make sure you have the following plugins installed:
- Gradle Plugin for Eclipse.
- Groovy Plugin for Eclipse.
gradle sayHello –Dorg.gradle.debug=true
gradle sayHello --daemon –Dorg.gradle.debug=true
http://www.jasondl.ee/posts/2013/gradle-tip-attaching-a-debugger.html
Maven offers a nice script to allow for attaching a debugger to your build,
mvnDebug
. Gradle does not. Again, though, Gradle makes it pretty easy to add this to your build.test { if (System.getProperty('DEBUG', 'false') == 'true') { jvmArgs '-Xdebug', '-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9009' } }
From the command line, issue
gradle -DDEBUG=true test
:run { if (System.getProperty('DEBUG', 'false') == 'true') { jvmArgs '-Xdebug', '-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9009' } }To add this all of your projects, you can make this change to init.gradle:
$HOME/.gradle/init.gradle
allprojects {
tasks.withType(Test) {
if (System.getProperty('DEBUG', 'false') == 'true') {
jvmArgs '-Xdebug',
'-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9009'
}
}
tasks.withType(JavaExec) {
if (System.getProperty('DEBUG', 'false') == 'true') {
jvmArgs '-Xdebug',
'-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9009'
}
}
}
https://stackoverflow.com/questions/24612906/android-gradle-project-directory-variable
See the Gradle docs. Specifically, you're interested in
projectDir
(The directory containing the build script) or buildDir
(projectDir/build).https://michelkraemer.com/recipes-for-gradle-download/
task downloadFiles(type: Download) {
src([
'http://central.maven.org/maven2/org/citationstyles/styles/1.0/styles-1.0.jar',
'http://central.maven.org/maven2/org/eclipse/jetty/jetty-server/9.1.3.v20140225/jetty-server-9.1.3.v20140225-javadoc.jar'
])
dest buildDir
overwrite true
}
https://stackoverflow.com/questions/24724383/add-resources-config-files-to-your-jar-using-gradle
Move the config files from
src/main/java
to src/main/resources
.
I found a solution that may be useful to someone. Here is my final configuration to get that:
sourceSets {
main {
resources {
srcDirs "src/main/resources", "src/main/configs"
}
}
}
https://stackoverflow.com/questions/44493378/whats-the-difference-between-implementation-and-compile-in-gradledependencies { api 'commons-httpclient:commons-httpclient:3.1' implementation 'org.apache.commons:commons-lang3:3.5' }
Dependencies appearing in theapi
configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers.Dependencies found in theimplementation
configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath. This comes with several benefits:
- dependencies do not leak into the compile classpath of consumers anymore, so you will never accidentally depend on a transitive dependency
- faster compilation thanks to reduced classpath size
- less recompilations when implementation dependencies change: consumers would not need to be recompiled
- cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that distinguish exactly between what is required to compile against the library and what is required to use the library at runtime (in other words, don't mix what is needed to compile the library itself and what is needed to compile against the library).
The compile configuration still exists but should not be used as it will not offer the guarantees that the api and implementation configurations provide.
tl;dr
Just replace:
compile
withimplementation
testCompile
withtestImplementation
debugCompile
withdebugImplementation
androidTestCompile
withandroidTestImplementation
compileOnly
is still valid. It was added in 3.0 to replace provided and not compile. (provided
introduced when Gradle didn't have a configuration name for that use-case and named it after Maven's provided scope.)
https://stackoverflow.com/questions/21645071/using-gradle-to-find-dependency-tree
Additionally, if you want to check if something is
compile
vs. testCompile
vs androidTestCompile
dependency as well as what is pulling it in:./gradlew :app:dependencyInsight --configuration compile --dependency <name>
./gradlew :app:dependencyInsight --configuration testCompile --dependency <name>
./gradlew :app:dependencyInsight --configuration androidTestCompile --dependency <name>
tasks.withType(Javadoc).all { enabled = false } // non ascii characters make it crash
if (JavaVersion.current().isJava8Compatible()) {
allprojects {
tasks.withType(Javadoc) {
options.addStringOption('Xdoclint:none', '-quiet')
}
}
shadowJar
http://imperceptiblethoughts.com/shadow/
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.github.jengelman.gradle.plugins:shadow:2.0.4'
}
}
apply plugin: 'com.github.johnrengelman.shadow'
apply plugin: 'java'
Alternatively, the Gradle Plugin syntax can be used:
plugins {
id 'com.github.johnrengelman.shadow' version '2.0.4'
id 'java'
}
https://stackoverflow.com/questions/13565082/how-can-i-force-gradle-to-redownload-dependencies
If you are using recent version of Gradle, you can use --refresh-dependencies option.
./gradlew build --refresh-dependencies
you can refer the gradle manual.
The --refresh-dependencies option tells Gradle to ignore all cached entries for resolved modules and artifacts. A fresh resolve will be performed against all configured repositories, with dynamic versions recalculated, modules refreshed, and artifacts downloaded.
Generally, you can refresh dependencies in your cache with the command line option --refresh-dependencies. You can also delete the cached files under
~/.gradle/caches
. With the next build Gradle would attempt to download them again.NullPointerException org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:37)
I was getting exactly same error and I changed the version of gradle that I was using. Inside my gradle-wrapper.properties, changed version 2.4 to 2.2.1 and error is gone.
To run all tasks without an up-to-date check we use the option
http://mrhaki.blogspot.com/2014/11/gradle-goodness-check-task-dependencies.html--rerun-tasks
:$ gradle --rerun-tasks assembleTo run a Gradle build as a dry run we can use the command line option
-m
or --dry-run
.https://stackoverflow.com/questions/19396876/gradle-download-dependency-merge-into-maven-local-repository?rq=1
Gradle has its own cache, although it can read the maven local repo like this:
repositories {
mavenLocal()
mavenCentral()
}
If some dependency not found in maven local repo, Gradle will download it from maven central and cache it in ~/.gradle/caches/...
http://mrhaki.blogspot.com/2012/10/gradle-goodness-init-script-for-adding.html
apply plugin: 'eclipse'
- Put a file called
init.gradle
in theUSER_HOME/.gradle/
directory. - Put a file that ends with
.gradle
in theUSER_HOME/.gradle/init.d/
directory.
.gradle
in the GRADLE_HOME/init.d/
directory, in the Gradle distributionrepositories { mavenCentral() }
allprojects { repositories { mavenLocal() } }https://discuss.gradle.org/t/how-do-i-get-rid-of-version-numbers-and-unspecified-on-java-plugin-jars/7512/
jar {
version = null
}
https://stackoverflow.com/questions/44324060/what-does-gradle-build-task-include-exactly
You can use the Gradle Task Tree Plugin to see the task dependencies
eg:
plugins {
id "com.dorongold.task-tree" version "1.3"
}
Then run
gradle build taskTree
Output
:build
+--- :assemble
| \--- :jar
| \--- :classes
| +--- :compileJava
| \--- :processResources
\--- :check
\--- :test
+--- :classes
| +--- :compileJava
| \--- :processResources
\--- :testClasses
+--- :compileTestJava
| \--- :classes
| +--- :compileJava
| \--- :processResources
\--- :processTestResources
gradle build --console=plainhttps://www.slideshare.net/ynnek13/4f-migrating-to-gradle
https://docs.gradle.org/current/userguide/java_plugin.html
http://www.ekiras.com/2016/12/gradle-build-life-cycle-phases-gradle.html
Initialization
- In this phase the gradle build is initialized. Gradle scans the project and its sub projects to create aProject
instance of each project and sub project.Configuration
- In this phase the gradle build is configured. In this phase aTask tree
is created which determines how and when to run the tasks.Execution
- In this phase the gradle build is executed. This phase actually runs the tasks configured in the configuration phase.
https://www.mkyong.com/gradle/gradle-create-java-project-structure-automatically/
To quick start a new Gradle Java project, type
distributionUrl=https\://services.gradle.org/distributions/gradle-4.1-bin.zipgradle init --type java-library
In order to achieve separation of concerns we can separate the different types of tests (e.g. unit, integration, acceptance), allowing us to prioritise unit tests and other verification tasks before integration tests in our task execution graph, thus reducing time spent waiting on all of the tests to fail before determining that one early and quick-to-execute unit test had failed early on in the process. Failing fast is an important concept of the Agile software development methodology as it allows the learning process to begin as early as possible, providing the shortest feedback loop available for the developer to begin fixing a failing test.
a SourceSet represents a set of Java source files and miscellaneous resources, the directories for which we need to configure relative to the working directory of the sub-project.
The following code creates a new SourceSet named
integTest
and configures the directory paths for both its Java source files and resource files:sourceSets {
integTest {
java.srcDir 'src/integTest/java'
resources.srcDir 'src/integTest/resources'
}
}
dependencies {
integTestCompile sourceSets.main.output
integTestCompile sourceSets.test.output
integTestCompile configurations.compile
integTestCompile configurations.testCompile
integTestRuntime configurations.runtime
integTestRuntime configurations.testRuntime
}
- Provides, at compile-time, the classes produced by the
main
andtest
SourceSets, allowing the integration tests to access the production code inmain
and allowing them to reuse any unit test helper methods intest
. - Provides, at compile-time, the dependencies that both
main
andtest
require in order to successfully compile. - Provides, at run-time, the dependencies that both
main
andtest
require to run.
https://gist.github.com/mychaelstyle/9826322
apply plugin: "findbugs"
apply plugin: "pmd"
findbugs {
ignoreFailures = true
}
pmd {
ignoreFailures = true
}
debug test
https://github.com/robolectric/robolectric-gradle-plugin/wiki/Debugging-the-Plugin
- Execute this at the root of your project:
GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5006" ./gradlew test --no-daemon -Dorg.gradle.debug=true
- Point a remote debugger to port 5006. In Intellij set up 'Remote' Debug configuration and set the port (actual port can be changed)
https://stackoverflow.com/questions/28437636/how-to-debug-a-gradle-build-gradle-file-in-a-debugger-with-breakpoints
export GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
https://docs.gradle.org/current/userguide/userguide_single.html-s
,--stacktrace
- Print out the stacktrace also for user exceptions (e.g. compile error). See also logging options.
-Dorg.gradle.debug=true
- Debug Gradle client (non-Daemon) process. Gradle will wait for you to attach a debugger at
localhost:5005
by default. -Dorg.gradle.daemon.debug=true
- Debug Gradle Daemon process.
org.gradle.debug=(true,false)
When set to
true
, Gradle will run the build with remote debugging enabled, listening on port 5005. Note that this is the equivalent of adding -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
to the JVM command line and will suspend the virtual machine until a debugger is attached. Default is false
.org.gradle.logging.level=(quiet,warn,lifecycle,info,debug)
When set to quiet, warn, lifecycle, info, or debug, Gradle will use this log level. The values are not case sensitive. The
lifecycle
level is the default. See the section called “Choosing a log level”Debugging
The test task provides a
Test.getDebug()
property that can be set to launch to make the JVM wait for a debugger to attach to port 5005 before proceeding with test execution.
This can also be enabled at invocation time via the
--debug-jvm
task option (since Gradle 1.12).--parallel
./gradlew clean build --profile --daemon -x test -x findbugsMain -x findbugsTest -x findbugsIntegrationTest -x pmdMain -x pmdTest -x pmdIntegrationTest -x testClasses -x integrationTestClasses -x javadoc -x javadocJar
publishToMavenLocal --dry-run --profile --daemon
./gradlew clean build publishToMavenLocal --profile --daemon -x test -x findbugsMain -x findbugsTest -x findbugsIntegrationTest -x pmdMain -x pmdTest -x pmdIntegrationTest -x testClasses -x integrationTestClasses --parallel
./gradlew android:assembleDebug --profile
— profile will tell gradle to measure the time taken to execute each task and dump that data into HTML file. You can find that report under /projectDir/build/reports/profile directory.
Gradle has three distinct phases in build life cycle:
- Initialisation: In this stage of the build life cycle, gradle picks the project and decides what things to build.
- Configuration: Here, gradle will evaluate your build.gradle script, configure all the plugins and evaluate the task graph.
- Execution: In this phase gradle actually runs all the task those were evaluated in previous phase to get the work done and build the application.
As you can see that out of all three phases, only execution phase performs all the operations.
That means that first two phases are just overhead to the gradle build process. We don’t care about them. But, sadly whenever you do anything with gradle this two phases will always get executed.
So, how can we measure the time taken to execute first two phases? Luckily, gradle provides — dry-run command, that tells gradle to evaluate the project but don’t run any task. Thus execution phase won’t get executed. So, run this command in your terminal:
./gradlew android:assembleDebug --dry-run --profile
You can see in above statistics that gradle passed almost 7.8 seconds just to initialise and configure the project. That is completely waste of time for us.
Gradle provides — configure-on-demand flag, that will tell gradle to only build the projects that it really needs to build. Let’s run this command.
./gradlew android:assembleDebug --dry-run --profile --configure-on-demand
--daemon
Always keep your gradle up-to-date:
So, always make sure that you are using the latest version of the gradle. You can go to /gradle/wrapper/gradle-wrapper.properties and upgrade gradle version by changing distributionUrl.
gradle assemble
To list all available tasks for your project, try:
gradle tasks
- Avoid heavy computations, like increasing the version code from git commits count or downloading some files from url while building the project. Gradle will spend time to perform those computations or network operations and that will afftect build timings.
- Don’t use dynamic dependency like,
compile 'com.android.support:appcompat-v7:23.0.+'
If you are using the dynamic dependencies, gradle will go online and check if there is any newer version for the library is available or not? (Most of the time, it is just waste of the precious build time). Instead, use the fixed dependencies and update them manually time to time.
compile 'com.android.support:appcompat-v7:23.0.2'
org.gradle.daemon=true
# Try and findout the best heap size for your project build.
org.gradle.jvmargs=-Xmx3096m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
# Modularise your project and enable parallel build
org.gradle.parallel=true
# Enable configure on demand.
org.gradle.configureondemand=true
Increase the heap size:
there is now no reason to use
mavenCentral()
over jcenter()
in your repositories
blocks. JCenter
is bigger, more secure and - even if ever so slightly - faster.
Use specific dependencies versions
--parallel
- Add mavenLocal() as a repository location in the main build.gradle
- Make sure mavenLocal() is in the first position of the list.
findbugs {
ignoreFailures = true
}
if (JavaVersion.current().isJava8Compatible()) {
tasks.withType(Javadoc) {
// disable the super-strict doclint tool in Java 8
options.addStringOption('Xdoclint:none', '-quiet')
}
}
./gradlew publishToMavenLocal
http://mrhaki.blogspot.com/2009/11/gradle-goodness-changing-project-name.html
So what can we do? We must create a file
settings.gradle
and set the property rootProject.name
:rootProject.name = 'newProjectName' |
We can check the name of our project has changed by running the following command again:
$ gradle -r | grep name name: newProjectName |
Project names can only be changed in
settings.gradle
. For example:include "foo" // or `includeFlat`, doesn't matter
// always good to nail down the root project name, because
// the root directory name may be different in some envs (e.g. CI)
// hence the following even makes sense for single-project builds
rootProject.name = "bar"
// change subproject name
project(":foo").name = "foofoo"
Alternatively, you can use the desired project name in the
include
statement, and later reconfigure the project directory:include "foofoo"
project(":foofoo").projectDir = file("foo")
To give some background, the only difference between
include
and includeFlat
is that they use different defaults for the project's projectDir
. Otherwise they are the same.gradle sayHello --daemon –Dorg.gradle.debug=true
https://stackoverflow.com/questions/32352816/what-the-difference-in-applying-gradle-plugin
apply plugin: 'someplugin1'
apply plugin: 'maven'
and other one:
plugins {
id 'org.hidetake.ssh' version '1.1.2'
}
The
plugins
block is the newer method of applying plugins, and they must be available in the Gradle plugin repository. The apply
approach is the older, yet more flexible method of adding a plugin to your build.
The new
plugins
method does not work in multi-project configurations (subprojects
, allprojects
), but will work on the build configuration for each child project.
I would think that as functionality progresses, the
plugins
configuration method will overtake the older approach, but at this point both can be and are used concurrently.apply plugin: 'eclipse'
apply plugin: 'maven-publish'
apply plugin: "maven"
repositories {
mavenLocal()
}
Start up script
All the files with .gradle extension under <USER_HOME>/.gradle/init.d directory are treated as initialization scripts.
init.gradle under <USER_HOME>/.gradle/ are treated as an initialization script
All the files with the .gradle extension under <GRADLE_HOME>/init.d/ directory.
You can even specify any Gradle file as the initialization script with -I <file name> or --init-script <file name>.
Along with project-level properties, you can also define system-level properties in the gradle.properties file. To define system-level properties, you can append properties with systemProp. So systemProp.sProp1=sVal1 will set sProp1 as a system-level property with the value sVal1.
You can define runtime properties on the command line also using the -P and -D options. Using -P, you can define project-specific properties. Using -D, you can define system-level properties. To access system-level properties, you can use System.properties['<propertyname>'].
https://medium.com/@wasyl/make-your-gradle-builds-fast-again-ea323ce6a435
http://www.gubatron.com/blog/2014/07/29/solved-gradle-how-to-increase-the-java-compilers-available-heap-memory/
compileJava {
//raise heap
options.fork = ‘true’
options.forkOptions.with {
memoryMaximumSize = “2048m”
}
}
These are the contents that made it work for both Mac and Windows (I’ve still not tested this on my linux box)
org.gradle.jvmargs=-Xms256m -Xmx1024m
https://coderwall.com/p/4g8znw/things-i-learned-while-writing-a-dockerfile
I originally was using one RUN command per shell line that I wanted to exectue:
Example:
RUN service postgresql start
RUN su postgres -c "createuser -d -r -s root"
The Problem
I wanted to separate the commands in order to optimize recreation of other images. But I'd always get the error that postgres wasn't running. That's exactly because each RUN command is a separate layer of running machine. Starting postgres in a RUN command does nothing because as soon as the next RUN command is reached, I'm in a new VM, and there's no postgres running at all.
The Solution
Join commands that are part of one cohesive set up step into one RUN statement:
(Note, thanks @outrunthewolf for pointing out that line continuations
(Note, thanks @outrunthewolf for pointing out that line continuations
\
can be used to carry the same command across multiple lines for readability).RUN service postgresql start && \
su postgres -c "createuser -d -r -s root"
Online guides for installing and setting up postgres instruct the user to run commands as sudo
, but this won't work with a Dockerfile because the commands are running as root, and root doesn't have access to the sudo
command.
The Solution
Use su {USER} -c "commands go here"
instead to execute commands as a different user.
FROM ubuntu
MAINTAINER Murphy Randle, murphy@spacemonkey.com
# Install Postgresql deps
RUN apt-get install -y postgresql postgresql-contrib
# Postgresql setup:
RUN service postgresql start && su postgres -c "createuser -d -r -s root" && createdb accounts && service postgresql stop
ENTRYPOINT ["/bin/bash"]
Could not create an instance of type org.gradle.invocation.DefaultGradle_Decorated
- check the ownership whether /.gradle is created correctly.
https://stackoverflow.com/questions/45387971/when-to-use-gradle-properties-vs-settings-gradle
A gradle build has three files
build.gradle
that defines the build configuration scriptsgradle.properties
settings.gradle
The
settings.gradle
file is, just like the build.gradle
file, a Groovy script. Only one settings.gradle
script will be executed in each build (in comparison to the build.gradle
script in multi-project builds). It will be executed before any build.gradle
and even before the Project
instances are created. Therefore, it is evaluated against a Settings
object. With this Settings
object, you can add subprojects to your build, modify the parameters from the command line (StartParameter
) and access the Gradle
object to register lifecycle handlers. Use the file, if your settings are build-related and not necessarily project-related or require logic before possible subprojects are included.
The
gradle.properties
file is a simple Java Properties
file, that only gains it special role by being automatically included into the scope of the Project
object (as so-called project properties). It's a simple key-value store, that only allows string values (so you need to split lists or arrays by yourself). You can put gradle.properties
files to these locations:- directly in the project directory (for project-related values)
- in the user home
.gradle
directory (for user- or environment-related values)
https://www.packtpub.com/mapt/book/web_development/9781783982363/5/ch05lvl1sec29/the-settings.gradle-file
During initialization, Gradle reads the
settings.gradle
file to figure out which projects are to take part in a build. Gradle creates an object of type Setting
. This happens even before any build.gradle
is parsed. It is usually placed in the root project parallel to build.gradle
. It is recommended to put setting.gradle
in the root project, otherwise we have to explicitly tell Gradle the location to the settings file with the command-line option -c.
The most common use of settings.gradle is to enlist all the subprojects participating in the build:
include ':repository', ':services', ':web-app'
task stopTomcat(type:Exec) { workingDir '../tomcat/bin' //on windows: commandLine 'cmd', '/c', 'stop.bat' //on linux commandLine './stop.sh' //store the output instead of printing to the console: standardOutput = new ByteArrayOutputStream() //extension method stopTomcat.output() can be used to obtain the output: ext.output = { return standardOutput.toString() } }https://stackoverflow.com/questions/30636905/gradle-copy-file-after-its-generation
The culprit is your
copyJarToBin
task. when doingtask copyJarToBin {
copy {
from 'build/libs/GradleJarProject.jar'
into "d:/tmp"
}
}
you copy the jar during the configuration time by using the
copy
method. (see the gradle user guide at https://docs.gradle.org/current/userguide/userguide_single.html#sec:build_phases to understand the build lifecycle) You want to run the actual copy operation during the execution phase (the execution of the task).
One way to solve that is to move the call of the
copy
method into a doLast block:task copyJarToBin {
doLast {
copy {
from 'build/libs/GradleJarProject.jar'
into "d:/tmp"
}
}
}
The problem with this approach is that you won't benefit of gradles incremental build feature and copy that file every single time you execute the task even though the file hasn't changed.
A better and more idionmatic way of writing your copyJarToBin task is to change your task implementation to use the
Copy
task type:task copyJarToBin(type: Copy) {
from 'build/libs/GradleJarProject.jar'
into "d:/tmp"
}
We can even improve this snippet by taking advantage of gradle's autowiring feature. You can declare the output of one task as input to another. So instead of writing `build/libs/GradleJarProject.jar' you can simply do:
task copyJarToBin(type: Copy) {
from createJar // shortcut for createJar.outputs.files
into "d:/tmp"
}
Now you don't need to bother about task ordering as gradle know that the
createJar
task must be executed before the copyJarToBin
task can be executed.https://stackoverflow.com/questions/29813189/how-do-i-extend-gradles-clean-task-to-delete-a-file
<<
is equivalent for clean.doLast
. doFirst
and doLast
are ordering the operations at the execution phase, which is seldom relevant for delete operations.
In this case you don't need any of them. The clean task from base is of type Delete, so you simply need to pass it a closure to tell it at configuration time what to delete when it executes:
clean {
delete 'someFile'
}
AS mushfek0001 correctly points it out in his answer, you should use double quotes for variable interpolation to work:
clean {
delete "${buildDir}/someFile"
}
You need to have at least the base plugin applied for this to work, most other plugins, like the Java plugin either apply base or declare their own
clean
task of type delete Delete task. The error you would get if you don't have this is a missing clean
method one.apply plugin: 'base'
https://docs.gradle.org/current/userguide/userguide.html
https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:using_a_predicate
task hello { doLast { println 'hello world' } } hello.onlyIf { !project.hasProperty('skipHello') }
Output of
gradle hello -PskipHello
> gradle hello -PskipHello
https://dzone.com/articles/gradle-goodness-running-single
https://stackoverflow.com/questions/18061774/run-single-integration-test-with-gradle/25442622#25442622
//select specific test method
gradle test --tests org.gradle.SomeTest.someFeature
//select specific test class
gradle test --tests org.gradle.SomeTest
//select all tests from package
gradle test --tests org.gradle.internal*
//select all ui test methods from integration tests by naming convention
gradle test --tests *IntegTest*ui*
//selecting tests from different test tasks
gradle test --tests *UiTest integTest --tests *WebTest*ui
https://github.com/dougborg/gdub
brew install gdub
http://www.gdub.rocks/
echo "alias gradle=gw" >> ~/.bashrc source ~/.bashrc
Again, with
gw
this becomes:$ gw build
Gradle task has 2 major stages in its lifecycle:
- Configuration stage
- Execution stage
And the answer is - the part specified within the top-level of the task - is task configuration section. I.e:
task myTask {
def name = "Pavel" //<-- this is evaluated during configuration
println "Hello, World!"////<-- this is also evaluated during configuration
}
That's why when I call
gradle tasks
I can see "Hello, World!" - this is our configuration section is executed. But that's not really what I want - I want "Hello, World!" to be printed only when I explicitly call my task.task myTask {
def text = 'Hello, World!' //configure my task
doLast {
println text //this is executed when my task is called
}
}
http://trickyandroid.com/gradle-tip-2-understanding-syntax/Closure is a standalone block of code which can take arguments, return values and be assigned to a variable.
def myClosure = {String str -> println str }
//execute our closure
myClosure('Hello world!')
Or if closure accepts only 1 parameter, it can be referenced as
it
:def myClosure = {println it }
//execute our closure
myClosure('Hello world!')
def myClosure = {String str, int num -> println "$str : $num" }
Another cool feature is that current context for the closure can be changed by calling Closure#setDelegate()
. This feature will become very important later:
def myClosure = {println myVar} //I'm referencing myVar from MyClass class
MyClass m = new MyClass()
myClosure.setDelegate(m)
myClosure()
class MyClass {
def myVar = 'Hello from MyClass!'
}
at the moment when we created closure, myVar
variable doesn't exist. And this is perfectly fine - it should be present in the closure context at the point when we execute this closure.
In this case I modified current context for the closure right before I executed it, so myVar
is available.
Pass closure as an argument
The real benefit of having closures - is an ability to pass closure to different methods which helps us to decouple execution logic.
- method accepts 1 parameter - closure
myMethod(myClosure)
- if method accepts only 1 parameter - parentheses can be omitted
myMethod myClosure
- I can create in-line closure
myMethod {println 'Hello World'}
- method accepts 2 parameters
myMethod(arg1, myClosure)
- or the same as '4', but closure is in-line
myMethod(arg1, { println 'Hello World' })
- if last parameter is closure - it can be moved out of parentheses
myMethod(arg1) { println 'Hello World' }
buildscript { repositories { jcenter() } dependencies { classpath 'com.android.tools.build:gradle:1.2.3' } } allprojects { repositories { jcenter() } }
- there is (somewhere) a
buildscript
method which accepts closure:def buildscript(Closure closure)
- there is (somewhere) a
allprojects
method which accepts closure:def allprojects(Closure closure)
If we search for
buildscript
- we will find buildscript {}
script block. But wait.. What the hell is script block??? According to documentation:
If we keep reading
ScriptHandler from buildscript. It means that execution scope for the closure we pass as an input parameter will be changed to ScriptHandler. In our case we passed closure which executes
buildscript
documentation - it says: Delegates to:ScriptHandler from buildscript. It means that execution scope for the closure we pass as an input parameter will be changed to ScriptHandler. In our case we passed closure which executes
repositories(Closure)
and dependencies(Closure)
methods. Since closure is delegated to ScriptHandler
, let's try to search for dependencies
method within ScriptHandler
class.
And here it is - void dependencies(Closure configureClosure), which according to documentation, configures dependencies for the script. Here we are seeing another terminology: Executes the given closure against the DependencyHandler. Which means exactly the same as "delegates to [something]" - this closure will be executed in scope of another class (in our case - DependencyHandler)
"delegates to [something]" and "configures [something]" - 2 statements which mean exactly the same - closure will be execute against specified class.
For the sake of completeness, let's see what is happening when we execute closure
{classpath 'com.android.tools.build:gradle:1.2.3'}
within DependencyHandler
context. According to documentation this class configures dependencies for given configuration and the syntax should be:<configurationName> <dependencyNotation1>
So with our closure we are configuring configuration with name
classpath
to use com.android.tools.build:gradle:1.2.3
as a dependency.B.dependsOn A
task A << {println 'Hello from A'}
task B {
dependsOn A
doLast {
println 'Hello from B'
}
}
That's where
mustRunAfter
method comes into play. It tells Gradle to run task aftertask specified as an argument. So essentially, we do not introduce dependency between our unit tests and UI tests, but instead we told Gradle to give unit tests priority if they are executed together, so unit tests are executed before our UI test suite:task unit << {println 'Hello from unit tests'}
task ui << {println 'Hello from UI tests'}
task tests << {println 'Hello from all tests!'}
tests.dependsOn unit
tests.dependsOn ui
ui.mustRunAfter unit
1.1 Declares a wrapper task.
build.gradle
task wrapper(type: Wrapper) {
gradleVersion = '2.10' //we want gradle 2.10 to run this project
}
1.2 Run the wrapper task with
gradle wrapper
$ gradle wrapper
:wrapper
https://discuss.gradle.org/t/buildship-is-using-gradle-v2-2-but-it-is-not-clear-why-or-how-to-change/19691/2https://blog.codefx.org/tools/snapshots-gradle-maven-publish-plugin/
http://blog.danlew.net/2015/09/09/dont-use-dynamic-versions-for-your-dependencies/
compile 'com.android.support:appcompat-v7:23.0.+'
./gradlew ABC:build
gradle :ABC:build
The leading :
stands for the root project. ABC
is the subproject, and build
a task in that project.
./gradlew build publishToMavenLocal
buildscript {
repositories {
mavenLocal()
...
allprojects {
repositories {
mavenLocal()
...
Have into account that mavenlLocal() will always pick up libraries available in the /.m2 folder at first.
https://github.com/gradle/gradle-completion
https://www.petrikainulainen.net/programming/gradle/getting-started-with-gradle-creating-a-binary-distribution/
apply plugin:
'application'
apply plugin:
'java'
repositories {
mavenCentral()
}
dependencies {
compile
'log4j:log4j:1.2.17'
testCompile
'junit:junit:4.11'
}
mainClassName =
'net.petrikainulainen.gradle.HelloWorld'
The application plugin adds five tasks to our project:
- The run task starts the application.
- The startScripts task creates startup scripts to the build/scripts directory. This tasks creates startup scripts for Windows and *nix operating systems.
- The installApp task installs the application into the build/install/[project name] directory.
- The distZip task creates the binary distribution and packages it into a zip file that is found from the build/distributions directory.
- The distTar task creates the binary distribution and packages it into a tar file that is found from the build/distributions directory.
https://www.petrikainulainen.net/programming/gradle/getting-started-with-gradle-creating-a-multi-project-build/
- Create the settings.gradle file to the root directory of the root project. A multi-project Gradle build must have this file because it specifies the projects that are included in the multi-project build.
apply plugin: 'java' repositories { mavenCentral() } dependencies { testCompile 'junit:junit:4.11' }
If we want to add common configuration to the subprojects of our root project, we have to add the following snippet to the build.gradle file of our root project:
After we have removed the duplicate configuration from the build.gradle file of our root project, it looks as follows:
If we have configuration that is shared by all projects of our multi-project build, we should add the following snippet to the build.gradle file of our root project:
The core/build.gradle file looks as follows:
The app/build.gradle file looks as follows:
https://stackoverflow.com/questions/26983771/skip-tests-in-intellij-using-gradle |
./gradlew build -x test
https://docs.gradle.org/current/userguide/java_plugin.html#N1231D./gradlew build
./gradlew idea
./gradlew allDeps --configuration compile
gradle.properties
build.gradle
apply plugin: 'idea'
idea {
project {
languageLevel = "${jdkVersion}"
}
}
subprojects {
apply plugin: 'idea'
apply plugin: 'java'
apply plugin: 'findbugs'
apply plugin: 'pmd'
sourceCompatibility = "${jdkVersion}"
findbugs {
ignoreFailures = true
}
pmd {
ignoreFailures = true
}
dependencies {
compile "com.intellij:annotations:${intellijAnnotationVersion}"
compile "org.slf4j:slf4j-api:${slf4jVersion}"
testCompile "com.google.guava:guava:${guavaVersion}"
testCompile "org.mockito:mockito-core:${mockitoVersion}"
testRuntime "log4j:log4j:${log4jVersion}"
testRuntime "org.slf4j:slf4j-log4j12:${slf4jVersion}"
}
configurations.all {
resolutionStrategy {
// We need this fix: https://github.com/netty/netty/issues/5648
force "io.netty:netty-all:4.0.41.Final"
}
}
// Allows to get the dependency tree for all modules at once with `gw allDeps`
task allDeps(type: DependencyReportTask) {}
}
http://mrhaki.blogspot.com/2016/11/gradle-goodness-replacing-operator-for.html
Gradle 3.2 deprecates the
<<
operator to add actions to a task. The <<
operator maps to the leftShift
method of a task. This operator confuses a lot people that are new to Gradle. Because without the operator we are configuring a task instead of adding actions. I can tell from experience the mistake is easily made. If we use the <<
in our build script with Gradle 3.2 we get a warning on the console. The warning message already mentions a solution: use the doLast
method to add actions.// Since Gradle 3.2 the << (leftShift) operator
// is deprecated. The operator can confuse
// people, because without the operator
// we would configure the deprecatedSample task,
// instead of adding the action statement:
// println 'Sample task'.
task deprecatedSample << {
println
'Sample task'
}
// To have no confusion we should use
// the doLast method of a task to add
// the action statement:
// println 'Sample task'.
task newSample {
doLast {
println
'Sample task'
}
}
https://solidsoft.wordpress.com/2014/11/13/gradle-tricks-display-dependencies-for-all-subprojects-in-multi-project-build/
You could think about
--recursive
or --with-submodules
flags, but they do not exist. It is possible to display dependencies for subprojects with “gradle sub1:dependencies
” and “gradle sub2:dependencies
“subprojects { task allDeps(type: DependencyReportTask) {} } |
When called
All dependencies belong to us, but some parts of the tree looks similar (and duplication is a bad thing). Especially configurations gradle allDeps
it executes dependencies
task on all subprojects.default
, compile
and runtime
and the second group testCompile
and testRuntime
in most cases contain (almost) the same set of dependencies. To make the output shorter we could limit it to runtime
(or in case of test dependencies testRuntime
). dependencies
task provides convenient parameter --configuration
and to focus on test dependencies “gradle allDeps --configuration testRuntime
” can be used.https://discuss.gradle.org/t/how-to-not-run-checkstyle-findbugs-tasks-automatically/7383/3
I know that I could use the "-x" flag but doign "gradle build -x findbugsMain -x findbugsTest -x checkStyleMain -x checkStyleTest" every time is a bit unwieldy. What I would like to be able to do is to run "gradle build" and not have any of the findbugs or checkstyle tasks run. I would explicitly run the tasks (e. g. "gradle findbugsMain") whenever I would want to analyze the code.
gradle.properties: findbugs = false
build.gradle: apply plugin: 'findbugs' ... findbugsMain.onlyIf {project.properties['findbugs'].toBoolean()}
This will cause findbugsMain to be skipped unless the property is overridden:
gradle -Pfindbugs='true' findbugsMain
https://stackoverflow.com/questions/23527091/module-is-not-backed-by-gradle
If you didn't set up the IDE project via "Import Project" and then pointing to a Gradle project, you may have to link the IDE project to the Gradle project. This can be done in the "Gradle" window.
Gradle uses a Domain Specific Language (DSL) based on Groovy to declare builds. The DSL provides a flexible language that can be extended by us.
convention-over-configuration
The Gradle Wrapper allows us to execute Gradle builds even if Gradle is not installed on a computer.
gradle -v
If we want to add JVM options to Gradle, we can use the JAVA_OPTS and GRADLE_OPTS environment variables. JAVA_OPTS is a commonly used environment variable name to pass extra parameters to a Java application. Gradle also uses the GRADLE_OPTS environment variable to pass extra arguments to Gradle
Software Development Kit Manager (SDKMAN!)
curl -s get.sdkman.io | bash
sdk install gradle
sdk use gradle 2.12
task helloWorld << {
println 'Hello world.'
}
The << syntax is, an operator shorthand for the leftShift()method, which actually means add to. Therefore, here we are defining that we want to add the closure (with the println 'Hello world' statement) to our task with the helloWorld name.
gradle --quiet helloWorld
Gradle daemon essentially keeps Gradle running in memory so that we don't get the penalty of starting the JVM each time we run Gradle.
Default Gradle tasks
gradle -q tasks
gradle -q help
gradle tasks
gradle -q properties
gradle -q projects
gradle -q model
Task name abbreviation
gradle -q hW
gradle -q hello
gradle helloWorld tasks
gradle init
project.description = 'Simple project'
Closures are basically reusable pieces of code that can be assigned to a variable or passed to a method. A closure is defined by enclosing the piece of code with curly brackets ({... }). We can pass one or more parameters to the closures. If the closure has only one argument, an implicit parameter, it, can be used to reference the parameter value.
task second {
doLast {
// Using implicit 'it' closure parameter.
// The type of 'it' is a Gradle task.
println "Running ${it.name}"
}
}
task second {
doLast { Task task ->
// Using explicit name 'task' as closure parameter.
// We also defined the type of the parameter.
// This can help the IDE to add code completion.
println "Running ${task.name}"
}
}
second.dependsOn 'first'
second.dependsOn = ['first']
task third(dependsOn: 'second') << { task ->
println "Run ${task.name}"
}
def printTaskName = { task ->
println "Run ${task.name}"
}
task second(dependsOn: first) << printTaskName
second.dependsOn {
// We use the Groovy method findAll
// that returns all tasks that
// apply to the condition we define
// in the closure: the task name
// starts with the letter 'f'.
project.tasks.findAll { task ->
task.name.contains 'f'
}
}
defaultTasks 'first', 'second'
gradle tasks --all
def taskGroup = 'base'
task second(
dependsOn: first,
description: 'Secondary task',
group: taskGroup) << {
println "I am second"
}
gradle help --task second
Gradle provides an ext namespace for the task object.
simple.ext.message = 'world'
task simple << {
println "Hello ${message}"
}
task longrunning {
// Only run this task if the
// closure returns true.
onlyIf { task ->
def now = Calendar.instance
def weekDay = now[DAY_OF_WEEK]
def weekDayInWeekend = weekDay in [SATURDAY, SUNDAY]
return weekDayInWeekend
}
// Add an action.
doLast {
println "Do long running stuff"
}
}
task listDirectory {
def dir = new File('assemble')
// Set value for enabled task property.
enabled = dir.exists()
// This is only executed if enabled is true.
doLast {
println "List directory contents: " +
dir.listFiles().join(',')
}
}
we can use the --exclude-tasks (-x) command-line option if we run the build.
check.dependsOn -= [integrationTest]
This would remove integrationTest task from check task.
task forceTest {
dependsOn "cleanTest", "cleanIntegrationTest", "test", "integrationTest"
}
// Exclude integrationTest from 'check' task
check.dependsOn -= [integrationTest]