Should at least document the Jersey 2.x requirement

[sfitts]

For a variety of reasons the DropWizard framework (which gets fairly wide use) is still on Jersey 1.18. The fact that this library has moved on to Jersey 2.x means that it can't be used as part of a DW application (which unfortunately is my use case).

I'll be forking this to take it back to 1.18 for those of us who cannot switch. In the meantime you probably want to document this requirement. You may also want to consider whether you really need to be using Jersey 2.x (since I think you can use 1.18 client code in a 2.x application, but you can't go the other way due to the use of methods that don't exist in 1.18).

[marcuslinke]

@sfitts The current docker-java API (0.10.1) is designed to be independent from any REST framework so its possible to provide an jersey 1.x implementation of it. You could take a look at version 0.9.1 which is the latest version with jersey 1.x support and port it to the current API under package com.github.dockerjava.jaxrs1 for example. Doing it this way it would allow to merge the jersey 1.x implementation back into master as a submodule docker-java-jaxrs1. WDYT?

[sfitts]

Sounds reasonable -- didn't notice that abstraction. I've got the backport to 1.18 working (though not using that structure), so when I get some time I'll clean it up and do as you suggest.

How do the dependencies work in that case (the base maven dependency seems to be pulling in jersey 2.x by default right now).

[marcuslinke]

This would turn docker-java into a multi-module project with docker-java-api which is jersey independent and docker-java-jaxrs2 and docker-java-jaxrs1 modules each with its own dependencies. The user has to choose an implementation jar at build time but works against the API in his client code only. This would allow to easily switch to another implementation then.

[sfitts]

OK, so I can take a swipe at this unless you'd rather do the basic restructuring and then I can fill in the jaxrs1 side of things. Looks like the jumping off point for the abstraction is DockerClientBuilder -- there are some test classes that may need tweaking so they don't depend on either version directly (for example AbstractDockerClientTest). We may want to have a neutral version of the builder whose getInstance method uses reflection to load whatever real version is in the CP.

[marcuslinke]

I'd rather restructure the project only after being able to take a look at an existing jersey 1.x implementation of the current docker-java API as the whole concept is some kind of theoretical. So if you could provide such i will try to integrate it then.

[sfitts]

Created #66 which contains the Jersey 1.18 implementation (the Jersey 2.x code has been moved to jaxrs2 which is excluded (since we can't build both in the same module).

[marcuslinke]

OK. So finally your branch passes all tests after some minor fixes here. But before a can merge i will prepare pluggable implementations via java.util.ServiceLoader within in the current master branch.

[sfitts]

Thanks much.

[marcuslinke]

After some thinking a decided to not breaking up API and different implementations. It would be to expensive to maintain two separate implementations for me. There would be also a risk that one implementation stays behind the other as the API develops forward.