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" <rva...@redhat.com> > To: infinispan-dev@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" <ttarr...@redhat.com> > >> To: infinispan-dev@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 <gal...@redhat.com > >>> <mailto:gal...@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 <slask...@redhat.com > >>> <mailto:slask...@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 > >>> <gal...@redhat.com <mailto:gal...@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@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@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@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rva...@redhat.com> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
