<div dir="ltr">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).<div><br></div><div>So, once we are clear how Uber Jars should work... let's take a look at one of the problems:</div><div><ul><li>Many of our modules use JBoss Logging</li><li>Uber jars relocate dependencies (like the one above) into infinispan package. The result for JBoss Logging would be: infinispan.org.jboss.logging*</li><li>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)</li><li>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</li></ul><div>There are several options to solve that:</div></div><div><ol><li>Stop relocating dependencies</li><ul><li>Pro: everything should work without problems</li><li>Con: our dependencies will clash with client's dependencies</li></ul><li>Wrap 3rd party dependency with our own wrappers. In case of JBoss Logging - develop our own facade and put it in common.</li><ul><li>Pro: 3rd party dependencies will not leak between our modules</li><li>Con: A lot of effort and rather small gain</li></ul><li>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.</li><ul><li>Pro: Lots of Uber Jars for everyone</li><li>Con: How to use small jars in this scenario?</li></ul><li>Mark all module dependencies as provided and let users add small/uber jars themselves.</li><ul><li>Pro: It should give us the best results with the smallest amount of time</li><li>Cons: Not all scenarios will be solved. We will also need to stop relocating some dependencies (like logging facades which are used almost everywhere)</li></ul></ol><div>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).</div></div><div><br></div><div>Does it sound reasonable?</div><div><br></div><div>Thanks</div><div>Sebastian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 8:42 AM, Tristan Tarrant <span dir="ltr"><<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 11/03/2016 18:20, Galder Zamarreño wrote:<br>
> Are uber jars really that useful? From my own experience they often get<br>
<br>
</span>The number of users who don't use a dependency management system (Maven,<br>
Ivy, Gradle) is quite a lot higher than you'd expect.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tristan<br>
--<br>
Tristan Tarrant<br>
Infinispan Lead<br>
JBoss, a division of Red Hat<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>