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>
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