search

SpongePowered / VanillaGradle

A toolchain for Minecraft: Java Edition that builds a workspace to interact with the game using the official mappings provided to the public by Mojang Studios.
MIT License
89 stars 18 forks source link

21w14a+: Use client filtered from server w/depend on server rather than JOINED #32

Open zml2008 opened 3 years ago

zml2008 commented 3 years ago

From a note taken during development:

    // TODO: reproduce 21w14a+ server/client split, where client is stripped of shaded server classes and depends on server artifact?
    // This would kinda blow our MinecraftPlatform model out of the water -- rather than creating a merged jar,
    // we simply strip all entries from the client jar that are also present in the server jar
    // The client artifact would depend on the server artifact

Can this be done in a sensible way? Would it be useful to anyone?

Zidane commented 3 years ago

I am trying to figure out why it would matter to have clearly defined client and server deps in the dependency graph.

Maybe for consistency? So if you are server only, you have a server artifact. If you are client only, you have a joined. With these changes, if you were client only you would have clearly defined artifacts as you would expect.

If anything, beyond enhancement, this would be low priority.

zml2008 commented 3 years ago

Yes, this is low-priority -- it's expected to be fairly trivial to implement once the pipeline is made flexible enough though.

The idea is projects using VanillaGradle could have a client sourceset and a server source set (only containing classes used on both sides), which would provide compile-time validation that projects don't try to access classes that don't exist on the appropriate side. I suppose mods could do that with client and joined artifacts right now, but the jar merging adds another step that is no longer necessary.

As of 21w14a, the client artifact has the exact same contents as the joined artifact, just without the annotations that would indicate something is client-specific, so it would be nice to eliminate mergetool eventually and expose the split in a form that IDEs and build tools can validate at compile-time.

Zidane commented 3 years ago

I agree, from that stance no longer merging is nice. There is still the stripping step so we didn't gain on removing toolchain steps so that is a wash.

Another nice thing I could think of is knowing, without looking at the code of a class or the package, where as class is sourced from.