Terasology is an open source project started by Benjamin "begla" Glatzel to research procedural terrain generation and efficient rendering techniques in Java using the LWJGL. The engine uses a block-based voxel-like approach as seen in Minecraft. After proving itself as a solid tech demo begla was joined at first by Anton "small-jeeper" Kireev and Rasmus "Cervator" Praestholm and a full-fledged game concept was born. Our goal is a game that pays ample tribute to Minecraft in initial look and origin, but stakes out its own niche by adopting the NPC-helper and caretaker feel from such games as Dwarf Fortress and Dungeon Keeper, while striving for added depth and sophistication in the foundation systems akin to DF.
Need to add a dependency resolution exclude for the engine when modules check dependency resolution in a local source workspace, should always use local engine instead of grabbing a jar from Artifactory. As one example it happened from a plain "gradlew idea" with Holdings downloaded as source solo (making it pull some module binaries)
This is likely caused when a local source module has a transitive dependency not available in source form and THAT dependency then downloaded as a jar from Artifactory (with a .pom) has a transitive dependency on Core, which has a transitive dependency on a SPECIFIC version of the engine ... you can observe that by looking at the submitted .pom for Core in Artifactory. Instead it should be assumed the engine is ALWAYS taken in source from locally and not resolved from Artifactory ? And Core too, really, since it is in the same repo as engine.
On the other hand this might better be fixed by cleaning up resulting module .pom files. Quite possibly they should be written with the engine dependency excluded? Since there's no sensible setup where they are "lacking" an engine or are able to run with a different version of the engine than the one present (source or binary). Maybe a provided or compileOnly thing would keep the engine out of the .pom
Need to add a dependency resolution exclude for the engine when modules check dependency resolution in a local source workspace, should always use local engine instead of grabbing a jar from Artifactory. As one example it happened from a plain "gradlew idea" with Holdings downloaded as source solo (making it pull some module binaries)
This is likely caused when a local source module has a transitive dependency not available in source form and THAT dependency then downloaded as a jar from Artifactory (with a
.pom) has a transitive dependency on Core, which has a transitive dependency on a SPECIFIC version of the engine ... you can observe that by looking at the submitted .pom for Core in Artifactory. Instead it should be assumed the engine is ALWAYS taken in source from locally and not resolved from Artifactory ? And Core too, really, since it is in the same repo as engine.On the other hand this might better be fixed by cleaning up resulting module
.pomfiles. Quite possibly they should be written with the engine dependency excluded? Since there's no sensible setup where they are "lacking" an engine or are able to run with a different version of the engine than the one present (source or binary). Maybe aprovidedorcompileOnlything would keep the engine out of the.pom