I don't yet have an opinion on this dependency that depends on everything, but I've created these two JIRAs which most of us seem to agree on:
* Remove unnecessary provided dependencies which make depending on Infinispan harder. [1] * Uber jars should not be pushed to Maven. Instead they should be treated just like other zip distros that are not pushed. [2] I think we should fix [1] in 9.0.x and [2] can wait to 9.1.x. Cheers, [1] https://issues.jboss.org/browse/ISPN-7930 [2] https://issues.jboss.org/browse/ISPN-7931 -- Galder Zamarreño Infinispan, Red Hat > On 11 Jun 2017, at 20:35, Sanne Grinovero <sa...@infinispan.org> wrote: > > On 9 June 2017 at 16:13, Alan Field <afi...@redhat.com> wrote: >> 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. > > The proposal is to bundle APIs only, but we'll always have tons of > optional (and provided) extension points, e.g. we can't include all > CacheStore(s), not least as many live in separate repositories. > > Similarly, many "experimental modules" might provide additional APIs > which will need to be accessed like the current Query API: *decoupled* > - at least until there's an agreement for inclusion in such an > umbrella API. > This is unavoidable as someone might start working on such a module > without telling us.. incidentally to foster a community of extensions > I'd rather have our own API showcase how it works. > > Also some Java EE APIs - e.g. the JTA API - should never be included; > that's "best practice" in community standards - ugly and we could > complain that Maven could deal better with it, containers could also > deal better with it, but that's how it is. > > So it's an improvement in the API but it's not sorting out the > problems for people not familiar with dependency management. And I > believe that's ok! Just making sure we're agreeing on the goals and > non-goals. > > Considering it's a very minor improvement in usability I'm not sold > about this direction: you'll have ONE MORE JAR and one more layer of > silly indirection to maintain. You might state it's trivial but I > don't believe that, as the definition of which components to include > is necessarily going to be fuild, makign this "API" more prone to wild > changes. > > The one liner to get a reference to the SearchFactory is no big deal > and could be solved better by having CDI and Spring extensions - while > maintaining good decoupling - but if it's the path to convince you all > to take out the uber jars then by all means do it right now ;) > > Thanks, > Sanne > >> >> 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 > > _______________________________________________ > 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
