Docker-java: Decouple library from Jersey

[coder-hugo]

This dependency makes it impossible to use your library for artifacts that have already a different JAX-RS implementation on the classpath. Therefore it would be nice if this dependency could be removed. A possible solution would be the following:

• provide an interface for initializing the docker client based on the given configuration (this should be the only thing Jersey is required for)
• use Java SPI to find a service provider implementing this interface on the classpath (ServiceLoader.load...)
• create the docker client within the builder using the found service provider
• implement at least a maven module that contains a service provider for the current jersey implementation

[garagatyi]

Mainteiners please comment if this idea is OK for you generally.
If you are OK with that maybe someone will contribute that.

[marcuslinke]

FYI: We will remove the jersey dependency with one of the next releases by replacing the default jersey based implementation with the netty based impl that is already included.

[garagatyi]

I don't think it will solve the problem.
Problem is that the library has 2 main subsystem:

1. api +core
2. http client impls

To make this library more usable it is better to separate these parts into several maven modules.
So first module should not have a lot of dependencies.
In that case other projects could include first part and implement second part with their own http client.
It is important for projects that don't want to increase amount of dependencies (by addition of netty, apache, jersey) or can't include some dependencies because it will require intellectual property approval form organization (e.g. Eclipse foundation).

As I can see first part uses:
fasterxml
guava
apache.commons.lang
bouncycastle
glassfish.jersey (used only once - in LocalDirectorySSLConfig.java)
slf4j

So if you separate api + core into the maven module and remove dependency to glassfish.jersey it will allow to use it more widely.

[KostyaSha]

I don't think that we would be ready to support such more abstractions.
You can use shaded library (we would resolve it soon).

[jamesnetherton]

Has there been any progress on this?

[bsideup]

See DockerHttpClient abstraction.