https://kotlinlang.org logo
Title
n

napperley

11/15/2020, 11:51 PM
Is it possible to apply the maven-publish plugin in a custom build file? Seems as though there are no errors when applying the plugin, however the functionality that the plugin provides (eg publishing block) isn't being made available.
g

gildor

11/15/2020, 11:52 PM
What is custom build file?
n

napperley

11/16/2020, 12:00 AM
The custom build file is named publish-bintray.gradle.kts, and it is located in the gradle directory in the root project.
m

mazorius

11/16/2020, 12:14 AM
I think the better way for this is using
buildSrc
or
includeBuild
☝️ 1
I did not really do a lot with this but in Gradle community that is more less the way 🙂 Maybe you should ask this question inside gradle-community.slack.com ?
n

napperley

11/16/2020, 12:30 AM
Due to the way the project is structured that isn't possible: https://github.com/napperley/kotlinx.atomicfu/tree/linux-arm32-support
Does the maven-publish plugin only work properly in *build.gradle*/*build.gradle.kts* files?
v

Vampire

11/16/2020, 1:18 AM
It works perfectly fine also in script plugins. The problem your are having is, that you don't have type-safe accessors like for the publishing block in Kotlin DSL script plugins. If you want type-safe accessors, you have to use a precompiled script plugin in buildSrc or an included build. If you don't want to use a precompiled script plugin for whatever reason (there shouldn't really be any), you have two choices left. Either use Groovy DSL, or use the verbose syntax in the Kotlin DSL.
n

napperley

11/16/2020, 2:02 AM
Not trying to develop a Gradle plugin.
v

Vampire

11/16/2020, 2:03 AM
Yes you do, you just don't know. ;-)
☝️ 2
What you try to use is called script plugin
n

napperley

11/16/2020, 2:04 AM
Tried the same thing with Groovy DSL and run into the same problem.
v

Vampire

11/16/2020, 2:04 AM
If you move it to buildSrc or an included build, it becomes a precompiled script plugin and there the typesafe accessors are available
Hm, I thought with Groovy it should work, but it is long ago that I used the Groovy DSL
n

napperley

11/16/2020, 2:08 AM
Moving the publishing logic into buildSrc won't work since an evaluation occurs afterwords for publishing ( https://github.com/napperley/kotlinx.atomicfu/blob/linux-arm32-support/atomicfu/build.gradle#L298 ).
v

Vampire

11/16/2020, 2:10 AM
Besides that you should avoid
afterEvaluate
wherever you can, why should that hinder you from moving logic to
buildSrc
or an included build?
n

napperley

11/16/2020, 2:13 AM
It is the legacy part of the AtomicFu library ( https://github.com/Kotlin/kotlinx.atomicfu ). For some strange reason the Kotlin Native libraries are published differently from the Kotlin JVM/JS libraries.
v

Vampire

11/16/2020, 2:15 AM
That doesn't answer my question, does it?
n

napperley

11/16/2020, 2:25 AM
Moving the publishing logic to buildSrc causes the following error to occur:
Could not get unknown property 'publishing' for project ':atomicfu' of type org.gradle.api.Project.
v

Vampire

11/16/2020, 2:27 AM
Well, without you build scripts this is guesswork, but you probably did not apply the plugin.
g

gildor

11/16/2020, 3:00 AM
The 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 DSL
It 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
n

napperley

11/16/2020, 3:06 AM
The maven-publish plugin is applied. Encountering an issue where the publishing block is accessible with the build.gradle.kts file in buildSrc, but the block isn't accessible with the build.gradle file in the atomicfu module.
g

gildor

11/16/2020, 3:15 AM
publishing block is accessible with the build.gradle.kts file in buildSrc
You 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
what you need is precompiled script plugin, please check docs which I sent above
n

napperley

11/16/2020, 4:23 AM
g

gildor

11/16/2020, 5:14 AM
documentation is broken? what do you mean?
m

mazorius

11/16/2020, 8:53 AM
If you apply a plugin inside the root project, but not inside the sub-project you have no access inside the sub-project. The `plugin`DSL only applies in the specific project, as well as the old way with
apply 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
The page looks good to me, and also helps me while creating my first Gradle plugin. what do you miss @napperley?
n

napperley

11/16/2020, 11:46 PM
@mazorius - You are correct on the Gradle documentation being accurate. Tried the custom compiled Gradle plugin stuff in a new Gradle project (using Kotlin DSL), and found it works as expected (incl IntelliJ recognising buildSrc). There is something strange going on with the AtomicFu's use of Gradle, which is unconventional that seems to cause buildSrc to not be recognised by IntelliJ/Gradle. This might explain why the custom Gradle plugin isn't being registered automatically, and hence the plugin cannot be applied outside of buildSrc.
🙌 1
At this stage it will be up to the Kotlin libraries team (@elizarov) to resolve the major build issues with the AtomicFu library ( https://github.com/Kotlin/kotlinx.atomicfu ). I have gone as far as I can to resolve the build issues.
g

gildor

11/16/2020, 11:55 PM
Custom plugin isn't being registered automatically? What do you mean? Maybe you could share your current code
n

napperley

11/17/2020, 12:00 AM
g

gildor

11/17/2020, 12:01 AM
And how to reproduce? Try to publish?
n

napperley

11/17/2020, 12:02 AM
Doing a Gradle refresh will be sufficient to reproduce the issue.
v

Vampire

11/17/2020, 11:34 AM
Didn't you say you are using Kotling DSL? I would really recommend it. It is a bit slower for initial compilation, but it is way nicer to work with and you get type-safety and amazing IDE support (at least if you use IntelliJ). Your problem (besides that you use long deprecated things in your build like the gradle metadata preview switch, or the
maven
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.
n

napperley

11/18/2020, 1:18 AM
Finally managed to get buildSrc recognised although it is very frustrating having to provide a valid build file, and do a Gradle refresh (which produces no errors) before syntax checking is applied by IntelliJ.
End up with this confusing error message after running the publishNativePublicationToMavenRepository Gradle task:
Execution 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.
v

Vampire

11/18/2020, 2:40 AM
As far as I remember, bintray does not support snapshot versions, but instead for snapshot versions OJO should be used.
n

napperley

11/18/2020, 4:18 AM
What is OJO?
The library is published however it looks as though some files are missing for the Kotlin Native targets.
I have added the linuxArm32Hfp target, and republished the library without any errors (additional files were published compared to last time). In a sample project the linuxX64 target works however the linuxArm32Hfp target fails with the following errors:
Execution 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'
v

Vampire

11/18/2020, 8:02 AM
OJO is short for oss.jfrog.org
👍 1