Is it possible to apply the maven-publish plugin i...

# gradle

[napperley]

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.

[gildor]

What is custom build file?

[napperley]

The custom build file is named publish-bintray.gradle.kts, and it is located in the gradle directory in the root project.

[mazorius]

I think the better way for this is using buildSrc or includeBuild

[mazorius]

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 ?

[napperley]

Due to the way the project is structured that isn't possible: https://github.com/napperley/kotlinx.atomicfu/tree/linux-arm32-support

[napperley]

Does the maven-publish plugin only work properly in *build.gradle*/*build.gradle.kts* files?

[Vampire]

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.

[napperley]

Not trying to develop a Gradle plugin.

[Vampire]

Yes you do, you just don't know. ;-)

[Vampire]

What you try to use is called script plugin

[napperley]

Tried the same thing with Groovy DSL and run into the same problem.

[Vampire]

If you move it to buildSrc or an included build, it becomes a precompiled script plugin and there the typesafe accessors are available

[Vampire]

Hm, I thought with Groovy it should work, but it is long ago that I used the Groovy DSL

[napperley]

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 ).

[Vampire]

Besides that you should avoid afterEvaluate wherever you can, why should that hinder you from moving logic to buildSrc or an included build?

[napperley]

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.

[Vampire]

That doesn't answer my question, does it?

[napperley]

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.

[Vampire]

Well, without you build scripts this is guesswork, but you probably did not apply the plugin.

[gildor]

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

[gildor]

I thought with Groovy it should work, but it is long ago that I used the Groovy DSL

It indeed will work with Groovy

[gildor]

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]

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.

[gildor]

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

[gildor]

what you need is precompiled script plugin, please check docs which I sent above

[napperley]

Tried that however the documentation is broken: https://docs.gradle.org/current/userguide/custom_plugins.html#sec:precompiled_plugins

[gildor]

documentation is broken? what do you mean?

[mazorius]

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

[mazorius]

The page looks good to me, and also helps me while creating my first Gradle plugin.

what do you miss @napperley?

[napperley]

@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.

[napperley]

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.

[gildor]

Custom plugin isn't being registered automatically? What do you mean?

Maybe you could share your current code

[napperley]

Here is the link to the library fork: https://github.com/napperley/kotlinx.atomicfu/tree/linux-arm32-support

[gildor]

And how to reproduce? Try to publish?

[napperley]

Doing a Gradle refresh will be sufficient to reproduce the issue.

[Vampire]

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.

[napperley]

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.

[napperley]

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.

[Vampire]

As far as I remember, bintray does not support snapshot versions, but instead for snapshot versions OJO should be used.

[napperley]

What is OJO?

[napperley]

The library is published however it looks as though some files are missing for the Kotlin Native targets.

[napperley]

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'

[Vampire]

OJO is short for oss.jfrog.org