[Refactoring]: Split maptool into different projects in the same repository

[thelsing]

Describe the problem

Currently we only have on big project than contains nearly all code. I would like to split this up into several jars like maptool-server, maptool-client-swing, maptool-client-common, maptool, maptool-model, maptool-lib-swing and so on.

We could also reintegrate dicelib into the main repository if we want.

The improvement you'd like to see

As a first step I would move the whole code into a subdirectory as specified here.

Expected Benefits

This will reduce comping time and makes it possible to add different clients while sharing much code. (We would need to separate actual gui from logic before that.

Additional Context

No response

[cwisniew]

Unless the code was in different repositories and then those jars were added in the build as the dependencies, this will increase the time taken for the build process not decrease it. Given the issues GitHub actions has been having for a while that's really undesirable.

[thelsing]

I meant rebuild times as I expect gradle to ignore all subprojects if nothing changed. Have to test it it really does.

[cwisniew]

our biggest problem at the moment though is github actions hanging, the longer it takes to compile from scratch the more pain involved.

[thelsing]

This may be true, but I fail to see how is this relevant for this issue.
With recompiling I'm talking about during development on a local machine.

[cwisniew]

Well the reason it is relevant is because doing it will have the above stated adverse effects so the problems it creates would be bigger than the benefits it creates.

[Phergus]

our biggest problem at the moment though is github actions hanging, the longer it takes to compile from scratch the more pain involved.

Looks like it was fixed by #3751

[kwvanderlinde]

I personally don't care about the JARs per se, but splitting up into subprojects would certainly be useful. We have a lot of bad interdependencies right now, and subprojects would avoid the worst of it. Thinking of how the model depends on the UI, how the clientserver code depends on some MT specifics, how there's no real separation of client and server state, etc.

Easiest to start with would be pulling out the clientserver code and some common libs. The model will probably be the worst to do, but if we can wrangle that away from the UI bits than the server code will come out pretty easily too.

[cwisniew]

I have no problems if we want to make them all their own repo, too (although everyone has been bugging me to do the opposite), but if the end goal is to try to suggest git submodules, then it's not going to happen as per other discussions on this. The reasons I have for this are

1. It raises the barrier for contributions / getting started for those unfamiliar with git.
2. (I guess this is also part of 1) Most GUI tools don't work well with it
3. Cleaning up when someone makes a mistake (due to 1 and 2 or just forgetting a step) is a PITA. When things are busy its time consuming enough to merge changes etc. Pushing more work into the funnel is just going to make things worse.

Sure we could script some of it in the gradle build but people forget to run spotlessApply enough times that its clear that's not really a solution that's going to fix the problems.

[irisiflimsi]

Do subfolders or really independent repos (as in independent deliverables) but don't use submodules. This has serious dependency consequences. (Take it from someone who's been there. I wish - still am there. :-( ) One example - may not be an issue now - is when moving code to another provider, say Gitlab. To quote you, it's a PITA.

[kwvanderlinde]

Absolutely agreed regarding git submodules, they are not the right tool for this project. Same for other takes on separate repos - despite being better in some ways than submodules, they're still a barrier when changes are needed across repos. So unless there's a real benefit for a particular case, let's just keep things in this repo.

[thelsing]

My intention was always to keep everything in one repo.