Is it possible to have

java-gradle-plugin

use a custom publication? The doc says

This automatic configuration happens in a Project.afterEvaluate() block (so at the end of the build configuration phase), and only if these publications haven't already been defined, so it's possible to create and customise them during the earlier stages of build configuration

But no matter what, the "java" component is added and the build fails with

Maven publication 'pluginMaven' cannot include multiple components

Can I tell

java-gradle-plugin

to use another component than the

java

one?

it's not in the docs, but there's an option to disable the automatic configuration

gradlePlugin {
  isAutomatedPublishing = false
}

https://github.com/gradle/gradle/blob/ebfcf97806a2c04b870652374bcbee2c915dac93/platforms/extensibility/plugin-development/src/main/java/org/gradle/plugin/devel/plugins/MavenPluginPublishPlugin.java#L66-L68

Does it also remove the plugin marker? I want the plugin marker 😅

yes please!

Features I currently use in

java-gradle-plugin

: • generation of the resource file • creation of the plugin marker

if it helps, you can try disabling the task for the automatic publication

tasks.withType<PublishToMavenRepository>().configureEach {
  onlyIf { publication.name != "pluginMaven" }
}

Yea but I'd like the marker to use my own publication instead of the default one

kotlin-gradle-plugin

would do the same as

kotlin-dsl

, but without the precompiled script plugins. And strongly encourage all of the best practice https://github.com/gradle/gradle/pull/24286

Ah yes, I see.

yeah, I'd prefer not to modify the other tasks/publications too

Yea, especially for Groovy I guess. But I'm hoping declarative Gradle will fix all of that 🤞

This might be an XY problem. What is your use-case? Why do you want to user a custom publication, what is wrong with the one created for you / what do you do differently in your custom one?

I want to publish the relocated jar by default

With

relocated

you probably mean you use the

shadow

plugin to create a fat jar and want to publish that instead?

Publishing to Maven Central

Sad, because the

plugin-publish

plugin has built-in support for the

shadow

plugin and will automatically publish that one. Ah, so you just obfuscate your code with R8? Or what is it? Just heard of it in relation to Android builds. If so, why do you do it? Maven Central only accepts open source libs anyway, doesn't it?

Ah, so you just obfuscate your code with R8?

Just relocate to avoid classloader issues, no obfuscation. R8 is designed for Android but it works with .class files too

Yeah, but it is against the terms of service most probably afair 🙂

They have been explicit about it, let me check

Oh, I see, thanks, maybe this changed at some point, or I just remember wrongly.

Yea, I think the explicitness is a recent addition but closed source has been allowed pretty much forever

So you do build a fat jar and use R8 for the relocation, right? Is it anyway a good idea to include the Kotlin stdlib in your plugin? Will that then not cause problems still as Gradle still controls the Kotlin execution environment / Kotlin version used?

Or maybe it was against TOS but they never enforced it, IDK

For typically conflicting things like ASM, I fully understand, except that then a user can also not use a

constraint

to update the ASM version when you for example use a version that does not support some class file version that the user is needing. I for example did this for the dependency analysis Gradle plugin. That also uses a relocated asm, but at least packaged and depended on as separate artifact, so I could update it without updating the plugin which was not possible for other reasons. But I thought relocating Kotlin stdlib like that will not be sufficient as Gradle still controls which Kotlin version that is used to execute it. Well, as long as it is a Gradle version with Kotlin 1.9 it will probably be able to use the Kotlin 2.0 stdlib because of the one version forward compatibility guarantee, but I'm not sure whether that's really worth the effort and you can still not run then on Gradle version before 8.3.0. 😄 That's why I personally would never use Kotlin or Groovy to implement a public Gradle plugin, but always just Java and there lowest version supported by the lowest Gradle version I want to support to have best compatibility. 🙂

> I fully understand, except that then a user can also no use a

constraint

to update the ASM version when you for example use a version that does not support some class file version that the user is needing. True > I thought relocating Kotlin stdlib like that will not be sufficient as Gradle still controls which Kotlin version that is used to execute it. Apollo has been using more recent kotlin version for several years now, it's working fine. > because of the one version forward compatibility That's at compile time. At runtime, if your plugin uses a K2 symbol, it'll crash (latest example)

If you disable the tasks for the "wrong" publication, that should not happen, should it?

True, still doesn't feel great

Or, back to just modifying the

java

component if possible 🙂

That works as well.