I think we should turn off maven deployment for uber jars. Tristan
On 6/7/17 5:10 PM, Gustavo Fernandes wrote: > On Wed, Jun 7, 2017 at 11:02 AM, Galder Zamarreño <gal...@redhat.com > <mailto:gal...@redhat.com>> wrote: > > As far as I see it: > > * infinispan-embedded should never be a dependency in a Maven project. > > * No uber jars should really be used as Maven dependencies because > all the exclusion that fine grained dependencies allow you to do > goes out of the window when all classes are inside a jar. This is > not just theory, I've personally had such issues. > > * Uber jars are designed for Ant or other build tool users that > don't have a dependency resolution engine in place. > > Cheers, > > p.s. I thought we had already discussed this before? > > > > I totally agree. In addition, uberjars should not be an osgi bundle or a > jboss module, for similar reasons. > > P.S: Even Ant has a dependency mgmt available, which is Ivy. > > Cheers, > Gustavo > > -- > Galder Zamarreño > Infinispan, Red Hat > > > On 7 Jun 2017, at 11:50, Sebastian Laskawiec <slask...@redhat.com > <mailto:slask...@redhat.com>> wrote: > > > > Hey, > > > > The change was introduced by this commit [1] and relates to this > JIRAs [2][3]. The root cause is in [3]. > > > > Imagine a scenario where you add JCache module to your together > infinispan-embedded. If your classpath was constructed in such a way > that infinispan-embedded was before infinispan-core (classpath is > scanned from left to right in standalone apps), we could get a > relocated (uber jars move some classes into other packages) logger. > That caused class mismatch errors. It is worth to mention that it > will happen to all relocated classes, logger was just an example. > And we need to relocate them, since a user might want to use his > own, newer version of DMR or any other library. So there's no > perfect solution here. > > > > Now a lot of time passed since then and we changed quite a few > things. So this topic probably needs to be revisited. > > > > So the first question that we should ask, shall we allow putting > jcache and infinispan-embedded together on the classpath. If the > answer is yes, I believe it should stay as it is (since the user > always have a choice whether he wants to use jcache with or without > uber jar). The same question needs to be asked for Spring modules as > well as all cache stores. The behavior needs to be consistent across > all those modules. > > > > If the answer is no (which is also valid because jcache is > already present in embedded uber jar), we should migrate all JBoss > Logging references to Infinispan Common Logging (as Tristan did here > [4]) and we can make infinispan-core as a compile time dependency to > jcache. Even though migrating to Infinispan logger is not necessary, > this way we won't break users app which used infinispan-embedded + > jcache approach. Of course the same applies to Spring and Cache > stores modules. > > > > I think the latter approach deserves some exploration. I would > vote for moving that way. > > > > Thanks, > > Sebastian > > > > [1] > > https://github.com/infinispan/infinispan/commit/720f158cce38d86b292e1ce77b75509342007739 > > <https://github.com/infinispan/infinispan/commit/720f158cce38d86b292e1ce77b75509342007739> > > [2] https://issues.jboss.org/browse/ISPN-6295 > <https://issues.jboss.org/browse/ISPN-6295> > > [3] https://issues.jboss.org/browse/ISPN-6132 > <https://issues.jboss.org/browse/ISPN-6132> > > [4] https://github.com/infinispan/infinispan/pull/4140/files > <https://github.com/infinispan/infinispan/pull/4140/files> > > > > > > On Wed, Jun 7, 2017 at 11:19 AM Galder Zamarreño > <gal...@redhat.com <mailto:gal...@redhat.com>> wrote: > > Hi all, > > > > Re: > > https://github.com/spring-projects/spring-boot/pull/9417#discussion_r120375579 > > <https://github.com/spring-projects/spring-boot/pull/9417#discussion_r120375579> > > > > Stéphane makes a good point there, why did we make core provided > dependency? It does feel a bit of a pain that anyone that depends on > jcache embedded also needs to depend on core. > > > > Any more details behind this decision? > > > > Cheers, > > -- > > Galder Zamarreño > > Infinispan, Red Hat > > > > -- > > SEBASTIAN ŁASKAWIEC > > INFINISPAN DEVELOPER > > Red Hat EMEA > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
