[infinispan-dev] Why JCache embedded has core as provided dependency

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Why JCache embedded has core as provided dependency

Galder Zamarreño
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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Sebastian Laskawiec
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



On Wed, Jun 7, 2017 at 11:19 AM Galder Zamarreño <[hidden email]> 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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Galder Zamarreño
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 <[hidden email]> 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 <[hidden email]> 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
>


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Galder Zamarreño
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>
>


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Sebastian Laskawiec
We discussed it number of times, including (but probably not limited to):

The biggest question - has anything changed? Do we have any other idea? 

On Wed, Jun 7, 2017 at 12:05 PM Galder Zamarreño <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Gustavo Fernandes-2
In reply to this post by Galder Zamarreño
On Wed, Jun 7, 2017 at 11:02 AM, Galder Zamarreño <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Sanne Grinovero-3
In reply to this post by Galder Zamarreño
On 7 June 2017 at 11:05, Galder Zamarreño <[hidden email]> 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 <[hidden email]> 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?

Memory eviction skills are strong with this team ;)

 - http://lists.jboss.org/pipermail/infinispan-dev/2016-November/017006.html
 - http://lists.jboss.org/pipermail/infinispan-dev/2016-March/016526.html
 - http://lists.jboss.org/pipermail/infinispan-dev/2017-April/017480.html
 - http://lists.jboss.org/pipermail/infinispan-dev/2016-March/016503.html
   -- http://lists.jboss.org/pipermail/infinispan-dev/2016-March/016504.html
 - http://lists.jboss.org/pipermail/infinispan-dev/2015-September/016187.html
 - ...



>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>> On 7 Jun 2017, at 11:50, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Galder Zamarreño
In reply to this post by Sebastian Laskawiec
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)
* Go through our examples and avoid using uber jar dependencies.

Then, explore the idea above of not having uber jars as Maven dependencies.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 7 Jun 2017, at 12:23, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Dennis Reed
Or take it one step further, and just get rid of the uber jars.

Because there is really only a single benefit to uber jars: save maybe a
minute the very first time you start a new project and are using a build
system other than maven or similar.  And there are a whole bunch of
problems they cause.

-Dennis


On 06/07/2017 10:48 AM, Galder Zamarreño 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)
> * Go through our examples and avoid using uber jar dependencies.
>
> Then, explore the idea above of not having uber jars as Maven dependencies.
>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 7 Jun 2017, at 12:23, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Sanne Grinovero-3
In reply to this post by Galder Zamarreño
On 7 June 2017 at 16:48, Galder Zamarreño <[hidden email]> 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?

>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 7 Jun 2017, at 12:23, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Tristan Tarrant-2
In reply to this post by Gustavo Fernandes-2
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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Gustavo Fernandes-2
In reply to this post by Sanne Grinovero-3
On Thu, Jun 8, 2017 at 1:07 AM, Sanne Grinovero <[hidden email]> wrote:
On 7 June 2017 at 16:48, Galder Zamarreño <[hidden email]> 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] https://github.com/netty/netty/issues/4671

Gustavo
 

>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 7 Jun 2017, at 12:23, Sebastian Laskawiec <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Alan Field
In reply to this post by Tristan Tarrant-2
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" <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]
> > <mailto:[hidden email]>> 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 <[hidden email]
> >     <mailto:[hidden email]>> 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
> >     <[hidden email] <mailto:[hidden email]>> 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
> >     [hidden email] <mailto:[hidden email]>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Sebastian Laskawiec
I agree with Alan here. Maven Central is a free "download area", so I wouldn't give it up for free. BTW, what is the point of creating and not shipping them?

I would lean towards to removing them completely or limiting the number of use cases to the minimum e.g. we shouldn't support using infinispan-embedded and jcache; if jcache is essential it should be inside infinispan-embedded; the same for Spring integration modules - either we should put them in uber jars or say that you can use Spring integration with small jars.

