fix: enable Scene Builder to load FXML with unresolved imports (#120, #281, #733)

[Oliver-Loeffler]

This fix allows Scene Builder to load FXML files with unresolved imports.
There is also a new option (keep unresolved imports) which also allows to keep the imports in saved FXML files. This can be toggled in Scene Builder preferences dialog.

If disabled, Scene Builder will effectively omit those unresolved imports and remove them from the updated FXML to be written.
If enabled, Scene Builder will keep track of unresolved imports and write them (unmodified) into the updated FXML. The import remains as it was declared in the original FXML file. Optimization is not applied to unresolved imports.

Of course, one cannot make use of unresolved imports and edit these controls. But, one can at least open an FXML file, edit and rework it in parts. Also, Scene Builder will inform the user that there is something wrong with the imports - it will not silently ignore the issue. This is quite helpful with foreign projects where users only want to look into the files and get a feeling of how the UI would look like.

This PR also increments Maven-Surefire version from 3.0.0-M5 to 3.5.0 in order to mitigate module system related errors during test.

Issue

Fixes #120
Fixes #281
Fixes #733 (added on 2024-09-29)

Progress

• Change must not contain extraneous whitespace
• License header year is updated, if required
• The PR name must follow the pre-defined format
• Verify the contributor has signed Gluon Individual Contributor License Agreement (CLA)

[Oliver-Loeffler]

This one no longer works as it used to. I'll review and rework accordingly. Loading FXML files with unresolvable imports works. Saving does not work anymore. I'll also add example FXMLs and tests for the FXOM.

[Oliver-Loeffler]

@abhinayagarwal or @AlmasB Could you please review this one?
This one addresses the issue, that some FXMLs have import statements which cannot be resolved by Scene Builder (e.g. JARs not availabl etc,). This one solves #120.

The idea is:

• SceneBuilder offers a preferences setting to ignore (and preserve) unresolvable imports.
• If it is permitted to load FXMLs with unknown types:
  • The resulting FXOMDocument will keep track of the unknown types.
  • FXOMSaver and FXOMRefresher will ignore those imports (e.g. will also remove them conditionally from any intermediate created FXML text).

Interesting would be your opinion to see if this approach is helpful and maintainable.

Thanks!

[Maran23]

I think this is a nice feature! Left some comments

[Maran23]

Tested with many FXMLs, removed some Imports and worked pretty good. The error dialog does not appear when I drag and drop a FXML file, but that might be expected?

Also one interesting note:

When I drag in a FXML with a custom component that is not know by the Scenebuilder, it will not load (as before).
But: If I remove the custom component import, it will load the FXML, which is a bit odd 😄 but probably expected, since this is really about the missing imports, I guess?

[Oliver-Loeffler]

I had to re-run mvnw package, mvnw install and mvnw javafx:run -f app in order to get the desired result.
On an attempt to load an unsupported (invalid, broken etc.) FXML file, a dialog is shown from the Welcome screen indicating the error.

Unfortunately, it does not show why - this could be helpful.

The behavior is basically expected. Its about the missing imports. Generally, the components are instantiated, hence those must be available for class loading.

[Maran23]

I had to re-run mvnw package, mvnw install and mvnw javafx:run -f app in order to get the desired result. On an attempt to load an unsupported (invalid, broken etc.) FXML file, a dialog is shown from the Welcome screen indicating the error.
Unfortunately, it does not show why - this could be helpful.

Could be a good followup, I agree.

The behavior is basically expected. Its about the missing imports. Generally, the components are instantiated, hence those must be available for class loading.

That makes sense. I wonder, since this lays the groundwork: We could handle unknown components the same way as if there import is missing. Since then, we can still load the FXML, which is better than failing. In any case, this should be a follow up!

[Maran23]

this looks good to me! Tested various scenarios and they all work for me.

[Oliver-Loeffler]

@jperedadnr could you please review again? Lots of additional work was done to shape this.