On Thu, Jun 8, 2017 at 1:07 AM, Sanne Grinovero <sa...@infinispan.org> wrote:
> On 7 June 2017 at 16:48, Galder Zamarreño <gal...@redhat.com> wrote: > > What has changed is that Stéphane has made a very good point which I had > not realised: > > > > Making core provided dependency means a JCache dependency user needs to > add core dependency on top of that, which reduces usability. Core jar is > not a provided dependency of JCache, it's a normal dependency. I don't > think provided dependencies should be used to get around uber jar > dependency issues. > > > > IMO, the bigger usability issue is the fact that uber jars are available > as Maven dependencies. Uber jars should just not be distributed as Maven > dependencies. They should just be put somewhere else but not in Maven. > That'd way we'd avoid the problem in the first place. > > > > In the mean time, I think we should: > > > > * Move back to having normal dependencies for core in JCache (and Spring > too, if it applies) > > +1 > > > * Go through our examples and avoid using uber jar dependencies. > > +10 > > > Then, explore the idea above of not having uber jars as Maven > dependencies. > > +100 > > They are designed for developers on outdated platforms. Let's ship > them exclusively on floppy disks? > We should also stop depending on 3rd party uber-jars, like we do with netty-all, due to reasons described on [1] [1] https://github.com/netty/netty/issues/4671 Gustavo > > > > > Cheers, > > -- > > Galder Zamarreño > > Infinispan, Red Hat > > > >> On 7 Jun 2017, at 12:23, Sebastian Laskawiec <slask...@redhat.com> > wrote: > >> > >> We discussed it number of times, including (but probably not limited > to): > >> • http://lists.jboss.org/pipermail/infinispan-dev/2016- > February/016414.html > >> • http://lists.jboss.org/pipermail/infinispan-dev/2016- > March/016490.html > >> You might also want to look into the internal lists... > >> > >> The biggest question - has anything changed? Do we have any other idea? > >> > >> On Wed, Jun 7, 2017 at 12:05 PM Galder Zamarreño <gal...@redhat.com> > wrote: > >> Moreover: > >> > >> * The experience of Maven users should never be penalised by uber jars. > Uber jar users should be a minority compared with Maven/Gradle...etc users > that have dependency engines in place to select which components they want > to depend on. > >> > >> Cheers, > >> -- > >> Galder Zamarreño > >> Infinispan, Red Hat > >> > >> > On 7 Jun 2017, at 12:02, Galder Zamarreño <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? > >> > -- > >> > Galder Zamarreño > >> > Infinispan, Red Hat > >> > > >> >> On 7 Jun 2017, at 11:50, Sebastian Laskawiec <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 > >> >> [2] https://issues.jboss.org/browse/ISPN-6295 > >> >> [3] https://issues.jboss.org/browse/ISPN-6132 > >> >> [4] https://github.com/infinispan/infinispan/pull/4140/files > >> >> > >> >> > >> >> On Wed, Jun 7, 2017 at 11:19 AM Galder Zamarreño <gal...@redhat.com> > wrote: > >> >> Hi all, > >> >> > >> >> Re: 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 > >> >> > >> > > >> > >> -- > >> SEBASTIAN ŁASKAWIEC > >> INFINISPAN DEVELOPER > >> Red Hat EMEA > >> > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > 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 >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
