11:50 a.m.
Hi,
uber jars were introduced as an answer to complaints such as "there
are too many jars" but I still think this was the wrong answer.. too
many issues so please stop this: it's not helping usability to
understand which jars are needed, and it makes things worse with
runtime errors not matching source code.
It was my impression that uber jars were a temporary solution to
improve things, while the real improvements - to actually need less at
runtime, or provide better errors pointing out what's needed - would
take more time.
So rather than stubbornly spend time maintaining this approach which
is so obviously broken, I'd rather see time spent in pursuing the
better improvements so that we can finally drop this.
Sebastian: I din't understand the idea behind proposal 2#: what does
it meant to provide our own facade to JBoss Logging? One will still
need to have JBoss Logging at runtime, right?
Thanks,
Sanne
On 14 March 2016 at 10:21, Sebastian Laskawiec <slaskawi(a)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?
Thanks
Sebastian
On Mon, Mar 14, 2016 at 8:42 AM, Tristan Tarrant <ttarrant(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev