Open DarkWeird opened 3 years ago
In Discord @DarkWeird mentioned the following configs that will need to be migrated to AutoConfig
:
Small note:
Optional: Telemetry and Discord not needs for server build
Discord: correct. Telemetry: want! Great way to send server logs and performance. There are client specific bits to the telemetry system though, like blocks broken and such. That part we could certainly skip, but then I'm not sure if that would enable by default 🤔
Investigation of possible to extract AutoConifg as Subsystem:
@In
InjectsPossible bonus. if we extract saving and loading from AutoConfigManager then per-game-saves will easier.(PathManager)
Think to do:
Context
(#4930)TranslationSystem
(there have Translator
(nui). but we needs getProject method.. which don't in traslator) or do TODO there Texture
and TextureUtil
ReflectionUtil.getFullyQualifiedSimpleUriFor
(engine). because AutoConfig is single user... but Yet Another ReflectionUtl.... (we have it in TS, in NUI)I was having trouble understanding #4930, but maybe re-reading the last comment here is helping.
I was thinking: Why bother extracting Context? Perhaps it is so Subsystems can use it, but, no, Subsystems do depend on Engine — they must, if for no other reason than the EngineSubsystem interface is defined in Engine. That means Subsystems may use a Context class defined in Engine too.
Looking at this, it seems it's because you want to extract AutoConfig as a library that has no Engine dependency?
It would help me keep things straight if we use different words for Subsystems vs non-Engine libraries. If the only obstacle to calling those “libraries” or “libs” is that we currently have the /libs/
directory doing a different job in our Gradle configuration, we can surely move or rename that.
I am also not totally sold on the utility of extracting libs to their own gradle sub-projects. It does carry some maintenance cost with it: for example, the recent case where we neglected to run tests on TypeHandlerLibrary for many months because we no longer invoke tests in the same way in all our sub-projects. On the other hand, it does add some constraints that help keep things more organized by preventing circular dependencies between packages.
I don't like current TS's engine:
Then i suggest:
I think about those categories now:
P.S. AutoConfig should provide config functionality for:
We cannot provide functionality for non-extracted subsystem and engine module... Because autoconfig using context. But we can extract Context-api and then extract autoconfigs!
Another example: We cannot extract rendering. We should extract api and impl... Because rendering using from bootstrap code(nuimanager) Then. Api should not use engine(circular dep) .
MTE example: MTE deeply using engines parts(runs engines and other infrastructure) We can extract it as subsystem (code module) and use it at engine.test(source set), facades, modules.tests. I think ideally place :3
You can provide you naming for /subsystem/
I think these are good categorizations. :+1:
Which of them want to be their own gradle-(sub)projects?
Advantages of being a separate gradle (sub)project:
Disadvantages of being separate:
build.gradle
to maintain.(There are, of course, ways to mitigate these disadvantages, but it adds a bit of work to do so.)
If an EngineSubsystem is optional or replaceable, so that a particular Facade may choose to build an application without it, I think that provides a good reason for wanting a separate jar.
On the other hand, a library such as THL will necessarily be a dependency for everything; no one will ever get the engine.jar without also getting the THL.jar.
Another thought, now that Terasology requires Java 11: Are Java Modules an alternative (better? worse?) way of describing the connections between these different packages and enforcing the API encapsulations we want for them? (If that is a can of worms that is too messy for now, please feel free to say so.)
Each has its own build.gradle to maintain
Yeah. I think about version catalog :3
More difficult to navigate the HTML Javadoc
Ehm. We have this? I think somewhere exists solution with html javadocs over several java libs.
On the other hand, a library such as THL will necessarily be a dependency for everything; no one will ever get the engine.jar without also getting the THL.jar.
There another reasons:
Another thought, now that Terasology requires Java 11: Are Java Modules an alternative ... I have some thoughts about this, but it is future:
- Replaces
@API
and our sandbox/security- Activate more aggressive optimization
- Seems easier tera module describes.(instead package module and jar module Cons:
- Java module have problems with unit tests yet(unit tests cannot access to internal packages)
- Needs support from gestalt side
Using Java Modules as gestalt Modules is a whole topic in itself. For now, I was wondering about these library-ish things, whether java modules' ability to define requirements and exports would help in this… but taking another look at that now, I think jars can only contain one module, and each gradle SourceSet can make one jar/module. That means this is not an alternative we could do instead of splitting these into different source directories— it's something additional we could do after splitting them up.
Mainly though, the "smaller engine part > easier maintenance" is what I am slow to understand. Why is org/terasology/engine/registry/*.java
easier to maintain if it is in /subsystems/Context/src/main
instead of /engine/src/main
?
You mention dependencies, and it does make it so if you're editing something there you can't just auto-import something from org.terasology.engine.world
without thinking about it; you have to pause and consider whether to manually add that dependency.
That is worth something, but I keep wondering if I have missed something else, because it doesn't quite sell me by itself.
On Javadoc: We do have Javadoc published on jenkins, if nowhere else. I think the build generates javadoc for everything, but the Jenkins built-in javadoc integration only publishes one javadoc directory for the project, so we have it pointing at /engine
currently.
Mainly though, the "smaller engine part > easier maintenance" is what I am slow to understand. Why is org/terasology/engine/registry/*.java easier to maintain if it is in /subsystems/Context/src/main instead of /engine/src/main?
Try to locate all parts of rendering. Try to locate all parts of any serialization. Try to locate all parts of health and destruction. Try to locate all parts of networking.
They placed in different packages. I try isolate one functionality in one place.
Context required to extract for another subsystems. (Also... Those gradle modules should be looks fine at dependency graph visualization)
Extraction subsystems should:
Telemetry
andDiscord
not needs for server build Replaceable:AudioLwjgl
andAudioNull
subsystems.Kallisti
->Jnlua
CoreRendering
->GraphicsLwjgl
Extraction subsystems shouldn't:
Module
sDraft extraction scheme:
Required Features:
4244 - for autoconfig. it ideally config system for subsystem ecosystem. needs 7 and 2.
Module
->Subsystem
dependency. Partial current solution for 'Library' subsystems - engine provides them as gradle'sapi
dependency (formal it is engine dependency)Extractions
DiscordRPC
subsystem #4233TypeHandlerLibrary
#4255EntitySystem
. ( requires ✅ #4565 for pure events and ✅ #4324 for serialize components)Outdated with #4324GsonSerializer
#4270 - needs 2.( follow-ups - migrate engine's code from pureGson
toGsonSerializer
)TypeWidgetLibrary
-- but first needs to merge #4244 ✅AutoConfig
.WorldStorage
to make it extendable.