letting EngineModule see its assets

[keturn]

I'm trying to simplify Terasology's build configuration, as an offshoot of improving IntelliJ compatibility in #3954. One of the tweaks we have to our build process involves the output directories for classes and resources.

Things like this in engine/build.gradle: https://github.com/MovingBlocks/Terasology/blob/5480be2b567e7edf7a58afa875554a326306f86b/engine/build.gradle#L270-L274

I might be able to hack the builds so that happens consistently when built by either gradle or IntelliJ, but it'd be great we didn't have to.

The thing it trips up on is the configuration of the engine module, in https://github.com/MovingBlocks/Terasology/blob/00f44d1bdb421a6c0872b5b14a3e994050f8b07c/engine/src/main/java/org/terasology/engine/module/ModuleManagerImpl.java#L85-L93

That getResourceAsStream("/engine-module.txt") succeeds, so we know that resource is on the classpath in a place where this class may load it.

But then when it does that ClasspathModule.create(), the directory which held engine-module.txt doesn't end up in the new Module's paths.

Given that the Module implementation is already built around the idea of having multiple paths to search, this shouldn't be too much of a barrier.

There is an alternate constructor that offers to include the classpath in this Module's paths: https://github.com/MovingBlocks/gestalt/blob/fe1893821127c254cd135252de2676eff31d0152/gestalt-module/src/main/java/org/terasology/module/ClasspathModule.java#L115

It would be a quick change to use that without needing any changes from Gestalt. But it looks like it will include all the directories in sys.path, not just the one that had engine-module.txt, and I'm not sure if that's Too Much.

At least it looks like it does only add directories, not jar files, so it wouldn't be trying to crawl through every single jar on the classpath.

[keturn]

I just tried with that includeDirectories=true, and that was sufficient to get my IntelliJ-build running the simple scenario.

[DarkWeird]

If you will see blame... You will see: classes and resources compile/copy in build dir dierectly, before. I restore gradle way(idea follow it) build/classes. I think it right. I added small hack with copy resource to classes, when detected ClassPathModule, etc etc etc.

Engine add all in path, because it is libraries, not TS Modules. And it must be near with engine, because we have sandboxing, whitelists.

Futher, gestalt finding engine-module.txt and mark classes in same ProtectionDomain as engine and use it. It is do it for modules also.

ProtectionDomain have CodeSource(link to jar or directory location, where this resource class)

General problem, I think, is not linked resources and classes. In new world.

We can try use java modules as replacement part of gestalt's modules, sandbox,etc in future.

[keturn]

There is lots about gestalt's domains and sandboxing I have not learned.

If I understand correctly, we can use create(includeDirectories=true) with engine's module, because it is this special module, but we cannot use that same method for other modules. Right?

For the template build.gradle given to modules has this similar task:

https://github.com/MovingBlocks/Terasology/blob/5480be2b567e7edf7a58afa875554a326306f86b/templates/build.gradle#L180-L184

But modules are a complicated discussion, it is probably best to keep focused on building the engine in this issue.

Is this a good approach, to create engine's ClassPathModule with includeDirectories=true? Or is it better to find another way to specify its resource directory only, without the rest of classpath?

[DarkWeird]

Idk, it can break sandboxing :(