The following error is very sad to deal with:

java.lang.NoClassDefFoundError: org/gradle/util/VersionNumber

Well, Gradle had

VersionNumber

class for quite some time, and it is sad Gradle 9 broke backward compatibility with plugins which still use

VersionNumber

from

org.gradle.util

I wonder what are the benefits for Gradle to drop the class. My guess is it does not require much efforts to support. It would be so much better if Gradle used something like

@Deprecated(level=Hidden)

instead of dropping the class.

I guess

level=Hidden

doesn't work for Java callers.

It does work

Interesting! TIL

Not that VersionNumber is specifically a bad offender here, but I would like Gradle drop and deprecate way more and way more aggressively

What’s wrong with

VersionNumber

?

because it shouldn't be a part of Gralde API, some completely random utility which should never be exposed to plugin authors

Like can you declare a Java class method "hidden"?

For the record, it uses

synthetic

til

@Andrey Mishchenko, it has been exposed since Gradle 1.2 (~2012). No questions why some of the projects accidentally import the class.

Exactly

That is a mistake to drop a class that has been exposed for more than 13 years

lack of real public API for plugin authors was a problem for long time, it's time to drop all this legacy

GitHub search shows quite some usages of the offending class: https://github.com/search?q=org.gradle.util.versionnumber&type=code

So my point: 1. Yes, it's unfortunate that some plugins broke (and yes we are also affected) 2. It must be reported more agressively before

Why dropping the classes that do not harm? Sure sometimes it might be complicated to “support” an old API.

I think everything outside of public API should be dropped as soon as possible

@Andrey Mishchenko, the fact that it was available, and the fact it was wildly used makes an excuse to avoid intentional breakage for the end-users. With the current case, Gradle breaks backward compatibility, and the team gives no reasons for the breakage.

Not only this class

So far this exact class prevents me upgrading pgjdbc/pgjdbc to Gradle 9: https://github.com/pgjdbc/pgjdbc/pull/3749

Send PR, hopefully plugin author will fix it

Sure thing. I’ve filed https://github.com/gradle/gradle/issues/34546 , and I’ll send a PR to resurrect

VersionNumber

Why? %)

karaf is not the only plugin that suffers

Just why not fix those few plugins

There a too many plugins and there are only 24 hours in a single day

YEs, we affected by Fladle plugin, send PR, publish own version

The approach of intentional breakages hurts the ecosystem

The fact that some plugins are not maintained shouldn't prevent Gradle evolution and API cleanup

The fact that Gradle drops the methods and classes makes its public image awful as in “Gradle XX broke my build”

Also this issue makes no sense, even if they return it (which will not happen), it already not available on Gradle 9.0

Sorry guys, don't mean to pollute your discussion with all my questions but the real question is how come those plugins haven't updated their usage in those X years/months while everything was deprecated?

So you reported that it was deprecated more than 2 years ago and got no answer for maintainer, so plugin is dead essentially

Keeping the backward compatibility for VersionNumber would be an easy task for Gradle, yet they decided to break things. That is what bothers me

You can just check on github usages of other org.gradle.util.* removed classes, also find many usages

That is why I suggest going with

Deprecated(level=Hidden)

. Have you seen the suggestion above? It would prevent new usages while it would keep backward compatibility at the same time

How would it help in your case? plugin is not updated for more than 5 years

Well, that would mean you need to reimplement that class in Kotlin as Java does not know that functionality.

plugins which have updates probably have no issues

@Vampire, one can add

synthetic

at the bytecode level with Java just fine

So you would need to re-implement all those classes in Kotlin, making sure the API stays the same, just to be able to mark them as hidden-deprecated

There’s no need to reimplement

Yes, one can, but that means they need to post-process the compiled code with some bytecode manipulation tool

post-processing is a small price to pay considering it would make Gradle’s backward compatibility way better

I don't think any effort to support unmaintained plugins that will fail to work sooner or later anyway is really warranted. 🤷‍♂️

I think support some abandonware plugin, last time released more than 5 years agon, which doesn't even support ActionT shouldn't be a priority for Gradle team, they have way more obvious areas to improve

Look at Java: they do support “bytecode 1.1”. They did drop

jsr

bytecode instruction in Java 1.6, yet Java still executes existing Java 1.5 classes that still use

jsr

instruction

Don't you think that for you just fork plugin, merge your Kotlin refactoring would be better spent of resources than try to restore 4 years deprecated internal api

To be fair, it was not internal api

Look at Gradle, it requires Java 17 to run

