AlessioDP / libby

A runtime dependency management library for plugins running in Java-based Minecraft server platforms.
MIT License
76 stars 20 forks source link

Issue with relocation of a dependency used by TransitiveDependencyCollector #31

Closed frengor closed 9 months ago

frengor commented 10 months ago

(Didn't actually happened, but I think it's possible to encounter this)

TransitiveDependencyCollector is loaded by an IsolatedClassLoader with its dependencies already loaded.
However, maven and gradle do apply relocations also to TransitiveDependencyCollector, so relocating, for example, org.eclipse.aether to my.libs.org.eclipse.aether would break it, since the dependencies are loaded but not relocated inside the IsolatedClassLoader.

Practically, this would happen if a project which is using Libby also makes use of maven-resolver (or similar) and decides to relocate it.

frengor commented 10 months ago

There are two possible solution to this I think:

  1. Relocate every package inside the IsolatedClassLoader, for example this method would become:
    public Library toLibrary() {
    return Library.builder()
        .groupId(groupId)
        .artifactId(artifactId)
        .version(version)
        .checksum(checksum)
        .repository(Repositories.MAVEN_CENTRAL)
        .relocate("org{}eclipse{}aether", "org.eclipse.aether")
        .relocate("org{}apache{}maven", "org.apache.maven")
        // etc etc
        .build();
    }
  2. Move TransitiveDependencyCollector to another module which is NOT shaded, but published separately and then downloaded and loaded at runtime into the IsolatedClassLoader like it was a dependency. This would fix every issue with relocations, but it puts more effort into the publishing and testing process.