I was experimenting a little bit with Gradle but as mainly being a Maven user, some dependency scopes are confusing me …
Some are identical to Maven:
compile -> compile
runtime -> runtime
compileOnly -> provided
but I also encounter implementation which sounds like the parent element of Maven POM but then again also not.
Can somebody explain me what is implementation and some other if they exist and I didn’t mention here (test versions of above are clear no need to explain)?
And if implementation is not like parent on Maven, how can we have the parent POM effect of Maven in Gradle?
As commented, please have a look at the documentation or even at this recent webcast (disclaimer: I am co-presenting that webcast)
As for the Maven comparison, view migrating / learning from Maven to Gradle the same as moving from subversion to git: while some vocabulary is the same, understanding the model of the later helps more than comparing.
In short:
Do not use compile or runtime in Gradle, they are deprecated.
implementation relates to dependencies that are required to compile and run your application.
compileOnly and runtimeOnly should be self-explanatory in the context of the above
The java-library plugin adds the api configuration which is reserved for dependencies that consumers of your library will need to compile.
There is no direct equivalent to a Maven parent pom. Whether you are talking about plugins, build config or dependencies, the way to centralize are different. Have a look at the documentation on multi-project authoring.
Related
I have a Spring Boot Project with this two Dependencies.
id 'org.springframework.boot' version '2.7.2'
....
implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
implementation 'com.google.code.gson:gson:2.8.8'
My problem here is that Eureka client brings gson dependency 2.9 into the project. So at least the version 2.8.8 specification is useless here.
I want to keep the gradle file clean. Is there an easy way to find dependency overlaps like this?
I have exactly the same situation in my Maven project. A solution for Maven would be nice too.
run:
gradle dependencies
You will get a tree showing where all of the dependencies come from and which have been overruled by later versions.
See the documentation at https://docs.gradle.org/current/userguide/viewing_debugging_dependencies.html
The solution I would use for Maven is to convert it to a Gradle project to make my life easier for this and everything else to come.
I've created new Kotlin project under Gradle. By default it sets this dependencies to the Kotlin-library project. And I wonder what does this kotlin-bom lib do ?
dependencies {
// Align versions of all Kotlin components
implementation(platform("org.jetbrains.kotlin:kotlin-bom"))
// Use the Kotlin JDK 8 standard library.
implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
// Use the Kotlin test library.
testImplementation("org.jetbrains.kotlin:kotlin-test")
// Use the Kotlin JUnit integration.
testImplementation("org.jetbrains.kotlin:kotlin-test-junit")
}
The kotlin-bom artifact is a dependency-only POM that aligns all the Kotlin SDK libraries with the same version.
See the POM content for version 1.5.31 for an example. It uses the POM's dependencyManagement section to depend on the same version of all the Kotlin SDK artifacts, like kotlin-stdlib, kotlin-stdlib-jdk8, kotlin-reflect, kotlin-test, etc.
Description of a BOM:
Software bill of materials (BOMs) don’t specify a dependency on a
module or file, but instead are a list of version constraints for
other components. They define what is called a platform, which is
basically a list of components with specific versions that are known
to play well together and/or form a useful unit of functionality. It’s
worth mentioning that not all of the dependencies listed in the BOM
actually have to be included in your projects — it’s basically a way
of saying “If you use any of these modules, use this version”.
-- A deep dive into an initial Kotlin build.gradle.kts
Is there a simple way to list the differences between the artefacts added to the classpath by one version of a Maven project and another?
Here is the problem I'm trying to solve. If I change the version of an artefact declared in a Maven project, the list of transitive dependencies added to the classpath by the dependency may change. I want know what those changes are before I commit a change to a dependency version. The primary reason I want to know what transitive dependencies will change on the classpath when I change the version number of declared dependency is concern that changing the version number of a declared dependency may cause the version of a transitive dependency to change to one that has a security vulnerability in it.
At the moment, I'm using the dependencies plugin tree goal to produce a before and after change dependency tree and then comparing the two by eye. This is not ideal.
I also know of a way to achieve my goal using the OWASP dependency check Maven plugin but this also seem not ideal.
Can anyone suggest a better solution to my problem that using the dependencies plugin or the OWASP dependency check plugin? Is there a Maven plugin to produce what I need?
Thanks
Please try
mvn dependency:list
It will list all the dependencies with version information.
now you can see the difference using any diff checker tool online.
When using some 3rd party libraries, I add a dependency to my module's build.gradle file.
compile 'com.android.support:appcompat-v7:24.1.1'
Or I add a plugin
apply plugin: 'com.neenbedankt.android-apt'
Some other times, the library requires adding a dependency to my app's build.gradle file.
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
What is the difference between these dependencies and plugins?
Why can't they all be set in a single build.gradle file?
All suggestions are appreciated, I'm having trouble searching for info on this
Three things. Gradle plugin, module dependency, a build dependency which is placed on the classpath of the build tool.
A plugin is how Gradle knows what tasks to use. There are many plugins. For more info, see Gradle - Plugin Documentation
A dependency is a library that is compiled with your code. The following line makes your module depend on the Android AppCompat V7 library. For the most part, you search Maven or Jcenter for these.
compile 'com.android.support:appcompat-v7:24.1.1'
The classpath setting is needed for Gradle, not your app. For example, this allows this includes the Gradle Build Tools for Android into the classpath, and allows Gradle to build apps.
classpath 'com.android.tools.build:gradle:2.1.2'
Why can't they all be in one build.gradle file?
They probably can be. It is simply more modular to not.
I got this answer from a colleague, and this helped me understand. "A gradle plugin is like the tools you use to build the app. The dependencies are the libraries included in the app. A gradle plugin is usually the tasks - like ktlint, etc."
I didn't understand this myself so here is what i found. My answer is based on gradle build tool.
Plugins:
Add additional tasks, repositories, new DSL elements, configuration for classpaths/build/run or dependency management for subsequent development. Plugins are developed for a larger scope of development like java, kotlin or spring-boot.
Dependencies:
modules/libraries for tasks like http, serialization or database are dependencies stored remotely at repositories or locally that are needed at runTime, test or build are resolved by gradle in a configured fashion.
Sources:
Spring boot gradle plugin: https://github.com/spring-projects/spring-boot/tree/master/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin
Gradle documentation on plugins/dependencies: https://docs.gradle.org/current/userguide/plugins.html
https://docs.gradle.org/current/userguide/core_dependency_management.html
Remote repositories:
https://mvnrepository.com/
In simple words:
Plugins are used to add some additonal features to the software/tools(like Gradle). Gradle will use the added plugins at the time of building the App.
Dependecies are used to add some addtional code to your source code, so a dependency will make some extra code (like Classes in Java) in the form of library available for your source code.
Single question:
In gradle, there are several configurations provided out of the box.
For example testCompile, testProvided, testRuntime, javaCompile, javaProvided, and so on...
Could you explain what's the difference?
Configurations allow you to scope dependencies. Given this configuration hierarchy:
testRuntime -> testCompile -> runtime -> compile
Each configuration helps you limit where your dependencies are. *Runtime configurations allow you to include a dependency, but not have it as a compile dependency. This is helpful when you want to keep a framework loosely coupled from a project. A runtime dependency means that you need it for the app to run, but don't need it to compile.
The same thing applies for the test* configurations.
Ref:
Gradle Docs - Dependency configurations
In addition to Ethan's answer: the provided configurations contain dependencies that are used during compile but are not packaged to the final artifact. This is for example useful when you develop for a container that provides these dependencies already in its installation.