On Mon, Mar 14, 2016 at 12:21 PM, Sebastian Laskawiec <slask...@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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
