Support Relocation
Opened this issue · 1 comments
Relocation is pretty much a necessity with any classpath based process.
Currently PDM does not do this at all, which in the future may cause problems in the form of conflicts.
Implementing this would be a trivial process into the pipeline:
- Download
- Relocate based on version or something random
- Load into classpath
There are existing libraries to do this (eg Lucko's jar-relocator
) or a custom solution may be necessary.
Relocation should likely be done in a typical format for 2 reasons:
- Maintains readable stacktraces
- Allows potential compatibility with things like shadow for transitive use.
This feature will likely also require a meta file that stores important information inside PluginLibraries
. (Eg original package name)
This will likely be a feature that takes time, as it's important to make sure it's fully working before publishing at all.
The current plan for this seems to be:
- Shade and relocate Lucko's jar-relocator + ASM into every plugin using PDM (should only add about 150-200KB), also relocating the PDM runtime in the process. (Shadow can probably do this for us)
- Relocated packages should be calculated at compile time if possible, with a configurable prefix. Default prefix will probably be
groupId.artifactId.libs
. These should be stored in dependencies.json (issues: how do we know what path to relocate? it doesn't always match the dependency's group and artifact. Hardcode in gradle plugin?) - The "pure" dependencies should be downloaded, and then each plugin using them relocates to a temporary directory before loading the relocated classes into memory. This means the PluginLibraries folder can still be shared.
I think that's it, hopefully will start working on this soon.