I'm writing a plugin to extract some boilerplate from a selection of existing Gradle build scripts. The existing build scripts are primarily written in Groovy and compiling Java.
To build my plugin I'm using the Gradle Kotlin DSL and figured I'd take the opportunity to write the plugin in Kotlin too. This all works but now my plugin has a huge dependency on Kotlin - and the Gradle docs specifically recommend minimizing external libraries.
Java and Groovy plugins avoid this because Java & Groovy are a shared dependency with Gradle, but Kotlin isn't a shared pre-requirement and so we then have to be concerned about potentially conflicting Kotlin versions needed by different plugins.
I figure I should move forward with one of the following approaches but am not clear which:
Just list Kotlin's stdlib as a standard dependency and trust Gradle to sort things out.
This works for one plugin, but should I expect problems when another plugin is also being used but depending on a different Kotlin?
Build some sort of uber shadowJar shadowing Kotlin libraries for my plugin
Implying that every plugin I write like this will be 10s of MB bigger than necessary.
Give up on Kotlin based plugins and rewrite in Java/Groovy
Would be a shame to give up on the new goodness but might be better to avoid the above sins.
Recommendations welcome!
Since your plugin is replacing boilerplate and is presumably not destined for public release, would it make sense to write it as a script plugin in the Gradle Kotlin DSL? That way a new enough Gradle should be able to understand it natively.
Raised this in Gradle Community Slack and was recommended to use Gradle's kotlin-dsl plugin to automatically configure dependencies on gradleApi() and embeddedKotlin() versions, and therefore whatever Kotlin version is bundled with Gradle's Kotlin DSL support.
I was concerned that this might introduce a dependency on the calling script using Kotlin DSL, but I've tested with a Groovy script and have been able to use my plugin. I assume that it does still depend on a version of Gradle with Kotlin DSL support though - i.e. 4.0+.
Related
I am new to gradle composite builds. I have a multi-project build that uses precompiled script plugins in order to have tasks configured for all projects that include the plugin. Now I want to port that functionality to a composite build setup.
The screenshots below show how the current multi-project build works:
This java precompiled script plugin (/buildSrc/.../java-conventions.gradle.kts) configures the "JavaCompile" tasks (i.e. sourceCompatability, targetCompatability...).
This kotlin precompiled script plugin imports the java conventions plugin and configures the "KotlinCompile" tasks.
Applying the the kotlin conventions plugin to project "test" automagically sets up my project with the proper "JavaCompile" and "KotlinCompile" configuration as shown above.
I have read the official docs and tutorials on gradle composite builds. Still, I dont know the proper way how to do this with composite builds. Do I have to write standalone plugins for this? If so, can you provide a POC code snippet? Any advice is greatly appreciated!
Is it possible to have a kotlin multiplateform project in maven?
I found only plugin for the kotlin multiplatform in gradle .
I need to build an librairy both in js, kotlin and java
To my knowledge, current multiplatform model is highly tied to Gradle and is benefiting from it's unique features like Gradle Metadata.
Still, you can file an issue on that at https://kotl.in/issue, it may sound reasonable to additionally support Maven when Multiplatform is stabilized with Gradle.
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.
I'm switching a large project from Maven to Gradle. Existing Maven project uses com.googlecode.maven-java-formatter-plugin to format the Java code. Looked for the equivalent in Gradle. Found https://plugins.gradle.org/plugin/com.github.sherter.google-java-format, but it spewed a bunch of errors out, was really slow, and didn't generate the same output as the Maven plugin.
Also looked here: https://github.com/google/google-java-format - no help.
Is there a Gradle plugin which will give me same result as the Maven plugin?
There is this other Gradle plugin, which uses the Eclipse formatter. Maybe you can tweak it to achieve the same results as with the maven plugin you mentioned (I'm not using this plugin myself).
Note that it is an explicit non-goal of google-java-format and the corresponding Gradle plugin to be configurable. If you are not happy with the formatting style then this tool is probably not appropriate for you.
(if you have technical problems with my Gradle plugin, feel free to provide more details or open a ticket on Github)
After switching to gradle 2.3 for wrapper I am noticing a lot more goals being added from application plugin and included as part of the build process. Its creating zip files, tar files, doing script related stuff for all subprojects. This is not the intended behavior. I would like to keep it the way it was before such that unless I explicitly specify the application plugin goals like distZip, they shouldnt be invoked as part of my gradle build.
This behaviour's caused by Spring Boot's Gradle plugin. I've opened an issue. I don't fully understand why the switching from Gradle 2.2 to 2.3 triggers a change in behaviour, but your best bet at the moment would appear to be to stick with Gradle 2.2.