[infinispan-dev] Uber jars - how do we want to use them

[Sebastian Laskawiec]

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:

   - Many of our modules use JBoss Logging
   - Uber jars relocate dependencies (like the one above) into infinispan
   package. The result for JBoss Logging would be:
   infinispan.org.jboss.logging*
   - Most of our modules are compiled with small jars (like Spring
   integration), so the compile dependency for Spring integration is
   org.jboss.logging (not infinispan.org.jboss.logging)
   - If someone wants to use Spring with Uber Jars (which should be
   absolutely fine), he gets a clash... Spring module can't find JBoss Logging

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160314/7f0010b9/attachment.html