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 conceptoctylFractal
12/18/2018, 7:32 PM() -> Unit
is a Kotlin lambda that takes & returns nothing, and it can't be converted to Closure
implicitlyoctylFractal
12/18/2018, 7:33 PMdelegateClosureOf
or closureOf
to do it explicitlyoctylFractal
12/18/2018, 7:33 PMKotlinClosure1
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
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 PMRobert
12/18/2018, 8:14 PMRobert
12/18/2018, 8:15 PMBorzdeG
12/18/2018, 8:37 PMkotlin-multiplatform
-example sketched in a quick wayRobert
12/18/2018, 8:51 PMRobert
12/18/2018, 9:40 PMRobert
12/18/2018, 9:40 PMRobert
12/18/2018, 10:30 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 AMgildor
12/19/2018, 12:58 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.buildgildor
12/19/2018, 2:33 AMtasks.assemble {
dependsOn(tasks.named("generateProto"))
}
tasks.test {
dependsOn(tasks.named("generateTestProto"))
}
gildor
12/19/2018, 2:39 AMgildor
12/19/2018, 3:20 AMidea
plugingildor
12/19/2018, 3:22 AMBorzdeG
12/19/2018, 5:18 AMBorzdeG
12/19/2018, 5:20 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
gildor
12/19/2018, 5:22 AMgildor
12/19/2018, 5:23 AMplugins
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
gildor
12/19/2018, 5:25 AMFor 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 manuallygildor
12/19/2018, 5:29 AMplugins {
kotlin("platform-jvm")
}
dependencies {
expectedBy(project(":samples:sample-common"))
}
gildor
12/19/2018, 5:31 AMBorzdeG
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 AMgildor
12/19/2018, 5:33 AMgildor
12/19/2018, 5:33 AMgildor
12/19/2018, 5:34 AMgildor
12/19/2018, 5:36 AMgildor
12/19/2018, 5:38 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 thinggildor
12/19/2018, 5:52 AMgildor
12/19/2018, 5:53 AMIf 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
gildor
12/19/2018, 5:54 AMAlthough 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 AMBorzdeG
12/19/2018, 6:07 AMBorzdeG
12/19/2018, 6:09 AMBorzdeG
12/19/2018, 6:11 AMgildor
12/19/2018, 6:14 AMcompile
because you donât use plugins blockgildor
12/19/2018, 6:15 AMMoreover, an example that in the screenshot, works great in the Groovy DSLYes because in groovy itâs completely dynamic and checked only on runtime
gildor
12/19/2018, 6:16 AMgildor
12/19/2018, 6:17 AMBorzdeG
12/19/2018, 6:17 AMgildor
12/19/2018, 6:18 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.
gildor
12/19/2018, 6:20 AMgildor
12/19/2018, 6:21 AMgildor
12/19/2018, 6:21 AMgildor
12/19/2018, 6:22 AMgildor
12/19/2018, 6:22 AMgildor
12/19/2018, 6:23 AMBorzdeG
12/19/2018, 6:27 AMgildor
12/19/2018, 6:29 AMgildor
12/19/2018, 6:30 AMBorzdeG
12/19/2018, 6:30 AMgildor
12/19/2018, 6:31 AMgildor
12/19/2018, 6:32 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 AMBorzdeG
12/19/2018, 6:33 AMgildor
12/19/2018, 6:34 AMgildor
12/19/2018, 6:34 AMgildor
12/19/2018, 6:34 AMgildor
12/19/2018, 6:35 AMBorzdeG
12/19/2018, 6:35 AMgildor
12/19/2018, 6:36 AMgildor
12/19/2018, 6:37 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 AMgildor
12/19/2018, 7:39 AMgildor
12/19/2018, 8:53 AMgildor
12/19/2018, 8:53 AMBorzdeG
12/19/2018, 12:54 PM