Refactoring Modules

[Nedelosk]

@mezz, @marcin212, @KorDum What do you think we should do ? Remove the modules and add block / item registries or make the mod modules more separate so that they no longer depend on each other.

[KorDum]

Ideally, all modules should be divided. But this is quite a lot of work ...

[KorDum]

Can we divide ExtraBees only now? This should be quite simple.

[mezz]

We should try but I'm not sure how to set up grade to make it all work. I think it should be possible for them to be separated mods in one workspace, and have the dependencies and everything set up with grade.

[KorDum]

https://github.com/BuildCraft/BuildCraft/blob/8.0.x/build.gradle Can not help us?

[mezz]

I think that only splits up the output jars, it would not help us keep the modules separate in code.

[mezz]

I am getting help from someone with better knowledge of gradle, and they will give it an attempt tomorrow. Please avoid giant refactors for a few days, it will be difficult for you to merge old changes once we split up the project.

[marcin212]

https://docs.gradle.org/current/userguide/multi_project_builds.html

[mezz]

Yes that's exactly it. You can see the wip branch here: https://github.com/ForestryMC/Binnie/tree/wip-modules?files=1

When it's working we should probably do the same with Forestry.

[mezz]

Here is my plan so far:

First Half: Get the modules working in a fast dirty way.

• [x] Split the module using gradle so that the code cannot reference other modules unless specify a dependency.
• [x] Some things get moved into "core" that do not belong there, there are dependencies that should not exist, and there is one big "api" that has all the apis together, but it compiles.
• [x] Get gradle set up so that it creates the separate jars per module. The separate jars are not going on curseforge, but they might be useful in maven at least.
  • [x] Create one jar with all of them combined, so it matches what we have now.

When this first half is done we can develop on it. I am trying to do as little as possible here so that it is done more quickly.

Second half: Do it right, and get it clean.

• [ ] Create new API methods and correct abstractions so we can move things into the modules where they belong
• [x] Split "api" into one api module for every module, so we have "botany-api", "core-api", etc.
• [ ] Every module should only depend on "core" and apis.
• [ ] Do this whole process for Forestry too, and have Binnie modules depend only on the Forestry modules they need.
• [ ] Split modules further, so we have smaller sub-modules like alcohol and carpentry.

When the second half is done we will be able to have modules disabled without fear of breaking things. Advanced players can pick only the modules they want, and our code is cleaner.

[mezz]

The first half is complete and was merged here: https://github.com/ForestryMC/Binnie/pull/260

Now we all can clean it up for the second half.

[ferk6a]

Is this being worked on?

[mezz]

This is mostly working right now, the modules are separate mods. The work involved with gradle to make separate jars was really inelegant and frustrating so I took a break from it. I haven't had time to work on Binnie's lately so there is no further progress.

[ferk6a]

Ah ok, I ran into https://github.com/ForestryMC/Binnie/issues/305 (disabling genetics makes every block and recipe still show up, albeit broken) and ended up in this bug. Thanks for the update, though, I can see how separate jars can be frustrating, so far I've only seen Charset do it right.

[mezz]

Yeah, asie learned from Buildcraft which is also split into jars. It's a bit easier to do when you plan the project that way from the beginning, like Charset :)