Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Wasn't the ability to add a single dependency to a project to start using Infinispan the whole purpose for the uber jars? I'm not trying to make an argument for keeping them, because I know they have caused many issues. I just think that if we are going to remove them from Maven, then there should be a way to achieve the same easy developer on boarding that uber jars were supposed to provide. Whether this is Maven project templates, or something else doesn't matter. Thanks, Alan ----- Original Message ----- > From: "Tristan Tarrant" <ttarrant(a)redhat.com&gt; > To: infinispan-dev(a)lists.jboss.org > Sent: Thursday, June 8, 2017 4:05:08 AM > Subject: Re: [infinispan-dev] Why JCache embedded has core as provided dependency > > 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 <galder(a)redhat.com >> <mailto:galder@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 <slaskawi(a)redhat.com >> <mailto:slaskawi@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/720f158cce38d86b292e1ce77... >> <https://github.com/infinispan/infinispan/commit/720f158cce38d86b292e1ce77... >> > [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 >> <galder(a)redhat.com <mailto:galder@redhat.com>> wrote: >> > Hi all, >> > >> > Re: >> https://github.com/spring-projects/spring-boot/pull/9417#discussion_r1203... >> <https://github.com/spring-projects/spring-boot/pull/9417#discussion_r1203... >> > >> > 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(a)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(a)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(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