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

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&gt; 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&gt; > 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