Add vanilla run support#342
Open
mezz wants to merge 2 commits into
Open
Conversation
## Context JEI client tests need to compare behavior across: - NeoForge client with JEI + NeoForge server with JEI - NeoForge client with JEI + NeoForge server without JEI - NeoForge client with JEI + vanilla server without JEI - vanilla client without JEI + NeoForge servers with JEI Before this change, a NeoForge-enabled project could create client or server runs with no loaded mods, but those runs still used the NeoForge userdev runtime. For true vanilla fixtures, JEI needed separate vanilla-mode projects or custom wiring. ## Changes This change adds two run helpers: ```groovy vanillaClient() vanillaServer() ``` These helpers: - use the vanilla run templates - clear loaded project mods by default - use a dedicated vanilla runtime classpath - avoid inheriting the NeoForge userdev runtime in NeoForge-enabled projects IDE integrations also avoid using the ordinary application classpath for dedicated vanilla runs: - IntelliJ and Eclipse generate Gradle-backed run configurations - VS Code uses the generated launch classpath argfile and disables the default Java extension classpath ## Why This lets a project declare vanilla client or server fixtures alongside its NeoForge runs. For JEI, that means vanilla client and server fixtures can live in the NeoForge project next to the other client-test fixtures, instead of needing separate vanilla-mode subprojects only for those runs. ## Testing - `./gradlew build --no-daemon` - Unit coverage for: - the vanilla runtime dependency model - empty loaded-mod defaults - IntelliJ/Eclipse/VS Code vanilla run IDE wiring - Functional coverage for: - evaluated vanilla run classpath wiring - vanilla run task graph scheduling with `runVanillaClient --dry-run` - preserved dev-launch wiring for ordinary runs that select a source set
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
JEI is optional on both the client and server, so good client tests need to compare behavior across a matrix of possible server/client combinations:
Before this change, a NeoForge-enabled project could create client or server runs with no loaded mods, but those runs still used the NeoForge userdev runtime. For true vanilla fixtures, JEI needed separate vanilla-mode projects or custom wiring.
Changes
This change adds two run helpers:
These helpers:
IDE integrations also avoid using the ordinary application classpath for dedicated vanilla runs:
Why
This lets a project declare vanilla client or server fixtures alongside its NeoForge runs.
For JEI, that means vanilla client and server fixtures can live in the NeoForge project next to the other client-test fixtures, instead of needing separate vanilla-mode subprojects only for those runs.
Testing
./gradlew build --no-daemonrunVanillaClient --dry-run