New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should at least document the Jersey 2.x requirement #64

Closed
sfitts opened this Issue Sep 30, 2014 · 9 comments

Comments

Projects
None yet
2 participants
@sfitts

sfitts commented Sep 30, 2014

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

This comment has been minimized.

Contributor

marcuslinke commented Sep 30, 2014

@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

This comment has been minimized.

sfitts commented Sep 30, 2014

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 comment has been minimized.

Contributor

marcuslinke commented Sep 30, 2014

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

This comment has been minimized.

sfitts commented Sep 30, 2014

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

This comment has been minimized.

Contributor

marcuslinke commented Oct 1, 2014

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

This comment has been minimized.

sfitts commented Oct 1, 2014

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

This comment has been minimized.

Contributor

marcuslinke commented Oct 2, 2014

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

This comment has been minimized.

sfitts commented Oct 2, 2014

Thanks much.

@marcuslinke

This comment has been minimized.

Contributor

marcuslinke commented Feb 8, 2015

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.

@marcuslinke marcuslinke closed this Feb 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment