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.
Problem
docker-java-transport-zerodepshadeshttpclient5internally, relocating its classes fromorg.apache.*tocom.github.dockerjava.zerodep.shaded.org.apache.*. However, theorg/publicsuffix/list/effective_tld_names.datresource 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-zerodepandhttpclient5directly (e.g. via WireMock, Spring's RestClient, etc.), two copies ofeffective_tld_names.datland on the classpath at the same path. Maven'sduplicate-finder-maven-pluginfails the build. This failure is normally not a problem, but it can become one.Since,
PublicSuffixMatcherLoader(already shaded tocom.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.psl.PublicSuffixMatcherLoader) contains the hardcoded absolute resource path/org/publicsuffix/list/effective_tld_names.datin 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:This moves the dat file to
com/github/dockerjava/zerodep/shaded/org/publicsuffix/list/effective_tld_names.datinside the jar and updates thegetResource()call in the shaded bytecode to match — zerodep remains fully self-contained.