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

Tristan Tarrant ttarrant at redhat.com
Thu Jun 8 04:05:08 EDT 2017


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 at redhat.com 
> <mailto: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
>     <mailto: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
>     <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
>     <galder at redhat.com <mailto:galder at 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 at lists.jboss.org <mailto:infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat


More information about the infinispan-dev mailing list