It was api that should have been internal but was in the public api

yeah, it was not, it was an issue of early Gradle versions, I totally understand it

I just for fixing it, not supporting previous mistakes

Java handled

jsr

removal much better than Gradle did with its

org.gradle.util

> I just for fixing it, not supporting previous mistakes Sure me too. But actually discussing about it here will probably not help much. I don't think we will be able to change Vladimir's opinion and even if he would change our minds, that wouldn't help with convincing the Gradle folks. 🙂

Resurrecting

VersionNumber

and

ConfigureUtil

does help: https://github.com/pgjdbc/pgjdbc/pull/3752 I copied the classes under

build-logic

, and it works. Unfortunately it breaks with Groovy doing some Groovy things:

groovy.lang.MissingMethodException: No signature of method: groovy.xml.MarkupBuilder.setOmitNullAttributes() is applicable for argument types: (Boolean) values: [true]
        Possible solutions: setOmitNullAttributes(boolean), isOmitNullAttributes(), setOmitEmptyAttributes(boolean)
            at com.github.lburgazzoli.gradle.plugin.karaf.features.KarafFeaturesBuilder.<init>(KarafFeaturesBuilder.groovy:35)
            at com.github.lburgazzoli.gradle.plugin.karaf.features.KarafFeaturesBuilder.<init>(KarafFeaturesBuilder.groovy:27)

However, the takeaway is that keeping

VersionNumber

and

ConfigureUtil

afloat is not that hard.

Maybe because of new Groovy?

may be. Looks like Groovy can’t somehow convert

Boolean

to

boolean

which sounds strange.

Look, without all the arguing, don't you think it would be better for your use case to fork the plugin and maintain? Genuine question, especially if you are an active user and the plugin is not maintained anymore by the original maintainer

Forking is literally investing time in reworking the release workflows. I remember I’ve spent some time refactoring the plugin, yet it was not complete (otherwise I would switch the status from draft to ready for review). Just to compare: it is a complete no-brainer for me to band-aid

VersionNumber

right under my

build-logic

, and it does heal

VersionNumber

issue. At the same time, forking the plugin, reworking the code, and pushing it would likely take much more time. For instance, Gradle forbids

com.github...

namespace for the plugins yet Maven Central happily accepts it. Those small breakages accumulate over time, and they do exhaust maintainers.

For instance, Gradle forbids

com.github...

namespace for the plugins yet Maven Central happily accepts it.

Those small breakages accumulate over time, and they do exhaust maintainers.

MC only accepts it for old namespaces. MC started with only accepting io.github for new namespaces.

You are right. Recently I faced it with one of my projects (

com.github.autostyle

which happends to be a fork of

spotless

🤣 ). I wan’t able to publish newer versions to Gradle Portal due to Gradle’s limitation. Luckily I can still publish to Central and postpone the group migration.

But yeah, of course forking and maintaining that fork needs time and dedication, that's out of question

ask for enabling it

The plugin was already published under

com.github.autostyle

before to Gradle Plugin Portal, and I expect they added a client-side validation.

I would not expect this to be client-side. Plugins previously published under that ID hopefully can post updates. I'd guess it is just an initial-validation check hopefully.

Does it really a problem to migrate group? I mean, it rarely requires more effort than update version I do not say that take care of plugin has no effort, only if I rely on open source project for my own work, I would like to make sure that it's maintained, and if not, fork it under my control

>Does it really a problem to migrate group? I mean, it rarely requires more effort than update version Renovate updates versions for me, so it is zero effort. Moving the group would require manual edits across all the usages or it would require a relocation artifact which is not easy to add since it is used once in a blue moon only.

I would not expect this to be client-side.

Plugins previously published under that ID hopefully can post updates.

I'd guess it is just an initial-validation check hopefully.

Yep, confirmed. https://plugins.gradle.org/plugin/com.github.sakata1222.jacoco-markdown was released 2 days ago and uses latest plugin version for publishing: https://github.com/sakata1222/jacoco-markdown-gradle-plugin/blob/main/plugin/build.gradle#L10 since 2 years ago.

The latest

com.gradle.plugin-publish

is 1.3.1 rather than 1.1.0 at https://github.com/sakata1222/jacoco-markdown-gradle-plugin/blob/f33e2f428792e5a62a6a5de8b88344a392f07b62/plugin/build.gradle#L10

Hey @Vladimir Sitnikov, For any publication issue of existing plugins, reach out to

plugin-portal-support at <http://gradle.com|gradle.com>