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

[Dan Berindei]

On Mon, Mar 14, 2016 at 12:21 PM, Sebastian Laskawiec
<slaskawi at redhat.com> wrote:
> 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:
>
> Stop relocating dependencies
>
> Pro: everything should work without problems
> Con: our dependencies will clash with client's dependencies
>
> 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
>
> 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?
>
> 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?

+1 for option 4. The embedded uber-jar doesn't expose any class in
org.jboss.logging, so it doesn't provide jboss-logging. The Spring
module should depend on jboss-logging itself, not assume that it's
going to be provided by another module.

One complication we have now is that we've made jboss-logging a part
of our API: one module's i18n Log interface can extend another
module's Log, and that means it extends the BasicLogger from
jboss-logging. I believe the Log interfaces should be private, and
each module should extend BasicLogger directly.


Cheers
Dan