napperley
11/15/2020, 11:51 PMgildor
11/15/2020, 11:52 PMnapperley
11/16/2020, 12:00 AMmazorius
11/16/2020, 12:14 AMbuildSrc
or includeBuild
napperley
11/16/2020, 12:30 AMVampire
11/16/2020, 1:18 AMnapperley
11/16/2020, 2:02 AMVampire
11/16/2020, 2:03 AMnapperley
11/16/2020, 2:04 AMVampire
11/16/2020, 2:04 AMnapperley
11/16/2020, 2:08 AMVampire
11/16/2020, 2:10 AMafterEvaluate
wherever you can, why should that hinder you from moving logic to buildSrc
or an included build?napperley
11/16/2020, 2:13 AMVampire
11/16/2020, 2:15 AMnapperley
11/16/2020, 2:25 AMCould not get unknown property 'publishing' for project ':atomicfu' of type org.gradle.api.Project.
Vampire
11/16/2020, 2:27 AMgildor
11/16/2020, 3:00 AMThe custom build file is named publish-bintray.gradle.kts, and it is located in the gradle directory in the root project.this approach is almost impossible to use with Kotlin DSL, you have no static accessors, the ONLY real way is use buildSrc and precompiled script plugins I would highly recommend you to read Kotlin DSL primer first
I thought with Groovy it should work, but it is long ago that I used the Groovy DSLIt indeed will work with Groovy
Does the maven-publish plugin only work properly in *build.gradle*/*build.gradle.kts* files?No, it’s just not how it work. maven-publish is just a plugin, as any other. What is really different is of course context where you apply it
napperley
11/16/2020, 3:06 AMgildor
11/16/2020, 3:15 AMpublishing block is accessible with the build.gradle.kts file in buildSrcYou probably missundertood how buildSrc works, buildSrc/build.gradle is now what you need! This file configures buildSrc itself, it doesn’t provide any configuration to other modules
napperley
11/16/2020, 4:23 AMgildor
11/16/2020, 5:14 AMmazorius
11/16/2020, 8:53 AMapply plugin
.
You need to apply the plugin to each project where you need it.
Of course you can do this in a custom script or buildSrc
and use project.allprojects.filter(…)
and than do apply plugin
inside.
But as all three of us mentioned, the better and cleaner way to extract build logic is using either buildSrc
or a include build
napperley
11/16/2020, 11:46 PMgildor
11/16/2020, 11:55 PMnapperley
11/17/2020, 12:00 AMgildor
11/17/2020, 12:01 AMnapperley
11/17/2020, 12:02 AMVampire
11/17/2020, 11:34 AMmaven
plugin, or that you use the -all
Gradle distribution which is just a waste of time to download and waste of diskspace for 98% of the users) is,
that the error message is a bit unlucky.
The contents of your publishing
block are invalid and due to that it doesn't find the right publishing
method to call, because the given closure is not ok.
You use bintraySettings
but it is nowhere defined, you probably wanted settings
or rename the variable to bintraySettings
.
And additionally you try to call a non-existing method getBintraySettings()
.
If those two problems are fixed, the sync works without any problem.napperley
11/18/2020, 1:18 AMExecution failed for task ':atomicfu:publishNativePublicationToMavenRepository'.
> Failed to publish publication 'native' to repository 'maven'
> Could not PUT '<https://api.bintray.com/maven/napperley/development/kotlinx.atomicfu/;publish=0/org/jetbrains/kotlinx/atomicfu-native/0.14.4-SNAPSHOT/maven-metadata.xml>'. Received status code 400 from server: Bad Request
As one can see the repo specified in the URL is development yet maven is used as the repo.Vampire
11/18/2020, 2:40 AMnapperley
11/18/2020, 4:18 AMExecution failed for task ':compileKotlinLinuxArm32'.
> Could not resolve all files for configuration ':linuxArm32CompileKlibraries'.
> Could not resolve org.jetbrains.kotlinx:atomicfu-native:0.14.4-dev.
Required by:
project :
> No matching variant of org.jetbrains.kotlinx:atomicfu-native:0.14.4-dev was found. The consumer was configured to find a usage of 'kotlin-api' of a component, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native', attribute 'org.jetbrains.kotlin.native.target' with value 'linux_arm32_hfp' but:
- Variant 'metadata-api' capability org.jetbrains.kotlinx:atomicfu-native:0.14.4-dev:
- Incompatible because this component declares a usage of 'kotlin-metadata' of a component, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'common' and the consumer needed a usage of 'kotlin-api' of a component, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native'
- Other compatible attribute:
- Doesn't say anything about org.jetbrains.kotlin.native.target (required 'linux_arm32_hfp')
- Variant 'metadata-commonMainMetadataElements' capability org.jetbrains.kotlinx:atomicfu-native:0.14.4-dev declares a usage of 'kotlin-api' of a component:
- Incompatible because this component declares a component, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'common' and the consumer needed a component, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native'
- Other compatible attribute:
- Doesn't say anything about org.jetbrains.kotlin.native.target (required 'linux_arm32_hfp')
- Variant 'native-api' capability org.jetbrains.kotlinx:atomicfu-native:0.14.4-dev declares a usage of 'kotlin-api' of a component, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
- Incompatible because this component declares a component, as well as attribute 'org.jetbrains.kotlin.native.target' with value 'linux_x64' and the consumer needed a component, as well as attribute 'org.jetbrains.kotlin.native.target' with value 'linux_arm32_hfp'
Vampire
11/18/2020, 8:02 AM