chore(deps): bump org.siouan.frontend-jdk17 from 8.0.0 to 9.0.0

[v1nc3n4]

Hi,
I saw this dependency upgrade failed. I need to temporary enable Gradle stack traces and this plugin verbosity during CI workflow to identify the cause.
Thanks in advance!
BR

[tchiotludo]

thanks, approuve to run now!

[tchiotludo]

@v1nc3n4 seems that it's falling, you have any clue?

[v1nc3n4]

Hi @tchiotludo,

Indeed, I suspect the upgrade fails due to a dependency conflict. The plugin uses the latest version of Apache Commons Compress (v1.27.1) but another dependency in the project probably uses a version < 1.25, and the one retained during the Gradle build is not the latest one. It's difficult for me to tell more and to identify the plugin/dependency that brings this old version. I can't tell why this issue happens now whereas the project could be built without any problem in the past years. I cannot reproduce the problem neither on my Windows workstation, or my WSL Ubuntu system. Between releases 1.24 and 1.25 of this library, there is a method signature change that may explain the error itself.

From my personal experience, such issue generally occurs when the Gradle whole project does not clearly isolate each independent project from each other. Here, the root project contains all the configuration for the server project, and the client project is a subproject. I would recommend separating both projects and make each one an independent subproject. I guess this refactoring would not be simple, but it's a matter of moving server-related code, build scripts, configuration files in a dedicated subproject (named 'server' to be consistent with the 'client' subproject name).

However, there may be 2 workarounds:

• Declare explicitly the Apache Commons Compress dependency in the root project or the 'client' projet.
• Modify the plugin to "accept" a backward-compatible signature of the not found method in the Compress library.

I will experiment a little soon and provide additional info here.

[v1nc3n4]

Hi @tchiotludo

Here are some additional details:

• After fixing my local environment (my fault), I can indeed reproduce the issue under Windows and under WSL Ubuntu. Technically speaking, it is the same error under both O/S (i.e. a dependency conflict), but the exception message varies a little because it is not the same type of archiver used under the hood (.zip or tar.gz) to explode the Node.js distribution.

• The problem is clearly a dependency conflict. The plugin uses the latest version of Apache Commons Compress (v1.27.1). Another plugin uses an incompatible version of this library. The client subproject applies the frontend-gradle-plugin only. That means the plugin pulling the incompatible version is located in the root project.

The easiest way to prevent such issue is to retain the latest version of plugins, and expect each one to retain the latest version of their own dependencies.

After scanning the build, I found plugin com.github.davidmc24.gradle.plugin.avro applied in the root project uses Apache Commons Compress v1.24, which is incompatible with version 1.27.1. This is consistent with the 2 errors I reproduce under Windows and Ubuntu. I would suggest a dependency upgrade and a new version is requested but the project has been archived a year ago by maintainers.
If I comment this plugin as well as the idea.project.settings block, task installNode is now executed successfully.

I think this PR and the original Dependabot PR could be closed because the frontend plugin cannot be upgraded without dealing with the other plugin.
I hope this helps. Let me know your analysis :)
BR

For reference: Gradle forum discussion

[v1nc3n4]

I forgot to mention that I can confirm moving server related files (build script plugins and configuration, code, YAML configuration, etc) in a dedicated server subproject will certainly fix this issue particularly (successful POC with this repository), and prevent any conflicts between client-related plugins and server-related plugins.
The Gradle forum link I provided in my previous comment explains how the classloader attached to the root project affects classloader attached to each subproject.
BR