[infinispan-dev] Why JCache embedded has core as provided dependency
Sanne Grinovero
sanne at infinispan.org
Sun Jun 11 14:35:51 EDT 2017
On 9 June 2017 at 16:13, Alan Field <afield at 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" <rvansa at redhat.com>
>> To: infinispan-dev at 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" <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
>>
>> _______________________________________________
>> 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
More information about the infinispan-dev
mailing list