Consider officially deprecating the GrEclipse-based formatter (and Eclipse CDT)

[nedtwigg]

@bric3 @jochenberger @diukarev (also of interest to @blacelle)

I think you have been active here making good contributions (apologies if I'm missing anyone else) related to the GrEclipse formatter. It is my view that maintaining the GrEclipse (and CDT) formatters are no longer cost-effective, in the sense that having formatted Groovy scripts is less valuable than the time it would take to get them.

That's just my personal view, I'm happy to merge PRs from interested parties, but I don't have time to investigate issues myself, and I am a little worried about merging well-intentioned PRs that break other parts of the system.

Here's the story:

• a long time ago, for each Eclipse-based formatter, we shipped a giant fatjar that bundled all of its dependencies, e.g. https://search.maven.org/artifact/com.diffplug.spotless/spotless-eclipse-groovy
• that lasted from 2018 - 2021. it was a lot of maintenance to keep them working, in Oct 2021 that maintenance stopped happening
• so in March 2023, we adopted Solstice. This meant that we could use the latest versions of Eclipse dependencies again. For Eclipse projects which published to maven central (e.g. JDT) it was smooth, for projects which don't publish all their jars to maven central (e.g. GrEclipse) it opened this can of worms around "where do the p2 deps get stored / how do they get downloaded"
• now it's May 2026, and these are the most-acute problems:
  • GrEclipse has changed its package metadata in a way, that Solstice doesn't support, so that we are once again stuck on an old version of GrEclipse
    • Update default Greclipse version #2924
  • publishing new versions of Solstice is currently not possible
    • deployment is broken (OSSRH shutdown back on June 30 2025) equodev/equo-ide#195
  • even if it were fixed, there is an unrelated and very mysterious bug around running GrEclipse with a fresh cache
    • Error when running with configuration cache disabled #2927
    • Fix #2950: tolerate null equality state in ConfigurationCacheHackList input fingerprinting #2951

I think the Eclipse JDT formatter is worth keeping, because all of its dependencies are in MavenCentral, it is tractable to use and distribute it. The rest of the Eclipse project is imo too dedicatedly esoteric, and this project would be much simpler to maintain if non-JDT eclipse projects were removed.

I'm not planning to remove it immediately. If anyone figures out how to get it working I'm happy to keep it. But if I understand correctly, greclipse mostly doesn't work in the latest versions of Spotless anyway.

My rough timeline is to add a deprecation warning ~July 2026 assuming we haven't made any progress by then, and then remove it completely ~Sep 2026 assuming that deprecation hasn't awoken some magical bear that causes the issue to get fixed.

[jochenberger]

First of all, I think we can actually get around the Solstice bug that we fixed recently and do #2924. I'm still looking for a cleaner way to do it (any help is much appreciated), but it lets us update to the latest GrEclipse version. On Java 25 that is.
As for the larger picture: I understand your concern and probably frustration with the Groovy formatter. And I would absolutely understand if you decided to remove it from the core project eventually. Unfortunately, there are no real alternatives to GrEclipse that we could use in Spotless.
Personally, I'd be a little sad about if the formatter was dropped since I use it for multiple projects, but someone could probably spin out a 3rd party library that keeps it alive.

[blacelle]

I think the Eclipse JDT formatter is worth keeping, because all of its dependencies are in MavenCentral, it is tractable to use and distribute it.

In my experience/usage (me and projects I'm related with), Eclipse JDT Formatter is a very important feature from Spotless.

On the other hand:

• Eclipse CDT might be a quite a niche (I personally used it for 3 weeks 15 years ago).
• GrEclipse / Groovy support: I suppose it's interesting coverage (as it better fits JVM eco-system) but I never used it (nor me neither projects I'm related with) and do not plan using it. I can't say it's not much used ; but if it's mostly broken and nobody complained...

I feel fine sunset-ing Eclipse CDT an GrEclipse: people actually interested might raise hands, and possibly help lifting the burden.

[jochenberger]

Maybe, if we could add support for npm-groovy-lint (#1121), that could provide a good alternative for everyone who's currently using the GrEclipse-based formatter.

[bric3]

The groovy formatter in spotless works well enough in our case.

Personally, I progressively moved from this is a fun language, to I don't like anymore the language, to code in this language is a burden to maintain. I (my colleagues as well) actively try to move away from it, whether it's gradle build script, tests (with or without spock), or just code. But the task is tedious and long, meanwhile having a working formatter is definitely useful. I don't know the burden of supporting (but deprecated) greclipse for as long as possible, i.e. remove it only if it prevents other improvements / changes.
Whatever you choose I know well the cost of maintaining a feature, so either way I'll respect your decision and support it.

By the way I've tried with prettier using prettier-plugin-groovy but the results were not that good #2788 (comment), maybe the npm-groovy-lint can be better.

By the way thanks for the notice.

[nedtwigg]

• @jochenberger - great fix in Update default Greclipse version #2924, that should keep it going for a while!
• @blacelle - I agree JDT is important, we will definitely keep it. Whether we remove greclipse or not, we can do Embed p2 lockfiles for Eclipse JDT #1996 which would isolate JDT from all this weirdness

Okay, I think the conclusion for now is: GrEclipse is the least bad of all options, with no good alternatives, and since Groovy is shrinking over time it doesn't make sense to invest in building up a new alternative. I'll keep it in, but when people have problems I'll probably close them out and point them to this heuristic:

• remove the greclipse step from your build
• does that fix the problem?
• then you face a choice - deal with greclipse or deal with its absence. The wonkiness (p2 downloads etc) are unlikely to improve, but users are free to opt-in to the pain so long as they choose ;-)

[jochenberger]

Oh boy, I guess I'd better get started on migrating my few hundred Spock tests. 🫠