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

[zml2008]

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]

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]

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]

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.