Build non-shaded jar as well as shaded

[dvgica]

Hi there, thanks for this very useful lib!

We are having a bit of trouble using it, unfortunately, because it's shaded-only. While shading a JAR can be useful to solve some problems, it can also cause different issues to crop up.

For example, when using the shaded JAR with sbt-assembly, you get conflicting files:

[error] (*:assembly) deduplicate: different file contents found in the following:
[error] /home/dvangeest/.ivy2/cache/com.fasterxml.jackson.core/jackson-annotations/bundles/jackson-annotations-2.6.0.jar:META-INF/maven/com.fasterxml.jackson.core/jackson-annotations/pom.properties
[error] /home/dvangeest/.ivy2/cache/com.orbitz.consul/consul-client/jars/consul-client-0.12.3.jar:META-INF/maven/com.fasterxml.jackson.core/jackson-annotations/pom.properties
[error] Total time: 19 s, completed 20-Sep-2016 10:54:39 AM

A simple solution to this is to allow the user to pick whether they want to use the shaded JAR or a non-shaded JAR. This PR tweaks the maven-shade-plugin config to build both a shaded and non-shaded JAR according to http://maven.apache.org/plugins/maven-shade-plugin/examples/attached-artifact.html.

This does mean that the default JAR is now un-shaded again, and to get the shaded JAR you need to put a shaded classifier on your dependency. While this is maybe a little annoying in the short-term, long-term it's closer to what people expect. That is, most people expect JARs to be un-shaded. Having a shaded JAR is an exception and should be treated as such.

Please let me know if I can do anything else to get this merged. Thanks!

[rickfast]

It's been hard to keep everyone happy with regards to transitive dependencies, so this seems like a good idea. Thanks

[rickfast]

0.13.0 is now available in jcenter and central

[dvgica]

Awesome, thanks a ton for the quick response.