Sergei Egorov

FTR while #2202 does not fix it, it at least provides a workaround (no prefetch mode)

@decebals I'll sketch something. The bigger challenge is how to keep it backward compatible. Otherwise, it has to be targeted for 3.x, I guess

@chanseokoh @loosebazooka please excuse me for not following up - I missed the notifications :( > What exactly the current problem is, and how will making the class an interface...

@chanseokoh unfortunately it does not help, because: 1. I may not have Docker CLI on the host 2. I may need to communicate over an established communication tunnel that cannot...

Hi! FYI I am the current maintainer of https://github.com/docker-java/docker-java We now have an `api` package, as well as very lean transports like OkHttp (from 3.2.0) or Apache HttpClient5 (to be...

@chanseokoh per Testcontainers' experience, you only need `docker-java-api`'s dependencies and JNA (for native transports that you cannot avoid), the rest can be shaded. > And I see that docker-java-api pulls...

@loosebazooka > Yeah I could see the interface as being the right solution here (perhaps the serviceloader mechanic that we use for extensions) I hope there will be an option...

FTR `docker-java` provides a very lightweight transport abstraction that already supports tcp, unix sockets and npipes. There is also a `zerodep` transport that only depends on JNA & Slf4j: ...

@eddumelendez I would also propose to do multiple steps, where the first step is to make Jib's `DockerClient` part of the public API, to enable "bring your own client" 👍

It looks like there are two challenges with this: 1. OkHttp + TCP transport does not pass 2. Npipe does not implement `shutdownOutput` properly putting on hold for now