Fix/nashorn per jvm and libraries zip - #200
Closed
EverNife wants to merge 3 commits into
Closed
Conversation
packageLibraries computed each artifact's Maven path and then dropped it: the into() call was commented out and the zipTree beside it fed nothing, so every jar landed at the archive root. The jar's own Class-Path, from generateClasspath(), looks each library up at libraries/<group as path>/<name>/<version>/<name>-<version>.jar. A flat archive matches none of those, which left this task shipping something unusable for the one case it exists to cover - an offline server that unpacks it, starts with an empty classpath, and dies on the first class a library owns. Each artifact now goes to that exact path, renamed to the Class-Path spelling because a published file name may carry a classifier and the entry never does. Verified against the built jar: 73 Class-Path entries, 73 archive members, no entry on either side without its pair.
The jar's Class-Path named nashorn-core for every JVM, and the JVM reads that
line before any Crucible code runs. On Java 8 the artifact is not merely unused
there: it publishes a javax.script.ScriptEngineFactory, so the first
ScriptEngineManager a mod builds dies with UnsupportedClassVersionError, and the
aborted service scan takes the JDK's own engine down with it - the server never
reaches "Done (".
A library can now be declared deferred in the build. It is still downloaded and
verified like every other one, so a single install serves either JVM, but it is
left out of the Class-Path and listed in a new Crucible-Deferred-Libs manifest
attribute paired with the lowest Java major that can read it. DeferredLibraries,
called from the RFB plugin, attaches the ones this JVM qualifies for to both RFB
class loaders: the launch loader answers the ServiceLoader resource scan, the
compat loader answers the class loads a LaunchClassLoader exclusion delegates
upwards.
Measured on a CustomNPC-Plus modpack, same jar and same libraries/ on both runs:
Java 8 boots first try reporting the built-in engine, Java 21 boots first try
reporting the standalone one, neither asking for a restart.
packageLibraries was never wired into buildPackages, and buildPackages is all CI runs. The release step attaches everything in build/distributions, so the offline archive was absent from every pre-release - it existed only for whoever knew to invoke the task by name. It is a dependency of buildPackages now, ordered after cleanPackages, which empties build/distributions: nothing related the two before, and an unordered pair can just as easily write the archive and then delete it.
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.
still testing, seems good