[infinispan-dev] Why JCache embedded has core as provided dependency
Radim Vansa
rvansa at redhat.com
Fri Jun 9 03:29:44 EDT 2017
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" <ttarrant at redhat.com>
>> To: infinispan-dev at 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 <galder at redhat.com
>>> <mailto:galder at 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 at redhat.com
>>> <mailto:slaskawi at 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
>>> <galder at redhat.com <mailto:galder at 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 at lists.jboss.org <mailto:infinispan-dev at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team
More information about the infinispan-dev
mailing list