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/[email protected]/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

[agustinona]

Hi @danieldbower ,
We apologize for this not having gained traction yet, and thank you for the valuable contribution. Our team is currently analyzing this as it would mean supporting two packages along with the associated maintenance overhead.
We expect to have a resolution for this in the following quarters.

[danieldbower]

I'd recommend that if you wanted to stick with just one artifact, you go with the non-shaded version. That will remove some complexity and make the library more secure.
If you want to stay with the shaded version, please prefix 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

[silviuburceadev]

I feel like this should get some attention. More and more security issues appear for shaded libraries and instead of just bumping the versions in your own project, you have to wait for the fix in split.io Java client itself first, then bump its version to get the fix. I have personally opened 2 PRs in the last few weeks in this regard.

• Updated httpclient5 version to fix CVE-2025-27820 #556
• Update gson version to fix sonatype-2025-000535 #572
  A solution to this, if you want to keep it like that, with shaded libs, would be to add renovate/dependabot to stay up to date with the fixes.

[tobinibot]

This is becoming a little ridiculous, you’re shipping a library with security vulnerabilities when there is an easy fix within reach. Providing a non-shaded version not only resolves vulnerabilities, but in my experience, it will ease the burden on developers pulling Split into their environments. At one of my previous gigs, it took us a while to figure out how to pull in Split and get all the right Maven exclusions in place to actually get it to build without errors and we were left with a considerably more complicated pom.xml (and was the source of quite a bit of frustration along the way). It’s honestly a ding against Split in my mind as I consider pulling it in to new companies.