Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid throwing exception when minecraft configuration is empty #877

Open
sciwhiz12 opened this issue Jul 22, 2022 · 1 comment
Open

Avoid throwing exception when minecraft configuration is empty #877

sciwhiz12 opened this issue Jul 22, 2022 · 1 comment
Labels
feature request Requests a new feature to be added

Comments

@sciwhiz12
Copy link
Contributor

Currently, ForgeGradle's userdev plugin checks the minecraft configuration after project evaluation to ensure there is exactly one defined Maven dependency in the configuration. This is by design because the MinecraftUserRepo needs to be initialized for the rest of the after-project-evaluation logic functions correctly.

However, this causes confusion when the buildscript does not execute properly, such as a syntax error or a plugin error, causing the minecraft configuration to remain empty if it occurs before the dependencies block is executed. In that case, the above check will throw its own exception, confusing the developer as to the actual error.

The command-line output will show FG's exception second and closer to the prompt, becoming the first thing the developer will likely look at:

📷 Image of the command prompt with a Gradle build failure, showing two exceptions: the first is a syntax error from the buildscript, and the second is the "Missing 'minecraft' dependency" from ForgeGradle.

Image of the command prompt with a Gradle build failure, showing two exceptions: the first is a syntax error from the buildscript, and the second is the "Missing 'minecraft' dependency" from ForgeGradle.

For IntelliJ IDEA users, the error is even more confusing, as IDEA only shows the error message from ForgeGradle's exception: (this also shows the syntax error introduced in the buildscript for both screenshots)

📷 Image of the Build tab in the IntelliJ IDEA interface, showing a failed Gradle sync for the Concord project. The only visible error message is "Missing 'minecraft' dependency".

Image of the Build tab in the IntelliJ IDEA interface, showing a failed Gradle sync for the Concord project. The only visible error message is "Missing 'minecraft' dependency".

While the full error is visible by clicking the top-most entry in the Build tab, it is not obvious to users that the full error is visible there, and the same problem with the command-line output is visible in the tab's console:

📷 Image of the Build tag in the IntelliJ IDEA interface, showing the full Gradle output with both exceptions in the attached console window.

Image of the Build tag in the IntelliJ IDEA interface, showing the full Gradle output with both exceptions in the attached console window.

Futhermore, in the previous image, the tab was expanded to show the full console output. Normally, the tab is only a fraction of its depicted size, which means it only shows the second exception. This further causes confusion as the user needs to know to scroll up the window to find the actual error message.

To avoid confusion, the exception should not be thrown. Other alternatives should be considered, such as warning the user through a console message at warning/error level and/or silently accepting the lacking minecraft dependency by doing nothing to further configure ForgeGradle.

@sciwhiz12 sciwhiz12 added the feature request Requests a new feature to be added label Jul 22, 2022
@LexManos
Copy link
Member

I'd rather the exception still be thrown, is there no way to get the current build state and see if there is a error parsing the script? Why the heck would gradle continue execution if it can't parse itself...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requests a new feature to be added
Projects
None yet
Development

No branches or pull requests

2 participants