Do not publish Gradle module metadata

[wolfs]

Currently, this would produce a module metadata file which can't be
consumed by downstream projects, since it doesn't contain any
dependencies and only the hpi variant and not jar variant.

Until this is fixed, Gradle module metadata shouldn't be published.

I realized this when publishing version 1.36 of the Jenkins gradle-plugin: jenkinsci/gradle-plugin#94 (comment).

[sghill]

This looks good @wolfs!

Would you mind getting the codenarc task back to passing and I’ll get this merged/released?

[wolfs]

@sghill I fixed the line length: b4a6626

Though I am not sure if it wouldn't be better to relax the codenarc line length rule for tests...

[darxriggs]

I also suggest to relax this rule. The change currently implemented due to it (the abbreviated task name) just makes it worse.

[sghill]

This has been released as v0.36.2 today.

Thanks for this change @wolfs, and the link to the additional context.

I am not sure if it wouldn't be better to relax the codenarc line length rule for tests...

I agree, and I'm open to that change.

So far I haven't changed any of the static analysis settings because I'd like this plugin to (eventually) be implemented in Kotlin. I think Kotlin would simplify maintenance and give contributors more confidence when submitting changes.

Currently, this would produce a module metadata file which can't be
consumed by downstream projects, since it doesn't contain any
dependencies and only the hpi variant and not jar variant.

Supporting module metadata would be good. If we also had a way to create module metadata for existing plugins, it may help simplify the way we currently resolve/add dependencies to a project.

What's the best way to fix this? This use-case doesn't seem to fit the scenarios covered in Modeling feature variants and optional dependencies. I've also seen Working with Variant Attributes, but I'm unsure how I'd implement this (a new org.gradle.usage called jpi?).

[wolfs]

I created #129 for relaxing the code style rules.

[wolfs]

So far I haven't changed any of the static analysis settings because I'd like this plugin to (eventually) be implemented in Kotlin. I think Kotlin would simplify maintenance and give contributors more confidence when submitting changes.

I wonder if plain Java wouldn't work good enough as well. Most of Gradle's own plugins are implemented in Java.

[wolfs]

@jjohannes, could you describe your thoughts how to publish correct Gradle module metadata for Jenkins plugins?

[sghill]

I wonder if plain Java wouldn't work good enough as well.

It's possible, but one of the things I really appreciate about Gradle are the docs with high-quality examples. Since those examples generally aren't available in Java, I think that'd be a little less friendly than Kotlin.