Robert
12/18/2018, 7:30 PMprotoc {
^ Type mismatch: inferred type is () -> Unit but Closure<(raw) Any!>! was expected`
Raw? Any? protoc looks like this:
public void protoc(Closure configureClosure) {
octylFractal
12/18/2018, 7:32 PMClosure
is a groovy concept() -> Unit
is a Kotlin lambda that takes & returns nothing, and it can't be converted to Closure
implicitlydelegateClosureOf
or closureOf
to do it explicitlyKotlinClosure1
which is a little more complicatedRobert
12/18/2018, 7:35 PMBorzdeG
12/18/2018, 7:37 PMimport com.google.protobuf.gradle.GenerateProtoTask
import com.google.protobuf.gradle.ProtobufConvention
import com.google.protobuf.gradle.ProtobufPlugin
import com.google.protobuf.gradle.id
import com.google.protobuf.gradle.plugins
import com.google.protobuf.gradle.proto
import com.google.protobuf.gradle.protobuf
import com.google.protobuf.gradle.protoc
buildscript {
dependencies {
classpath("com.google.protobuf:protobuf-gradle-plugin:+")
}
}
apply {
plugin<JavaPlugin>()
plugin<ProtobufPlugin>()
}
dependencies {
"compile"("com.google.protobuf:protobuf-java")
"compile"("io.grpc:grpc-stub")
"compile"("io.grpc:grpc-protobuf")
if (JavaVersion.current().isJava9Compatible) {
"implementation"("javax.annotation:javax.annotation-api:+")
}
}
configure<ProtobufConvention> {
protobuf {
protoc {
artifact = "com.google.protobuf:protoc"
}
}
}
configure<JavaPluginConvention> {
sourceSets {
this["main"].java.srcDir(the<ProtobufConvention>().protobuf.generatedFilesBaseDir + "/main/java")
}
}
tasks["build"].dependsOn(tasks.withType(GenerateProtoTask::class))
Robert
12/18/2018, 7:48 PMthe<ProtobufConvention>().protobuf.generatedFilesBaseDir + "/main/java"
BorzdeG
12/18/2018, 7:56 PM$PROJECT_DIR$/build/generated/source/proto/main/java
Robert
12/18/2018, 7:56 PM> Task :compileJava FAILED
/home/robert/testproto/build/generated/source/proto/main/java/sample/TestOuterClass.java:9: error: package com.google.protobuf does not exist
com.google.protobuf.ExtensionRegistryLite registry) {
Do i have to install it on my computer or something?BorzdeG
12/18/2018, 8:00 PMconfigurations.all {
resolutionStrategy {
failOnVersionConflict()
eachDependency {
when (requested.group) {
"com.google.protobuf" -> useVersion("3.6.1")
"io.grpc" -> useVersion("1.17.0")}}}}
Robert
12/18/2018, 8:07 PMBorzdeG
12/18/2018, 8:37 PMkotlin-multiplatform
-example sketched in a quick wayRobert
12/18/2018, 8:51 PMkotlin-gradle-plugin
right? Any clue? Or shouldn't I be looking in build/generated/source/proto/main/java
?BorzdeG
12/18/2018, 10:33 PMRobert
12/18/2018, 10:49 PMgildor
12/19/2018, 12:47 AMplugins{}
you will get much more help from Gradle, including generated type safe accessors for things like proc
extension, java convention and even to task.buildtasks.assemble {
dependsOn(tasks.named("generateProto"))
}
tasks.test {
dependsOn(tasks.named("generateTestProto"))
}
idea
pluginBorzdeG
12/19/2018, 5:18 AMgildor
12/19/2018, 5:21 AMPlug-ins can be applied “as needed”, i.e. depending on conditionsYou also can do this with plugins block
plugins
instead and I believe eventually buildscript will be used only for non-plugin dependenciesBorzdeG
12/19/2018, 5:23 AMgildor
12/19/2018, 5:24 AMOr the version of the plugin always coincides with the version of dependencies from the same package - I don’t want to write the same version twiceNo need to do that, you can extract it to buildSrc or use some other way to share versions
For example, I do not want to follow the updates of a plugin, but I always want to use its latest version.If plugin works, why would you update it implicitly, it’s against reproducible builds and performance
but I always want to use its latest versionBut why? What is you real use case?
BorzdeG
12/19/2018, 5:25 AMgildor
12/19/2018, 5:27 AMBorzdeG
12/19/2018, 5:27 AMBut why? What is you real use case?The version file contains an explicit version of the plugin. But at the same time, there is a separate Job, which tests on the latest versions. Thus, it is operatively visible when the assembly fails with updates. This allows you to “look ahead” to CI and have less headaches when updating
gildor
12/19/2018, 5:27 AMtasks.withType(Wrapper::class.java).configureEach {}
-> tasks.withType<Wrapper> { }
or even tasks.wrapper {}
(which is not exactly the same, but in your case will be the same)
Also you usually don’t need this task, easier just update wrapper version using command line or manuallyplugins {
kotlin("platform-jvm")
}
dependencies {
expectedBy(project(":samples:sample-common"))
}
BorzdeG
12/19/2018, 5:32 AMkotlin("platform-jvm")But this is not a static compilation and "magic". When explicitly calling a class, it is always clear where it comes from and where to look at the sources and documentation. This allows you to view the code without IDEA - in some other IDE or in VIM
gildor
12/19/2018, 5:33 AMOr here is a small project that I don’t know how to implement without buildscriptI see what you mean, you have custom plugin in buildSrc, and it’s completely fine to use with
plugins
block and have type safe accessors for extensions and tasks.
You can check this example
https://github.com/gradle/kotlin-dsl/tree/master/samples/buildSrc-plugin
Also there are a few tasks that should simplify it even more, you already can use precompiled plugins API for simple cases which is not exactly the same, but allows to create simple plugins without registration, just putting them to plugin-name.gradle.kts files in buildSrcBorzdeG
12/19/2018, 5:48 AMyou have no IDE helpOn the contrary - it is much more, since I can "jump" in the IDE via Ctrl + Click into the description of a particular class. While IDEA does not allow me to do this with the "best practices". Although it may have already learned - it is necessary to check.
I really want to show you what it is.I proceed from the simple - if something cannot be used, then it should be prohibited at the language level. If the use of the buildscript section is prohibited, but you need to leave it only in Groovy DSL and not drag in Kotlin DSL Also, once, it was a problem to use plug-ins used in external * .kts files - the configuration was described not by one file, but was split into several semantic ones - testing.gradle.kts, application.gradle.kts, etc ... I'll see how things are with this now and maybe update the configuration.
gildor
12/19/2018, 5:49 AMe IDEA does not allow me to do this with the “best practices”It’s completely not true
BorzdeG
12/19/2018, 5:50 AMAlthough it may have already learned - it is necessary to check.
gildor
12/19/2018, 5:51 AMAlso, once, it was a problem to use plug-ins used in external * .kts files - the configuration was described not by one file, but was split into several semantic ones - testing.gradle.kts, application.gradle.kts, etc ...this is different story not about plugins/builscript, related to script plugins. It’s also not the best way to deal with configuration with Kotlin DSL, because script plugins has only dynamic API for now. If you really want to extract big parts of config, better to use buildSrc And I’m talking about precompiled plugins, not just a separate kts file applied using
apply(from=)
precompiled plugins is relatevely new thingIf the use of the buildscript section is prohibited, but you need to leave it only in Groovy DSL and not drag in Kotlin DSLIt’s of course not prohibited, there are some valid use cases even now, for example to add some dependency to buildscript, but usually better to use plugins and for plugins you don’t need buildscript
Although it may have already learnedit’s never was true. Maybe just some IDE problems with navigation, but all static accessors code is available and you can see what they actually do and see used classes
BorzdeG
12/19/2018, 6:07 AMgildor
12/19/2018, 6:14 AMcompile
because you don’t use plugins blockMoreover, an example that in the screenshot, works great in the Groovy DSLYes because in groovy it’s completely dynamic and checked only on runtime
BorzdeG
12/19/2018, 6:17 AMgildor
12/19/2018, 6:18 AMBorzdeG
12/19/2018, 6:19 AMgildor
12/19/2018, 6:20 AMBorzdeG
12/19/2018, 6:20 AMgildor
12/19/2018, 6:20 AMthen such an entry should be prohibitedI would happy, but it’s not so easy, requires much longer deprecation cycle.
BorzdeG
12/19/2018, 6:27 AMgildor
12/19/2018, 6:29 AMBorzdeG
12/19/2018, 6:30 AMgildor
12/19/2018, 6:31 AMthen there are examples for the Kotlin DSL and it is not written that it is impossible to write like that at allNot sure what you mean. Do you see some invalid snippet in docs?
BorzdeG
12/19/2018, 6:33 AMgildor
12/19/2018, 6:34 AMBorzdeG
12/19/2018, 6:35 AMgildor
12/19/2018, 6:36 AMBorzdeG
12/19/2018, 6:39 AMI'll see how things are with this now and maybe update the configuration.
gildor
12/19/2018, 6:42 AMBorzdeG
12/19/2018, 6:45 AMgildor
12/19/2018, 7:17 AMBorzdeG
12/19/2018, 12:54 PM