Change decompiler from quiltflower to vineflower

[manofthepeace]

QuiltFlower became VineFlower https://github.com/Vineflower
Where's Quiltflower?

In short, Vineflower is Quiltflower- created by the same team and having the same goals, just under a new name. The reason for this shift was not due to any drama or falling out with the Quilt team, instead from a desire to expand past a focus on mainly Minecraft and create a more general Java decompiler. Quiltflower grew significantly since its inception and had always been doing its own thing on the side, and this is a natural progression of the project.

Last version of quiltflower was 1.9.0 (https://github.com/Vineflower/vineflower/releases/tag/1.9.0)

see: https://quiltmc.org/en/blog/2023-07-09-quiltflower-is-now-vineflower/

This is a 'somewhat' breaking change as it removes the possibility of using quiltflower/older versions of quiltflower

[github-actions]

🙈 The PR is closed and the preview is expired.

[gsmet]

@yrodiere the failure above is an OOM for metaspace so it looks like we are not done with it, unfortunately...

[yrodiere]

Oh we certainly aren't... I just hoped the problem was mitigated just enough that we don't see it anymore. But indeed it seems we can still see it, so I'll have to have another look... someday...

[geoand]

Thanks for this.

Have you tried it to make sure it decompiles the code?

[manofthepeace]

I have downloaded the code.quarkus.io basic app to test it and it worked.

[geoand]

I assume you mean both with 3.3 and with the PR, correct?

[manofthepeace]

I only tested with the pr i.e. 999-SNAPSHOT. I would assume that 3.3 wont work without the pr as the repo url changed, unless you already have it downloaded in your ~/.quarkus

[geoand]

That's fine, thanks.

[gsmet]

I would assume that 3.3 wont work without the pr as the repo url changed

I checked and there is a redirection between the old project and the new one. If we are following the redirects when downloading it should be good.

Now I think we should probably move to a Maven Central URL such as https://repo.maven.apache.org/maven2/org/vineflower/vineflower/1.9.2/ to download the jar as we are sure these URLs are immutables.

[manofthepeace]

Now I think we should probably move to a Maven Central URL such as https://repo.maven.apache.org/maven2/org/vineflower/vineflower/1.9.2/ to download the jar as we are sure these URLs are immutables.

Done and retested.

[gastaldi]

How about renaming it to something future-proof? decompiler perhaps?

[manofthepeace]

I think it's somewhat meant to be futureproof in the sense you could have support for multiple decompilers for example the config is quarkus.package.vineflower.enabled=true maybe there could be support for another one this way? quarkus.package.my-other-decompiler.enabled=true. I may be wrong though!

a bit what I could gather from the code in #25729 where both fernflower and quiltflower could coexist

[gastaldi]

The reason I ask is that I never know the config to enable the compiler without looking at the docs. quarkus.package.decompiler.enabled=true is cleaner (to me at least) 😄

[gastaldi]

a bit what I could gather from the code in #25729 where both fernflower and quiltflower could coexist

Right, and I believe this is the reason why @geoand made it that way. I'm afraid that removing the config option would make existing users a bit annoyed, so perhaps deprecating (for removal) quarkus.package.quiltflower in favor of quarkus.package.vineflower may be better in this case

[gastaldi]

But I am still leaning towards having quarkus.package.decompiler.enabled, given I doubt anybody cares about the decompiler used in practice :)

[manofthepeace]

So is there a consensus here? :)

In my opinion, having both config, with the deprecated one is more or less useful as there isn't extreme adaptation to be made. On quarkus update, when looking at the migration it would be quite clear, vs deprecating, it, then doing it in some other release, not like if a behaviour changed underneath. As per quarkus.package.decompiler.enabled, I do like it, but definitely not my call! I can adapt to what you guys decide.

[geoand]

I'd like to keep the decompiler name for the time being.

[gastaldi]

Can we somehow use the Maven resolver APIs here? I fear that this may not work in environments with a firewall, but maybe it can be revisited in a future PR

[manofthepeace]

I am not exactly sure what that means as I have never used it. I wouldn't mind looking into it in another PR to have less risks in that one. For my comprehension, would it be about fetching the jar during build so it can be used form the MAVEN_HOME when needed? Or like currently download as needed via something like shrinkwrap/resolver (this does not seem to help with firewall though)?

[gsmet]

I would argue this is exactly similar to what it used to be. So let's not make @manofthepeace 's life harder than it needs to be.

[gastaldi]

This is a 'somewhat' breaking change as it removes the possibility of using quiltflower/older versions of quiltflower

If no future versions of quiltflower are expected, then this is okay.

[quarkus-bot]

Failing Jobs - Building d044e9b

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✔️	Maven Tests - JDK 11
✖	Maven Tests - JDK 11 Windows	Build	⚠️ Check →	Logs	Raw logs

[gsmet]

I think this is good and we can merge it, thanks.