JExcellence/JExDependency

JExDependency addresses a real problem for Minecraft plugin developers: large shaded JARs and dependency version conflicts. Its architecture covers much more than basic downloading. The implementation includes YAML descriptors, platform-specific dependency merging, transitive POM resolution, optional ASM relocation, Paper and Spigot loading paths, synchronous and asynchronous initialization, retry handling, offline detection, atomic file moves, and a shared server cache with file locking. Java 21 virtual threads support concurrent downloads, while explicit result types and failure policies give plugin developers control over startup errors. The README explains the motivation, API choices, configuration, cache locations, and migration from ShadowJar clearly. The recent JUnit tests also provide useful coverage for coordinates, result models, and classpath injection.

The largest concern is reproducibility. The public build uses two custom Gradle plugins and a libs version catalog, but the repository contains no settings file, version catalog, buildSrc, or included convention-plugin build. A fresh clone therefore does not appear to contain everything required for the documented ./gradlew build command. There are also no GitHub Actions workflows to prove that compilation and tests pass outside the maintainer’s local environment. Publishing the missing build configuration and adding CI for Java 21 would immediately improve confidence.

Security documentation also overstates checksum enforcement. The downloader requests a SHA-1 file, but accepts the JAR when that checksum is missing, malformed, or cannot be fetched. Cached files are generally trusted when they are structurally valid JARs. Since these downloads become executable server code, checksum absence should fail under a strict default policy, with SHA-256 or stronger verification and clear opt-out behavior. The README’s “sandboxed URLClassLoader” wording should also be changed to “isolated,” since a classloader alone is not a security sandbox. Finally, version references disagree: the build declares 2.1.0, while the README badge, Gradle properties, and downloader user agent still say 2.0.0. The LICENSE file is empty despite repeated MIT claims. Overall, the project has a strong technical design, but its public build, release verification, and supply-chain guarantees need to match the quality of the core implementation.