Thomas Keller

An alternative to a whacky Kotlin implementation could be that one isolates the functionality of the SSH plugin into a separate custom task, written in Groovy, and then register /...

> I just came across https://github.com/steklopod/gradle-ssh-plugin [This references this plugin](https://github.com/steklopod/gradle-ssh-plugin/blob/master/build.gradle.kts#L43), so no, it's not an alternative.

On a related note - generated assets should be separated by build variant under Android, so that ``` build/reports/licenses/firstVariant build/reports/licenses/secondVariant ... ``` are all separated from each other and each...

It should be noted that - while the Android implementation in #2787 is usable (we have it activated since a couple of weeks), it spits out tons of warnings on...

Regarding the "mixed state" rules - would it be feasible to split these up, having a non-TR-enabled and a TR-enabled version and marking the non-TR-enabled version deprecated? Of course, the...

This is unrelated to Jacoco, this is the minimal reproduction case I could come up with: * build.gradle ```groovy buildscript { repositories { mavenCentral() } dependencies { classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.72" }...

You eventually might to look into Kotlin, which is code-wise more nearby to Groovy than Java is. I've written a couple of Gradle plugins with Kotlin already and it works...

@adamdubiel Any feedback on this here?

@bgalek I think its not so uncommon with today's standard to have a multi-stage isolated pipeline, all cloud build providers isolate a certain stage from the next and unless you...

> I think interface extraction of VersionConfig would be ok How would this look like exactly for you? `VersionConfig` is just a data holder / configurator for the plugin.