bristermitten/pdm

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:

  1. Download
  2. Relocate based on version or something random
  3. 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:

  1. Maintains readable stacktraces
  2. 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.