3.x package collision with 2.x

[jtnord]

The 3.x line uses the same package names as the 2.x line.

This causes issues where a library uses 2.x and another one uses 3.x and you want to use them both in an application.

Ideally when breaking changes (on a rare occaision) the maven artifactId should be updated along with the package names.

possible solutions to this are shading the dependency in the application which would need to shade all libraries using the 2.x line in a separate maven module and then include those, but shading is an instrument of last resort.

I guess it is probably too late now - but would there be a chance of a 3.x version with different artifactId and different packages?
or abandon the 3x and jump to 4.x with this rename (which I do understand would be a pain to users who are using 3.x - but would be a one time hit and relatively easy to do with an IDE refactor)?

An example of this is usage in Jenkins plugins (and whilst we could disect Jenkins plugin classloader isolation or lack of) we where looking to replace guava due to its breakages and use caffiene as the cache replacement - but as Jenkins is currently using java8 we would use the 2.x line, but in the future we are looking to move to Java11 and at that point expect some plugins to want to start using shiny new things. e.g. jenkinsci/stapler#213

[ben-manes]

The two major versions have almost identical apis. The difference is removal of deprecations and, for rarely used methods, small signature changes. For example returning the future in LoadingCache.refresh(). As long as the 2.x cases are using the latest version and doesn’t use deprecated apis, there is unlikely to be a problem. The vast majority of the changes are internal, e.g. replacing Unsafe with VarHandles. This is why changing packages did not appear to be necessary.

[ben-manes]

If you can identify an actual problems please let me know. It appears from your project's issue that it is a misunderstanding when reading the release notes by assuming there are "shiny new things", when in fact it's the same humdrum feature set. I plan on closing after letting this sit for a bit, unless there is a clear call to action.

[oleg-nenashev]

FTR https://github.com/jtnord/caffeine-api-plugin is a follow-up API plugin on the Jenkins side. It currently uses 2.x

[jglick]

https://github.com/jenkinsci/caffeine-api-plugin officially

[ben-manes]

Thanks for putting that together @jtnord! That's awesome. 🙂