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