Done because the split jar changes required registering the decompiler task after evaluation.
As there may be more than one decompile task, the options are set per decompiler and not per task.
This should also make easier to add new decompilers without requiring a plugin.
This lays the ground work for split client and server mod code. With this first phase when enabled loom will generate a clientonly and common minecraft jar. Fabric loader and API will both need changes to support this before it can be used to develop mods.
Phase two of this project will handle splitting mod code into a client and common source set along with spliting any dependencies.
Mostly fixes#539 by sepreating decompile tasks
* Fix decompiler tasks getting registered in afterEvaluate
* Allow decompilers to add file collections to the forked JVM classpath.
* General code cleanup.
* Use nio for zip utils
* Make tests work
* Please work
* Fix some issues with tests
* Fix more issues with tests
* NIOZipUtils -> ZipUtils
* Resolve Juuxel's reviews
* Use our own FS utils
* Improve error handling, add loom Pair
* Add Unit tests + fixes
Co-authored-by: modmuss50 <modmuss50@gmail.com>
* Rewrite CFR decompiler interface. Support javadoc
* CFR line numbers and fixes.
* Cleanup and fix
* Use WorkerExecutor to fork, massively cleans up the fernflower code, but does remove the fancy multithreaded logging.
* Use IPC to get logging back from the decompilers.
* Cleanup UnpickJarTask, fix leak in IPCServer
* Used published CFR build
* Handle older windows versions that do not support AF_UNIX.
* Fixes and basic unit test
* Improve memory handling of genSources
* Stop decompile worker JVM
* Add comments about transitive access widners to generated sources
* Migrate fully to mapping io
* Use release version of lorenz-tiny
* Review comment
