Problem

docker-java-transport-zerodep shades httpclient5 internally, relocating its classes from org.apache.* to com.github.dockerjava.zerodep.shaded.org.apache.*. However, the org/publicsuffix/list/effective_tld_names.dat resource bundled by httpclient5 is not relocated — it remains at its original path inside zerodep's jar.

When a project depends on both docker-java-transport-zerodep and httpclient5 directly (e.g. via WireMock, Spring's RestClient, etc.), two copies of effective_tld_names.dat land on the classpath at the same path. Maven's duplicate-finder-maven-plugin fails the build. This failure is normally not a problem, but it can become one.

Since, PublicSuffixMatcherLoader (already shaded to com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.psl.PublicSuffixMatcherLoader) contains the hardcoded absolute resource path /org/publicsuffix/list/effective_tld_names.dat in its bytecode, it was not updated by the shade plugin's string relocation because the path uses slash notation with a leading /, not dot notation.

Fix

Add two relocation entries to the shade plugin config in docker-java-transport-zerodep/pom.xml:

<!-- Relocates the resource file itself -->
<relocation>
    <pattern>org.publicsuffix</pattern>
    <shadedPattern>com.github.dockerjava.zerodep.shaded.org.publicsuffix</shadedPattern>
</relocation>
<!-- Fixes the absolute-path string literal in PublicSuffixMatcherLoader bytecode -->
<relocation>
    <rawString>true</rawString>
    <pattern>/org/publicsuffix</pattern>
    <shadedPattern>/com/github/dockerjava/zerodep/shaded/org/publicsuffix</shadedPattern>
</relocation>

This moves the dat file to com/github/dockerjava/zerodep/shaded/org/publicsuffix/list/effective_tld_names.dat inside the jar and updates the getResource() call in the shaded bytecode to match — zerodep remains fully self-contained.