[infinispan-dev] Why JCache embedded has core as provided dependency
Galder Zamarreño
galder at redhat.com
Wed Jun 14 09:34:51 EDT 2017
I don't yet have an opinion on this dependency that depends on everything, but I've created these two JIRAs which most of us seem to agree on:
* Remove unnecessary provided dependencies which make depending on Infinispan harder. [1]
* Uber jars should not be pushed to Maven. Instead they should be treated just like other zip distros that are not pushed. [2]
I think we should fix [1] in 9.0.x and [2] can wait to 9.1.x.
Cheers,
[1] https://issues.jboss.org/browse/ISPN-7930
[2] https://issues.jboss.org/browse/ISPN-7931
--
Galder Zamarreño
Infinispan, Red Hat
> On 11 Jun 2017, at 20:35, Sanne Grinovero <sanne at infinispan.org> wrote:
>
> 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
>
> _______________________________________________
> 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