Problem
winrm-java is a library, and a library must not depend on any logging framework or facade. Problems must be exposed to the caller through exceptions only. Yet the dependency tree currently contains org.slf4j:slf4j-api:2.0.9:
com.hierynomus:smbj:jar:0.14.0:compile
+- org.slf4j:slf4j-api:jar:2.0.9:runtime
+- org.bouncycastle:bcprov-jdk18on:jar:1.79:runtime
+- net.engio:mbassador:jar:1.3.0:runtime
\- com.hierynomus:asn-one:jar:0.6.0:runtime
Our own code (main and light backend) does not use SLF4J anywhere — it comes in exclusively as a transitive dependency of smbj, which is used only by SmbTempShare (temporary SMB share for file copy).
Why a simple <exclusion> is not enough
smbj classes reference org.slf4j.Logger directly at class-load time, so excluding slf4j-api from the smbj dependency would cause NoClassDefFoundError as soon as SmbTempShare is used. As long as smbj is on the compile classpath, slf4j-api must ride along.
Proposed resolution
The clean fix is to eliminate smbj itself, which also removes BouncyCastle (bcprov-jdk18on, 8.2 MB — the reason the standalone CLI JAR weighs ~9 MB), mbassador, and asn-one in the same move, completing the zero-dependency goal of the winrm-light effort (#103–#108):
- Replace the SMB-based file copy in
SmbTempShare with a WinRM-native transfer (e.g. chunked base64 through the command shell / PowerShell, like other dependency-free WinRM clients do), or
- If SMB must be kept, implement the minimal SMB client in-house (we already have pure-JDK MD4/NTLMv2 crypto in
org.metricshub.winrm.light).
Acceptance criteria
mvn dependency:tree shows no org.slf4j artifact in any scope (and ideally no runtime dependency at all).- No logging API is called anywhere in
src/main; all failures surface as exceptions.
- File-copy functionality (
SmbTempShare use cases) still works against a real Windows host.
Problem
winrm-javais a library, and a library must not depend on any logging framework or facade. Problems must be exposed to the caller through exceptions only. Yet the dependency tree currently containsorg.slf4j:slf4j-api:2.0.9:Our own code (main and light backend) does not use SLF4J anywhere — it comes in exclusively as a transitive dependency of
smbj, which is used only bySmbTempShare(temporary SMB share for file copy).Why a simple
<exclusion>is not enoughsmbjclasses referenceorg.slf4j.Loggerdirectly at class-load time, so excludingslf4j-apifrom thesmbjdependency would causeNoClassDefFoundErroras soon asSmbTempShareis used. As long as smbj is on the compile classpath, slf4j-api must ride along.Proposed resolution
The clean fix is to eliminate
smbjitself, which also removes BouncyCastle (bcprov-jdk18on, 8.2 MB — the reason the standalone CLI JAR weighs ~9 MB),mbassador, andasn-onein the same move, completing the zero-dependency goal of the winrm-light effort (#103–#108):SmbTempSharewith a WinRM-native transfer (e.g. chunked base64 through the command shell / PowerShell, like other dependency-free WinRM clients do), ororg.metricshub.winrm.light).Acceptance criteria
mvn dependency:treeshows noorg.slf4jartifact in any scope (and ideally no runtime dependency at all).src/main; all failures surface as exceptions.SmbTempShareuse cases) still works against a real Windows host.