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

[Gustavo Fernandes]

On Wed, Jun 7, 2017 at 11:02 AM, 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?
>


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 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
> >
>
>
> _______________________________________________
> 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/20170607/c6b9ed85/attachment-0001.html