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

Thu Jun 8 07:25:07 EDT 2017

On Thu, Jun 8, 2017 at 1:07 AM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> On 7 June 2017 at 16:48, Galder Zamarreño <galder at 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 <slaskawi at 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 <galder at 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 <galder at 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 <slaskawi at 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 <galder at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170608/0ab5a982/attachment.html 