-
Notifications
You must be signed in to change notification settings - Fork 8
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
Drop shading support? #91
Comments
@ieggel I just did a smoke test without using the shaded jar without problems. What is the reason behind using the shaded version? |
I implement Rest services in my project using spring boot, which also uses
Jersey. The version spring boot uses was at least in the past not
compatible with the version from docker-client.
…On Sat, Nov 16, 2019, 09:29 Dimitris Mandalidis ***@***.***> wrote:
@ieggel <https://github.com/ieggel> I just did a smoke test without using
the shaded jar without problems. What is the reason behind using the shaded
version?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#91?email_source=notifications&email_token=ACGEFGUGYFUNL3PVLRFBWNLQT6VQDA5CNFSM4JOEEYQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHMPJA#issuecomment-554616740>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGEFGQTBOUGUEZ35L4MOHTQT6VQDANCNFSM4JOEEYQQ>
.
|
Doesn't seem like spring boot is transitively pulling jersey. Could you please send me the spring boot dependencies you 're using? |
You might be right. I am not a 100% sure it was jersey, but there was a
conflict and using the shaded version resolved that problem. I can send you
a list on Monday.
Thanks for all your effort.
…On Sat, Nov 16, 2019, 14:31 Dimitris Mandalidis ***@***.***> wrote:
Doesn't seem like spring boot is transitively pulling jersey. Could you
please send me the spring boot dependencies you 're using?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#91?email_source=notifications&email_token=ACGEFGVBXP2U3KHTLOCGVU3QT7Y3RA5CNFSM4JOEEYQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHRTJY#issuecomment-554637735>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGEFGVGGLD6YUSKXEFOBY3QT7Y3RANCNFSM4JOEEYQQ>
.
|
Thank you for your help with these bugs. Shading is generally a time bomb ticking, I 'd want to get rid of it if it's not used anymore. Thanks again |
Found it out, this is what you were getting for com.spotify.docker:docker-client:8.16.0
This was reported at spotify/docker-client#1030 but it seems not valid anymore |
HI @dmandalidis, I now tried it with
As soon I replace Isn't this a jersey dependency? |
Yes it's a transitive jersey dependency which should have been pulled correctly though. Could you please try with |
@dmandalidis I've just quickly tried |
@dmandalidis I would ask not to drop shading support. We use this client with other internal APIs that are still using the older Jersey 1.x framework. If I recall, this caused a problem with the docker client and forced us to use the shaded version. |
Just in case, here my dependency tree.
|
@dmandalidis |
@ieggel no clue, discussions around the internet indicate a jersey bug but it's still not clear to me why this is happening. Docker-client directly uses MultiException and this should be pulled transitively by client projects. Needs more investigation from my side I guess |
@rwmajor2 I see. jersey-1.x is pretty old though and I 'd suggest you considering updating it (I know it may be a total mess). I 'll check if I can modify docker-client in a way that a different JAXRS client could be used when applicable |
@dmandalidis |
@dmandalidis I now did: grep -r "2.27" ~/.gradle/caches/modules-2/files-2.1/* So it seems that jersey is referenced in the following poms:
BTW i also asked a question on that behavior over at https://stackoverflow.com/questions/58937991/gradle-springboot-overriding-dependencies-jersey-and-apache-httpclient |
FWIW, we haven't used the shaded version in the past, but I was in the process of switching to shaded. The nice thing about shading is that the consumer doesn't have to add a big list of dependencies to their project that are sometimes hard to assemble. In my particular case, I want to use this in Eclipse plug-ins, so it has to be converted from maven to a P2 bundle. If it is unshaded, all of the dependencies also need to be converted to P2 bundles so that they can be consumed. This is always a small burden, but because this has so many dependencies it is a major maintenance headache. That being said, I understand why you want to drop shaded support and I see that shaded support is not really intended to support my use case. I guess I'll switch back to non-shaded - just wanted to provide some input about my use case. |
@tony-- I just wanted to gather the use cases to see if the extra caution with each dependency update will worth it. Will add an question mark in the description :) |
I have the use case I described and although it would reduce maintenance effort in some ways, it might require very frequent releases of shaded due to the frequent CVEs in dependencies. So in the end, it might be more practical to have consumers retain control of dependencies so that they can be updated piecemeal downstream. I'm not sure. As I mentioned, I haven't used shaded up until now, so obviously it is not a requirement. Just thought it might be nicer than maintaining all the dependencies separately. |
I just realized that I should clone the repo and run dependencyTree there. 🙄 |
I'm using gradle, not maven.
The gradle command is : ` ./gradlew dependencyInsight --dependency
org.mandas:docker-client`
Sorry cannot help regarding maven.
…On Wed, Nov 20, 2019, 19:04 Tony Homer ***@***.***> wrote:
By the way @ieggel <https://github.com/ieggel>, is it possible to use
dependencyTree to generate the list of dependencies for this library only?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#91?email_source=notifications&email_token=ACGEFGTBVM5J46F6CV3LUJ3QUV3ZTA5CNFSM4JOEEYQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEETLFNY#issuecomment-556184247>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGEFGVVC5PCUSDCYO6AURDQUV3ZTANCNFSM4JOEEYQQ>
.
|
#91) - Force use of Builder to create a Docker Client - Explicitly pull JAXRS API dependency - Pull out inner DockerClient builder to JerseyDockerClientBuilder - Setup builder inheritance so that a custom JAXRS client can be plugged - Switch Jersey dependencies to optional - Remove testing of notimeout methods
#91) - Force use of Builder to create a Docker Client - Explicitly pull JAXRS API dependency - Pull out inner DockerClient builder to JerseyDockerClientBuilder - Setup builder inheritance so that a custom JAXRS client can be plugged - Switch Jersey dependencies to optional - Remove testing of notimeout methods
#91) - Force use of Builder to create a Docker Client - Explicitly pull JAXRS API dependency - Pull out inner DockerClient builder to JerseyDockerClientBuilder - Setup builder inheritance so that a custom JAXRS client can be plugged - Switch Jersey dependencies to optional - Remove testing of notimeout methods
#91) - Force use of Builder to create a Docker Client - Explicitly pull JAXRS API dependency - Pull out inner DockerClient builder to JerseyDockerClientBuilder - Setup builder inheritance so that a custom JAXRS client can be plugged - Switch Jersey dependencies to optional - Remove testing of notimeout methods
Superseded by #161 |
Why would someone need to use this project's shaded version? What are the problems otherwise?
The text was updated successfully, but these errors were encountered: