[Jersey] Re: Jersey Repackaging

From: Marek Potociar <>
Date: Tue, 2 Sep 2014 15:09:32 +0200

Sometimes newer version has a bug that prevents us from upgrading.
Sometimes Jersey gets integrated into a final release of larger piece of software (Glassfish, WebLogic) and we do not force the users of the product to be limited to a particular version of a seemingly unrelated library, just because Jersey is using the library.
And of course, when we want to integrate Jersey into a commercial product, we need to get a legal approval for EVERY changed version of every third-party library that Jersey depends on. So, behind the scenes, it is a lot of work.

Initially, we were not repackaging.Fro the reasons explained above, we have changed the approach and started to repackage popular and frequently used 3rd party libraries that we depend on internally in the core modules. Of course, this may cause some duplicity in classes. To minimise it, we are also shrinking the repackaged libraries (i.e. we only include those 3rd party classes that we really need and use in our code; e.g. jersey-guava has 940kB while original guava library has more than double - 2.1MB).


On 25 Aug 2014, at 21:47, cowwoc <> wrote:

> Part of the solution is for Jersey to be more proactive in updating its dependencies. Keeping up-to-date with the latest releases isn't a lot of work.
> Gili
> On 25/08/2014 3:42 PM, Mark Thornton wrote:
>> Perhaps because not all build systems in use have something equivalent to shade. Also where the version used by jersey is particularly old (such as asm), far too many users would have to do the same repackaging.
>> Mark Thornton
>> On Monday, 25 August 2014, Robert DiFalco <> wrote:
>> Does the Jersey repackaged stuff mean that if I am using Guava in my project that there will be duplicate classes for all the stuff Jersey repackaged? Why is this a better idea than letting people use shade or something similar?