search

Kong / unirest-java

Unirest in Java: Simplified, lightweight HTTP client library.
http://kong.github.io/unirest-java/
MIT License
2.59k stars 593 forks source link

Shading all dependencies in standalone jar #383

Closed reini2150 closed 3 years ago

reini2150 commented 3 years ago

Just tried the new standalone jar with the hope to get rid of the dependenyManagement of gson 2.8.6 and commons-codec 1.11
in my projects pom.xml. But only the org.apache.http dep is shaded. Obviously there must be a reason but maybe you could also provide a "full" shaded with another classifier?

ryber commented 3 years ago

There is not actually a reason. It's a mistake

ryber commented 3 years ago

This should be complete in 3.11.04

reini2150 commented 3 years ago

3.11.04 standalone appears to have still a problem. Just found that the class kong.unirest.JsonObjectMapper imports com.google.gson.* META-INF\maven contains folders and pom.xml of the unshaded dependencies. So Maven still thinks that unirest has these external dependencies when e.g. viewed in eclipse's dependency hierachy panel.

ryber commented 3 years ago

I think thats the problem with Eclipse maybe. If you crack open the jar you will see that the google classes (and the apache classes) are not in the normal packages but in shaded directories. The point is not to not have the dependency but to avoid classloader issues. I'm not fully aware of what magic takes place in the classloader to make it look in the moved directory rather than in com/google.

If you can suggest where our setup is wrong I'm open to change

shade

ryber commented 3 years ago

If your goal is to NOT have gson at all, you should not use the shaded jar and should instead exclude gson in your pom. However this will result in you not being able to use any of the JSON functionality

reini2150 commented 3 years ago

Ok, I did not know about that. So you can still reference in your source the com.google.gson.Gson class but at runtime the classloader eventually takes the unirest.shaded.com.googlegson.Gson version? That's really magic.

ryber commented 3 years ago

That's always been the way I've done it. The compiler isn't aware of the moved dependency AFAIK and google's own code of course continues to reference itself in the expected com/google packages. The shader just moved stuff it doesn't recompile everything

ryber commented 3 years ago

OK, so I was wrong about how the plugin works, apparently it DOES rewrite the bytecode: https://medium.com/@akhaku/java-class-shadowing-and-shading-9439b0eacb13

I also noticed something weird about the way it was configured. The namespaces were being jammed together because we didn't have a . on the end of the relocation. I fixed that in 3.11.05 which will be in maven central in the next hour or so