Is there a standard way to have Gradle add a jar to do annotations processing? Why isn't this built into Gradle as opposed to doing something hack-ish
Related
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+.
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.
I’m trying to create a custom Artifactory repository to resolve dependencies in my gradle project, but I’m confused between gradle and maven repo: what repository key should I choose? And what is the real difference between a gradle repository and a maven repository?
There is no such thing as a Gradle repository.
While Maven is the name for both a build tool and a repository type, Gradle ist just a build tool. It supports both Maven and Ivy repositories.
Gradle is a Java development tool, but not the only one. An alternative is Maven, which is older and commonly used. Spring Framework let developers to choose between these two tools.
Gradle is an open source build automation system that's built on Apache Maven and Apache Ant concepts. It uses a domain-specific language based on the programming language Groovy. This is a very interesting difference between Gradle and older Apache Maven, which uses XML. Gradle was developed in 2007 and in 2013 it was adopted by Google for Android system (this must say a lot about how powerful is Gradle).
Maven Repository is a directory where all the project jars, library jar and plugins can be used by Maven/Gradle easily. Maven Repository are of three types: local, central or remote. Gradle can and use the Maven Repositories, as I've said before, Gradle is build on top of Maven concepts.
You can think of Gradle as goodness of Ant and Maven put together minus the noise of XML. And scriptability with groovy is very big plus.
Gradle gives you conventions but still gives you power to override them easily.
Gradle build files are less verbose as they are written in groovy.
It provides very nice DSL for writing build tasks.
Has lot of good plugins and vibrant ecosystem
When to use Gradle and When to use Maven ?
Almost everywhere for creating java/groovy project. The build files are much terse.
With Google choosing Gradle as the new build system for Android SDK and mature libraries like Spring, Hibernate, Grails, Groovy etc. already using it to power their builds, there is no doubt that Gradle is becoming de-facto build system for the Java ecosystem.
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.
I need to distribute a Gradle plugin among several repositories and would like to package it as a jar, or at least a single artifact. I can write all of the functionality in straight Gradle and would prefer to over writing Groovy. Is it possible to package Gradle files together that can be used as a Gradle plugin via 'apply'?
Currently, build scripts can only be distributed via HTTP (apply from: "http://..."). However, a binary plugin (i.e. a class implementing the org.gradle.api.Plugin interface) can use almost the same syntax as a build script, and can be distributed as a Jar.