Can someone explain to me how depedencies listed in the "buildscript" in the build.gradle file are different than regular dependencies listed in the dependencies block { } ? and why they have to be listed with the syntax "implementation"? I've googled this and responses say the dependencies in the buildscript and used to "build the project" but I don't understand this? can anyone give a more clear picture and answer?
buildscript:
buildscript
{
repositories
{
maven {
url 'myMavenFeed'
credentials {
username "myUsername"
password myPassword
}
}
mavenCentral()
jcenter()
}
dependencies
{
classpath "com.microsoft.azure.sdk.iot:iot-device-client:1.14.1"
}
}
Dependencies block:
dependencies
{
compile group: 'com.microsoft.azure.sdk.iot', name: 'iot-device-client', version: '1.16.0'
}
Can someone explain to me how depedencies listed in the "buildscript" in the build.gradle file are different than regular dependencies listed in the dependencies block { } ?
Dependencies defined in the buildscript { } block are dependencies to use to build your project. These dependencies are available to use in your Gradle build file (build.gradle or build.gradle.kts)
Dependencies defined in the dependencies { } are for your application code.
So for your samples in your questions, does it make sense for Gradle (the build system) to have iot-device-client on its classpath? Why does a build system need iot-device-client on its classpath to build your project? It doesn't make sense therefore it should be removed.
Now let's say you are developing an application the requires some functionality or class from iot-device-client. You need a way to add this library to your application's code/classpath. You when then declare it as a dependency as you have done above:
dependencies {
implementation("com.microsoft.azure.sdk.iot:iot-device-client:1.16.0")
}
References:
External dependencies for the build script
Declaring depenedncies
and why they have to be listed with the syntax "implementation"?
implementation is known as a configuration: A Configuration represents a group of artifacts and their dependencies
There are many more configurations depending on the plugins you apply to your project. For example, if you apply the Java plugin:
plugins {
id("java")
}
The following configurations are available to use:
implementation
compileOnly
compileClasspath
...and many more
Each one has their own meaning/usage and I strongly suggest reading about them here.
Related
I'm quite new to Gradle, trying to make multi-project. In root project declares all common libs (also their versions as properties) and apply plugins.
For example, root and child common projects.
In root's settings.gradle type:
rootProject.name = 'root'
include 'common'
In root's build.gradle type:
buildscript {
ext.kotlin_version = '1.3.11'
repositories {
mavenCentral()
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
}
}
subprojects {
buildscript {
repositories {
mavenCentral()
}
}
apply plugin: 'kotlin'
repositories {
mavenCentral()
}
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
}
}
And now I'd like to use another library only in specific child project. Do this in common's build.gradle:
buildscript {
dependencies {
classpath "org.jetbrains.kotlin:kotlin-allopen:$kotlin_version"
}
}
It's work fine when running gradle commands from root's folder, but failed with message Could not get unknown property 'kotlin_version' for object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler when running from common's folder.
What I'm doing wrong? Or is there any way around? And what are best practices for sharing libs and properties in multi-project?
For me, it looks like common know nothing about it's "parent" project, all relations defined in root's settings.
The reason why Gradle cannot resolve the property is because the project in folder common is named commons. This is caused by a spelling mistake in common's settings.gradle. This is fortunately easy to fix (common/settings.gradle) :
rootProject.name = 'common'
Alternatively, just delete the common/settings.gradle, it's fully optional in this case.
Consider reading the official Gradle documentation for authoring multi-project builds and the guide create multi-project builds for more information and best practices around multi-project builds.
I have a Kotlin Gradle project.
If I create a .kts file it runs in InteliJ alright except when it is in the /src/main/kotlin folder.
IDEA highlights the whole file in red.
Gradle throws out compilation exception.
The exception is
...src/main/kotlin/test.kts: (3, 1): Cannot access script base class 'kotlin.script.templates.standard.ScriptTemplateWithArgs'. Check your module classpath for missing or conflicting dependencies`.
What is the problem?
My build.gradle:
plugins {
id 'org.jetbrains.kotlin.jvm' version '1.3.0-rc-131'
}
group 'kotlin.tutorials.coroutines'
version '1.0-SNAPSHOT'
repositories {
maven { url 'http://dl.bintray.com/kotlin/kotlin-eap' }
mavenCentral()
jcenter()
maven { url "https://dl.bintray.com/kotlin/ktor" }
}
ext.ktor_version = '1.0.0-alpha-1'
ext.coroutines_version = '0.30.2-eap13'
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
compile "io.ktor:ktor-server-netty:$ktor_version"
compile "ch.qos.logback:logback-classic:1.2.3"
//KTOR features
compile "io.ktor:ktor-jackson:$ktor_version"
compile "io.ktor:ktor-auth:$ktor_version"
compile "io.ktor:ktor-auth-jwt:$ktor_version"
compile "io.ktor:ktor-freemarker:$ktor_version"
compile "io.ktor:ktor-html-builder:$ktor_version"
}
compileKotlin.kotlinOptions.jvmTarget = "1.8"
compileTestKotlin.kotlinOptions.jvmTarget = "1.8"
.kts files should go to the src/main/resources folder since src/main/kotlin is for .kt files.
Scripts are a completely different animal in this sense, and you should use something like KtsRunner to execute them.
Related question is here.
If you just want to use scripts from IDEA, then you should use Scratch files which are supported out of the box.
The solution turned out to be very straight forward.
The compiler could not find utility classes that are usually added to any Kotlin script classpath. Adding one dependency to my build.gradle fixed it:
dependencies {
compile "org.jetbrains.kotlin:kotlin-scripting-jvm"
}
P.S.
I created 2 tickets to improve Kotlin script support in InteliJ:
https://youtrack.jetbrains.com/issue/KT-27542
https://youtrack.jetbrains.com/issue/KT-27544
If you care about those features, please vote them up!
We have a Gradle build that includes a buildSrc with some custom plugins. Those plugins apply yet other plugins. For example, our plugin applies com.android.tools.build:gradle. For annotation processing that library needs to be on Gradle's classpath during compilation. So, putting this in our main build.gradle works:
buildscript {
repositories {
google()
}
dependencies {
classpath "com.android.tools.build:gradle:$gToolsVersion"
}
}
However, that means that for a user to apply this plugin they must (1) apply our plugin and (2) add that buildscript boilerplate. It seems like that shouldn't be necessary. We can also add a project.buildscript block inside our plugin but that too seems unnecessary and, due to this bug is problematic: https://developer.android.com/studio/build/gradle-plugin-3-0-0.html?utm_source=android-studio#known_issues.
I added the com.android.tools.build:gradle dependency to buildSrc/build.gradle as a runtime dependency. It seems like that should work: I thought that tells Gradle that in order to run my plugin that library (and its dependencies) need to be on the classpath. However, gradle buildEnvironment (and the fact that our build fails) makes it clear that's not the case.
So, questions:
What's the difference between a runtime dependency specified in buildSrc/build.gradle and a classpath dependency specified in a buildscript block in a regular build.gradle?
How can I arrange things so that users can apply the plugin from buildSrc and not have to also add the buildscript block to their build.gradle?
I got a slightly different problem and found an acceptable solution that might help with for your second question: I wanted to apply the same repositories in the buildSrc/build.gradle and twice in the root build.gradle.
repositories.gradle in the project root:
repositories {
if (project.hasProperty('nexus')) {
maven {
url 'http://localhost:8081/repository/JCenter/'
}
maven {
url 'http://localhost:8081/repository/Maven_Google/'
}
} else {
jcenter()
google()
}
}
ext {
androidGradleBuildToolsDependency = 'com.android.tools.build:gradle:3.1.3'
}
buildSrc/build.gradle:
buildscript {
apply from: '../repositories.gradle'
}
allprojects {
apply from: '../repositories.gradle'
}
dependencies {
// androidGradleBuildToolsDependency is defined in repositories.gradle
implementation androidGradleBuildToolsDependency
}
Root build.gradle:
buildscript {
apply from: 'repositories.gradle'
}
allprojects {
// this line will also be executed from the build.gradles in subprojects, so the working
// directory isn't always the same, so we use the absolute path here
apply from: "${rootProject.projectDir}/repositories.gradle"
}
Note that you do not need the classpath dependency inside the buildscript block of the root build.gradle as you normally would. The implementation dependency in the repositories.gradle seems to auto apply it.
My solution probably doesn't work when the build.gradles are supplied via a dependency.
Stumbled upon this while digging into a tangential problem.
I've been successfully using buildSrc/build.gradle as the place to define dependencies that would normally belong in the root-project's buildscript classpath for a few of my projects.
You can see a working example here: https://github.com/episode6/chop/blob/develop/buildSrc/build.gradle
I used to use compile dependencie but just switched to runtimeClasspath which feels more appropriate and also works. I don't think your classpath dependencies were working because they would be on the classpath of the buildSrc project, but not compiled into or run along side it.
If you decide to go this route, you may run into the problem I was just digging into which only came up because of this approach.
When I tried this approach with the dokka plugin, I got the following error
Could not resolve all files for configuration ':detachedConfiguration1'.
> Cannot resolve external dependency org.jetbrains.dokka:dokka-fatjar:0.9.17 because no repositories are defined
I was able to workaround this by adding jcenter() to the root project's buildscript repositories: https://github.com/episode6/chop/blob/develop/build.gradle#L2
If a have a custom plugin which handles the building and deploying of a specific component, where do I list the dependencies (other components in my system) which are required for the build?
Dependencies for your Gradle plugins should be listed in the buildscript portion of the build.gradle file. See this chapter of the User Guide, which also has an example:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath "com.jfrog.bintray.gradle:gradle-bintray-plugin:0.4.1"
}
}
apply plugin: "com.jfrog.bintray"
If your custom plugin depends on jar files on your local machine, I gather that you need to add those files as a "flatDir" repository in the repositories entry, as described here:
repositories {
flatDir {
dirs 'lib1', 'lib2'
}
}
I'm going through Google's documentation on "Add Google Play Services to Your Project" in Android Studio:
https://developer.android.com/google/play-services/setup.html
I'm using that documentation to modify the build.gradle file of a freshly created Android project. In Step 2 (Add Google Play Services to Your Project), it states:
Add this line:
apply plugin: 'android'
Under Dependencies, add this:
compile 'com.google.android.gms:play-services:5.0.77'
It also says to update that version after updating Google Play Services, which is now at 18 according to Android SDK Manager.
Here is my entire build.gradle file at the top-level (parent of this file is the root folder).
// Top-level build file where you can add configuration options common to all sub-projects/modules.
apply plugin: 'android'
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.12.+'
compile 'com.google.android.gms:play-services:18'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
jcenter()
}
}
Upon saving, it prompts for a Sync. I Sync it, but get:
Build script error, unsupported Gradle DSL method found: 'compile()'!
Error:(10, 0) Possible causes could be:
- you are using a Gradle version where the method is absent
- you didn't apply Gradle plugin which provides the method
- or there is a mistake in a build script
I'm using Android Studio 0.8.2. I didn't install Gradle, just using the plugin that came with Android Studio.
It's interesting to note that the build.gradle file generated when I made this new project says:
//NOTE: Do not place your application dependencies here
But Google's documentation says (which conflicts with the above):
Note: Android Studio projects contain a top-level build.gradle file and a build.gradle
file for each module. Be sure to edit the file for your application module.
What's wrong with my build.gradle file (or environment)?
The Google documentation you quoted is correct, and doesn't conflict. There's more than one build.gradle file. Instead of putting dependencies in the top-level one as you have, put them in the build file that's in your module's directory.
Also, don't put an apply plugin: 'android' statement in that top-level build file; it will cause an error.
You can also add dependencies through the Project Structure UI, which does the right thing.
Do not add dependencies in your project by editing its most 'external' build.gradle (YourProject/build.gradle). Edit the one that is under the 'app' module instead (YourProject/app/build.gradle).
There, by the way, you will find the declaration of one dependency, such as:
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
}
This block will be just below android { ... } configuration block.
In my case, I am just adding leeloo dependencies, so it became:
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'net.smartam.leeloo:oauth2-client:0.1'
compile 'net.smartam.leeloo:oauth2-common:0.1'
}
Then sync your project and dependencies will be downloaded. Hope it helps!
the compile-time dependencies should reside in the dependencies block under allprojects, not under buildscript:
apply plugin: 'android'
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.12.+'
}
}
allprojects {
repositories {
jcenter()
}
dependencies {
compile 'com.google.android.gms:play-services:18'
}
}
This should work fine.
Think of “Gradle DSL method” as a Java method. So in Gradle, methods can be distinguished by either {} or “.”. So
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
}
is the same as
dependencies.compile fileTree(dir: 'libs', include: ['*.jar'])
where both “dependencies” and “compile” are methods.
So you are including a method somewhere in your build.gradle file that is not supported by your program. For example, make your dependencies this:
dependencies {
nothing 'this.does.nothing.build:gradle:0.7.+'
}
Which is the same as writing:
dependencies.nothing 'this.does.nothing.build:gradle:0.7.+'
And you will see an error saying “unsupported Gradle DSL method found: ‘nothing()’!”
Obviously "nothing" is not a real method. I just made it up.
So one of your "compile" methods inside your build.gradle is wrong.
When I faced this problem I used android developer UI to import dependencies as follows:-
1 Go to View ---> Open Module Settings
Select Dependency tab. Click + to add a dependency and select Library dependency. Choose the downloaded library here.