`MergeJarsTask` should be an `AbstractArchiveTask`
triphora opened this issue Β· comments
This way, it can be used more easily in Minotaur, for example.
We encountered the exact same issue in Longjing as well.
See this workflow run for more logs: https://github.com/teaconmc/Longjing/actions/runs/5453959652/jobs/9923451690
Log excerpt:
* What went wrong:
Execution failed for task ':teaconLongjingProcessing'.
> assert targetTask.get() instanceof AbstractArchiveTask
| | |
| | false
| task ':mergeJars'
provider(task 'mergeJars', class io.github.pacifistmc.forgix.plugin.MergeJarsTask)
* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
In Longjing, we assume that each project will produce exactly one jar (and if the project produces > 1 jars, we pretend that all other jars do not exist); to find out where the jar is, we further assume that, there is always an AbstractArchiveTask
that produces a ready-to-use jar. This has been proven to be the case for almost all standard and non-standard scenarios:
- Projects using ForgeGradle
- Projects using Fabric Loom, Quilt Loom or Architectury Loom
- Multi-project or multi-loader setup (where we support specifying a specific subproject to use)
The fact that MergeJarsTask
is not AbstractArchiveTask
breaks our assumption.
I have done some preliminary investigation; it appears that hard-coding some special casing on our side seems possible, but with unknown quirks.
I will give more updates once I have more info to share. Still, I personally believe this should be addressed on Forgix's end.
I still have no clue how to turn the task into an AbstractArchiveTask
can't figure out a way to detect all projects and their jars and have the task somehow return a single JarFile