On Thu, Jun 8, 2017 at 1:07 AM, Sanne Grinovero <sanne(a)infinispan.org>
wrote:
On 7 June 2017 at 16:48, Galder Zamarreño <galder(a)redhat.com>
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)
+1
> * Go through our examples and avoid using uber jar dependencies.
+10
> Then, explore the idea above of not having uber jars as Maven
dependencies.
+100
They are designed for developers on outdated platforms. Let's ship
them exclusively on floppy disks?
We should also stop depending on 3rd party uber-jars, like we do with
netty-all, due to reasons described on [1]
[1]
>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 7 Jun 2017, at 12:23, Sebastian Laskawiec <slaskawi(a)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 <galder(a)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 <galder(a)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
<slaskawi(a)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
<galder(a)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(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