Or take it one step further, and just get rid of the uber jars. Because there is really only a single benefit to uber jars: save maybe a minute the very first time you start a new project and are using a build system other than maven or similar. And there are a whole bunch of problems they cause.
-Dennis On 06/07/2017 10:48 AM, Galder Zamarreño wrote: > What has changed is that Stéphane has made a very good point which I had not > realised: > > Making core provided dependency means a JCache dependency user needs to add > core dependency on top of that, which reduces usability. Core jar is not a > provided dependency of JCache, it's a normal dependency. I don't think > provided dependencies should be used to get around uber jar dependency issues. > > IMO, the bigger usability issue is the fact that uber jars are available as > Maven dependencies. Uber jars should just not be distributed as Maven > dependencies. They should just be put somewhere else but not in Maven. That'd > way we'd avoid the problem in the first place. > > In the mean time, I think we should: > > * Move back to having normal dependencies for core in JCache (and Spring too, > if it applies) > * Go through our examples and avoid using uber jar dependencies. > > Then, explore the idea above of not having uber jars as Maven dependencies. > > Cheers, > -- > Galder Zamarreño > Infinispan, Red Hat > >> On 7 Jun 2017, at 12:23, Sebastian Laskawiec <slask...@redhat.com> wrote: >> >> We discussed it number of times, including (but probably not limited to): >> • >> http://lists.jboss.org/pipermail/infinispan-dev/2016-February/016414.html >> • http://lists.jboss.org/pipermail/infinispan-dev/2016-March/016490.html >> You might also want to look into the internal lists... >> >> The biggest question - has anything changed? Do we have any other idea? >> >> On Wed, Jun 7, 2017 at 12:05 PM Galder Zamarreño <gal...@redhat.com> wrote: >> Moreover: >> >> * The experience of Maven users should never be penalised by uber jars. Uber >> jar users should be a minority compared with Maven/Gradle...etc users that >> have dependency engines in place to select which components they want to >> depend on. >> >> Cheers, >> -- >> Galder Zamarreño >> Infinispan, Red Hat >> >>> On 7 Jun 2017, at 12:02, Galder Zamarreño <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? >>> -- >>> Galder Zamarreño >>> Infinispan, Red Hat >>> >>>> On 7 Jun 2017, at 11:50, Sebastian Laskawiec <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 >>>> [2] https://issues.jboss.org/browse/ISPN-6295 >>>> [3] https://issues.jboss.org/browse/ISPN-6132 >>>> [4] https://github.com/infinispan/infinispan/pull/4140/files >>>> >>>> >>>> On Wed, Jun 7, 2017 at 11:19 AM Galder Zamarreño <gal...@redhat.com> wrote: >>>> Hi all, >>>> >>>> Re: >>>> 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 >>>> >>> >> >> -- >> SEBASTIAN ŁASKAWIEC >> INFINISPAN DEVELOPER >> Red Hat EMEA >> > > > _______________________________________________ > 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
