Remove relocations in POM

[g1thubhub]

Question: Why are there so many relocations/shadings in the POM file, the dependency tree of the current master branch is attached below, I don't see any ambiguities. I'm asking because I'll have a PR for a new OutputReporter soon and it crashes when keeping these relocations since there is some complicated initializations which gets confused by class names. When I removed these relocations, the new class worked fine in a local test....

Current dependency tree: [INFO] com.uber:jvm-profiler:jar:1.0.0 [INFO] +- org.apache.kafka:kafka-clients:jar:0.11.0.2:compile [INFO] | +- net.jpountz.lz4:lz4:jar:1.3.0:compile [INFO] | +- org.xerial.snappy:snappy-java:jar:1.1.2.6:compile [INFO] | - org.slf4j:slf4j-api:jar:1.7.25:compile [INFO] +- org.apache.commons:commons-lang3:jar:3.5:compile [INFO] +- com.fasterxml.jackson.core:jackson-core:jar:2.8.11:compile [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.8.11:compile [INFO] | - com.fasterxml.jackson.core:jackson-annotations:jar:2.8.0:compile [INFO] +- org.javassist:javassist:jar:3.21.0-GA:compile [INFO] +- org.yaml:snakeyaml:jar:1.18:compile [INFO] +- org.apache.httpcomponents:httpclient:jar:4.3.6:compile [INFO] | +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile [INFO] | +- commons-logging:commons-logging:jar:1.1.3:compile [INFO] | - commons-codec:commons-codec:jar:1.6:compile [INFO] - junit:junit:jar:4.8.1:test

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

phil seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[hiboyang]

The reason for the relocation is to prevent potential conflict between jvm-profiler's dependencies and spark application's dependencies. User's spark application may have all kinds of dependency, and jvm-profiler is attached to user's spark application. There is potential dependency conflict. Thus we do relocation in jvm-profiler jar file.

[g1thubhub]

Yes but I don't know if this actually creates problems: There is an open issue (https://github.com/uber-common/jvm-profiler/issues/30) about classes not found and I personally had issues when importing an AWS dependency and keeping these relocations

[g1thubhub]

I can recreate the issue if you want more explanations

[hiboyang]

You could create a new profile in pom.xml and remove the relocation. So it won't impact others.