[infinispan-dev] Why JCache embedded has core as provided dependency
Alan Field
afield at redhat.com
Fri Jun 9 11:13:05 EDT 2017
I really like this idea. It is similar to one of the solutions hinted at in the Netty issue that Gustavo pointed at. [1] The suggestion there was to replace their current uber jar that contains all of the shaded dependencies with a JAR that just depended on everything. Then you would get the benefit of being able to use a single Maven dependency to pull in all of the JAR files without the issues that shading brings.
Thanks,
Alan
[1] https://github.com/netty/netty/issues/4671
----- Original Message -----
> From: "Radim Vansa" <rvansa at redhat.com>
> To: infinispan-dev at lists.jboss.org
> Sent: Friday, June 9, 2017 3:29:44 AM
> Subject: Re: [infinispan-dev] Why JCache embedded has core as provided dependency
>
> Katia has recently pointed out some usability flaws, and we have
> discussed a central point class that would allow you to explore the API:
> instead of *knowing* about org.infinispan.query.Search or
> org.infinispan.counters. EmbeddedCounterManagerFactory you'd just call
>
> Infinispan ispn = Infinispan.newInstance();
> ispn.search().someQueryMethod(...);
> ispn.counters().someCounterMethod(...);
> ispn.cacheManager().getCache(...);
>
> An umbrella module that would contain this 'discovery API' would need
> all the dependencies, so that would be a perfect replacement for the
> embedded maven artifact. Shouldn't be that much of a work to hack this
> together - how do you think that should be called? infinispan-api (but
> it would be nicer to reserve this if we ever manage to create the
> 'public API' module, with interfaces only), infinispan-facade,
> infinispan-surface? We could even use infinispan-embedded, but that
> would cause some confusion if we distributed infinispan-embedded uberjar
> and infinispan-embedded umbrella artifact.
>
> Radim
>
> On 06/08/2017 08:04 PM, Alan Field wrote:
> > 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 at redhat.com>
> >> To: infinispan-dev at 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 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
> >> _______________________________________________
> >> 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
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
More information about the infinispan-dev
mailing list