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(a)redhat.com&gt; >> 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 > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev