Is it possible to apply the maven publish plugin in a custom

Question

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 · Answer

What is custom build file

napperley · Answer

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

mazorius · Answer

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

mazorius · Answer

I did not really do a lot with this but in Gradle community that is more less the way slightly smiling face Maybe you should ask this question inside <http gradle community slack com|gradle community slack com>

napperley · Answer

Due to the way the project is structured that isn t possible <https github com napperley kotlinx atomicfu tree linux arm32 support>

napperley · Answer

Does the maven publish plugin only work properly in build gradle build gradle kts files

Vampire · Answer

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 · Answer

Not trying to develop a Gradle plugin

Vampire · Answer

Yes you do you just don t know

Vampire · Answer

What you try to use is called script plugin

napperley · Answer

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

Vampire · Answer

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

Vampire · Answer

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

napperley · Answer

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 · Answer

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

napperley · Answer

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 · Answer

That doesn t answer my question does it

napperley · Answer

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 · Answer

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

gildor · Answer

gt 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 I would highly recommend you to read first

gildor · Answer

gt 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 · Answer

gt 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 · Answer

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 · Answer

gt 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 · Answer

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

napperley · Answer

Tried that however the documentation is broken <https docs gradle org current userguide custom plugins html sec precompiled plugins>

gildor · Answer

documentation is broken what do you mean

mazorius · Answer

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 · Answer

The page looks good to me and also helps me while creating my first Gradle plugin what do you miss < napperley>

napperley · Answer

< 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 · Answer

At this stage it will be up to the Kotlin libraries team < elizarov> to resolve the major build issues with the AtomicFu library I have gone as far as I can to resolve the build issues

gildor · Answer

Custom plugin isn t being registered automatically What do you mean Maybe you could share your current code

napperley · Answer

Here is the link to the library fork <https github com napperley kotlinx atomicfu tree linux arm32 support>

gildor · Answer

And how to reproduce Try to publish

napperley · Answer

Doing a Gradle refresh will be sufficient to reproduce the issue

Vampire · Answer

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 · Answer

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 · Answer

End up with this confusing error message after running the publishNativePublicationToMavenRepository Gradle task ```Execution failed for task atomicfu publishNativePublicationToMavenRepository gt Failed to publish publication native to repository maven gt 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 · Answer

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

napperley · Answer

What is OJO

napperley · Answer

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

napperley · Answer

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 gt Could not resolve all files for configuration linuxArm32CompileKlibraries gt Could not resolve org jetbrains kotlinx atomicfu native 0 14 4 dev Required by project gt 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 · Answer

OJO is short for <http oss jfrog org|oss jfrog org>