On Fri, Jun 9, 2017 at 5:05 AM Alan Field <[hidden email]> 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" <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]
> > <mailto:[hidden email]>> 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 <[hidden email]
> >     <mailto:[hidden email]>> 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
> >     <[hidden email] <mailto:[hidden email]>> 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
> >     [hidden email] <mailto:[hidden email]>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Radim Vansa
In reply to this post by Alan Field
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" <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]
>>> <mailto:[hidden email]>> 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 <[hidden email]
>>>      <mailto:[hidden email]>> 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
>>>      <[hidden email] <mailto:[hidden email]>> 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
>>>      [hidden email] <mailto:[hidden email]>
>>>      https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>      <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Tristan Tarrant-2
In reply to this post by Sebastian Laskawiec
They would be shipped in the zip distributions.

Tristan

On 6/9/17 8:37 AM, Sebastian Laskawiec wrote:

> I agree with Alan here. Maven Central is a free "download area", so I
> wouldn't give it up for free. BTW, what is the point of creating and not
> shipping them?
>
> I would lean towards to removing them completely or limiting the number
> of use cases to the minimum e.g. we shouldn't support using
> infinispan-embedded and jcache; if jcache is essential it should be
> inside infinispan-embedded; the same for Spring integration modules -
> either we should put them in uber jars or say that you can use Spring
> integration with small jars.
>
> On Fri, Jun 9, 2017 at 5:05 AM Alan Field <[hidden email]
> <mailto:[hidden email]>> 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" <[hidden email]
>     <mailto:[hidden email]>>
>      > To: [hidden email]
>     <mailto:[hidden email]>
>      > 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
>     <[hidden email] <mailto:[hidden email]>
>      > > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     <[hidden email] <mailto:[hidden email]>
>      > >     <mailto:[hidden email] <mailto:[hidden email]>>>
>     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
>      > >     <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>> 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
>      > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      > >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>      > >
>      > >
>      > >
>      > >
>      > > _______________________________________________
>      > > infinispan-dev mailing list
>      > > [hidden email]
>     <mailto:[hidden email]>
>      > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      > >
>      >
>      > --
>      > Tristan Tarrant
>      > Infinispan Lead
>      > JBoss, a division of Red Hat
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
>
> SEBASTIANŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red HatEMEA <https://www.redhat.com/>
>
> <https://red.ht/sig>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Tristan Tarrant-2
In reply to this post by Radim Vansa
On 6/9/17 9:29 AM, Radim Vansa wrote:
> 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.
org.infinispan:infinispan

Nothing else.

Tristan

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Alan Field
In reply to this post by Radim Vansa
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.

Thanks,
Alan

[1] https://github.com/netty/netty/issues/4671

----- Original Message -----

> From: "Radim Vansa" <[hidden email]>
> To: [hidden email]
> 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" <[hidden email]>
> >> To: [hidden email]
> >> 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 <[hidden email]
> >>> <mailto:[hidden email]>> 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 <[hidden email]
> >>>      <mailto:[hidden email]>> 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
> >>>      <[hidden email] <mailto:[hidden email]>> 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
> >>>      [hidden email]
> >>>      <mailto:[hidden email]>
> >>>      https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>      <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> [hidden email]
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >> --
> >> Tristan Tarrant
> >> Infinispan Lead
> >> JBoss, a division of Red Hat
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Dennis Reed
In reply to this post by Alan Field
Uber jars were never needed for maven.

Their only purpose is to be able to add a single dependency in other
build systems that don't already have automatic dependency management.

-Dennis


On 06/08/2017 01: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" <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]
>>> <mailto:[hidden email]>> 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 <[hidden email]
>>>     <mailto:[hidden email]>> 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
>>>     <[hidden email] <mailto:[hidden email]>> 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
>>>     [hidden email] <mailto:[hidden email]>
>>>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

Sanne Grinovero-3
In reply to this post by Radim Vansa
On 9 June 2017 at 08:29, Radim Vansa <[hidden email]> wrote:

> 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.

+1 but.. hadn't we already proposed this? I still agree though ;)

>
> 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" <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]
>>>> <mailto:[hidden email]>> 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 <[hidden email]
>>>>      <mailto:[hidden email]>> 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
>>>>      <[hidden email] <mailto:[hidden email]>> 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
>>>>      [hidden email] <mailto:[hidden email]>
>>>>      https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>      <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12
Loading...