I took a look at Nexus download statistics and Infinispan Uberjars are about 7% of our downloads (of course this calculation has been based on our JBoss Nexus instance and we have no data from other mirrors).

So, once we are clear how Uber Jars should work... let's take a look at one of the problems:
There are several options to solve that:
  1. Stop relocating dependencies
    • Pro: everything should work without problems
    • Con: our dependencies will clash with client's dependencies
  2. Wrap 3rd party dependency with our own wrappers. In case of JBoss Logging - develop our own facade and put it in common.
    • Pro: 3rd party dependencies will not leak between our modules
    • Con: A lot of effort and rather small gain
  3. Develop 3rd party dependencies as Uber Jars. In case of Spring - we will have a Spring Uber Jar. I think Dan put this idea on the table.
    • Pro: Lots of Uber Jars for everyone
    • Con: How to use small jars in this scenario?
  4. Mark all module dependencies as provided and let users add small/uber jars themselves.
    • Pro: It should give us the best results with the smallest amount of time
    • Cons: Not all scenarios will be solved. We will also need to stop relocating some dependencies (like logging facades which are used almost everywhere)
Having in mind our download statistics I would go for #4 (even though it doesn't solve the problem entirely). However #2 seems like a better fit for long term maintenance and we should proceed with this direction if number of Uber Jars users will grow (I can set a reminder in a 3-4 months time).

Does it sound reasonable?

Thanks
Sebastian

On Mon, Mar 14, 2016 at 8:42 AM, Tristan Tarrant <ttarrant@redhat.com> wrote:


On 11/03/2016 18:20, Galder ZamarreƱo wrote:
> Are uber jars really that useful? From my own experience they often get

The number of users who don't use a dependency management system (Maven,
Ivy, Gradle) is quite a lot higher than you'd expect.

Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev