Shaded and non shaded versions

[danieldbower]

Corrects the url of the sdk documentation as the given url does not work.

Minor fix added to specify the version number for the maven-source-plugin

I also bumped the version to ensure I had some maven settings correct.

I was not able to run the redis module tests as that seems to be an integration test requiring some infrastructure.

The pom will now create a shaded version java-client-with-deps and a non-shaded version at java-client.

In this version, documentation referencing the shaded version's maven coordinates would have to change from this:

            <dependency>
                <groupId>io.split.client</groupId>
                <artifactId>java-client</artifactId>
                <version>4.9.0</version>
            </dependency>

to this

            <dependency>
                <groupId>io.split.client</groupId>
                <artifactId>java-client-with-deps</artifactId>
                <version>4.9.0</version>
            </dependency>

The original maven coordinates would be for the non-shaded version.

Why do this?
Simpler management of dependencies with tools like scanning for vulnerabilities and updates.

[danieldbower]

While this works, I'm increasingly convinced that the correct way to do it is a separate module so that the dependency list in the pom is correct in both instances.

[danieldbower]

Reasoning for the separate module: https://www.mail-archive.com/users@maven.apache.org/msg139854.html

[jbreton]

I'm using this package in a kotlin project. While it's working fine using JVM, it fails when using the native build (Graalvm). We believe the native build is not able to load some of the shaded dependencies.
It's quite hard to prove since SplitClientImp says the sdk is ready but all calls to getTreatment are failling. There are no other warnings or errors. It seems to at least call the API since we're getting a 400 Bad request error when using an invalid API Key.

[danieldbower]

Are there any suggestions or concerns with this PR that would increase its chances of being merged?

[danieldbower]

If you REALLY prefer to shade, then you should be prefixing those packages so they don't conflict with the rest of the app. See this feature of the maven-shade-plugin: https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html