[Bug]: Converting to IntelliJ GUI designer as broken build / development process

[cwisniew]

Describe the Bug

The move to IntelliJ GUI designer performed in #3799 has been done in such a way that it's unclear on how to edit forms.

Editing a form in intellij does not properly update the source, there is no option to compile the form as it seems by default this is turned off if the project is using gradle as the build script is assumed to have the compile step. It also seems there is no complication in the build script.

At the moment I am left trying to make a change to the campaign properties form yet nothing I have tried has altered the dialog.

This is a step backwards from what we had.

To Reproduce

Remove a component on a .form and try replace it with a new one

Expected Behaviour

Development and build experience should not be a backwards step from what we had previously as a starting point. Ideally though the build script should have the compilation of the form in it.

Screenshots

No response

MapTool Info

No response

Desktop

No response

Additional Context

Update: You can build by changing the IDE settings to build via IDE rather than gradle. This is not really acceptable as goes against the philosophy of not tying the build to an IDE that was put in place when removing it from eclipse dependency to build. It also means that the build generated may not match the source if someone saves but forgets to swap their IDE settings. We will need to find a fix for this so that the gradle script compiles the form, or move to another solution if that is not possible (I guess as much as everyone hates it moving back to the old solution is easiest if we need to change).

[thelsing]

Documentation is https://www.jetbrains.com/help/idea/gui-designer.html.
You need to delegate "Build" to intellij and not to gradle. Then intellij will update the java files. "Also Generate GUI into" should be set to "Java source files"

[cwisniew]

unfortunately, this breaks the intention of having reliable, repeatable builds where you know the build reflects the source code. As of now it is possible for the source (.form) to be checked in with modifications that are not compiled, potentially hiding a bug that crops up when the next person wants to edit it leaving them to debug and look back in history to determine the intent of the change.

I have tried to get it compiling the forms via gradle with out any luck so far, if you also have no luck I will look at it this weekend.

[cwisniew]

I tried the above its marked every java source file that comes from a view as changed, this will cause issues going forward as well

[cwisniew]

The reason for the above is the generated source is based on the IDE config, so everyone has to have the exact same config. Which will obviously not work in practice :) Thats why we have spotless the thing everyone loves to curse so much

[thelsing]

We could get rid of the 'spotless off' tags around the generated code, but intellij and spotless will play reformatting ping pong.

[kwvanderlinde]

but intellij and spotless will play reformatting ping pong.

They already do 😅

---

I don't know how this is going so far, but I found some possible leads if needed.

Starting at the IntelliJ tracker, it looks like they do have a maven repo with the libs. And we should be able to use their ant task, as shown on SO. And there's what appears to be the maven equivalent as well.

I haven't tried it out yet, so I don't know how it will go.

[cwisniew]

but intellij and spotless will play reformatting ping pong.

They already do 😅

I don't know how this is going so far, but I found some possible leads if needed.

Starting at the IntelliJ tracker, it looks like they do have a maven repo with the libs. And we should be able to use their ant task, as shown on SO. And there's what appears to be the maven equivalent as well.

I haven't tried it out yet, so I don't know how it will go.

I tried that out (well a modified version to fit our build) and ran into an issue because gradle could not get the jar for the ant task, not sure why as it was available at the link added to the repository. So more investigation to be done.

[thelsing]

There is actual a gradle plugin that can compile the xml to classes.

To use it you have to remove most of the generated UI code. (You have to keep $$$getRootComponent$$$ because it's only generated when you create java code for whatever reason.) I did this in https://github.com/thelsing/maptool/tree/develop

It works as far as builds go.
BUT:
You have to clean every single time after you changed sth., before running during development, because you will end up with java.lang.ClassFormatError because of duplicate methods at runtime.
Not sure if this is better than the current solution.

[thelsing]

After some more experiments: We can delete the *View.class files in task before compileJava gradle task. Downside is that compileJava will now always run to compile the view classes.

If this is ok, I can create a PR.

[cwisniew]

After some more experiments: We can delete the *View.class files in task before compileJava gradle task. Downside is that compileJava will now always run to compile the view classes.

If this is ok, I can create a PR.

How much extra time does it add?
It might be worth requiring the clean at the moment, and removing the view classes from git, so at least the git hub actions are always picking up latest. Changing the GUI happens a lot less of than running for any change when doing dev so its probably the lesser of two evils to do it this way.

Its better than at the moment, where I make a change, then git status, then a bunch of git restore commands :)

I think I saw some view classes with a custom create method, though, so these would need to be changed.