Hi Val,
Pretty much, with obvious exceptions being integration modules with other
projects. If the dependency is well isolated, then shading could be
beneficial.
I've also had to do this for client libraries operating inside other
frameworks (I've had to shade netty to avoid conflicting with user
Hi Nick,
Do you suggest to build and deploy uber-jars that has no external
dependencies?
-Val
On Sun, Aug 20, 2017 at 1:02 PM, Nick Pordash wrote:
> If the dependency is not exposed by the public API then another alternative
> is to simply shade the artifact and then this becomes a non-issue f
If the dependency is not exposed by the public API then another alternative
is to simply shade the artifact and then this becomes a non-issue for
users.
Considering Ignite is a platform that executes user code via compute and
service grid I personally think it would be good to minimize the number
Guys,
Keep in mind that some projects can use *older* version of third-party
libraries as well, and dependency upgrade can break them. In other words,
dependency upgrade is in many cases an incompatible change for us, so we
should do this with care.
Unless there is a specific reason to upgrade a
If the third party library is incompatible with the new version and the
old version (such as lucene3.5.0-5.5.2), and the dependent version of
Ignite is older, it may cause conflicts in the user's system.
For such scenarios, I think that updating third-party dependencies's
major version is valuab
Denis,
> I would respond why do we need to update? Some bug, new capabilities,
> security breach? Alexey K., please shed some light on this.
There is no special purpose, I just accidentally found that we are using
very old dependency.
It is common practice (especially in web development (as exam
On Wed, Aug 16, 2017 at 5:26 PM, Denis Magda wrote:
> I would respond why do we need to update? Some bug, new capabilities,
> security breach? Alexey K., please shed some light on this.
>
Actually, now that I think of it, why do we even have that dependency? But
if you do, and upgrading does not
I would respond why do we need to update? Some bug, new capabilities, security
breach? Alexey K., please shed some light on this.
—
Denis
> On Aug 16, 2017, at 5:12 PM, Dmitriy Setrakyan wrote:
>
> On Wed, Aug 16, 2017 at 5:02 PM, Denis Magda wrote:
>
>> Honestly, I wouldn’t touch a dependen
On Wed, Aug 16, 2017 at 5:02 PM, Denis Magda wrote:
> Honestly, I wouldn’t touch a dependency if it works like a charm and
> nobody requested us to migrate to a new version.
>
> Why do you need to update Apache Common coded?
>
Not sure I agree. Why not update it?
>
>
> —
> Denis
>
> > On Aug 1
Honestly, I wouldn’t touch a dependency if it works like a charm and nobody
requested us to migrate to a new version.
Why do you need to update Apache Common coded?
—
Denis
> On Aug 16, 2017, at 10:36 AM, Alexey Kuznetsov wrote:
>
> Done
>
> https://issues.apache.org/jira/browse/IGNITE-6090
Done
https://issues.apache.org/jira/browse/IGNITE-6090
On Wed, Aug 16, 2017 at 8:01 PM, Dmitriy Setrakyan
wrote:
> The answer is Yes, we should update. Jira ticket assigned to the next
> release should be enough in my view.
>
> D.
>
> On Wed, Aug 16, 2017 at 2:38 AM, Alexey Kuznetsov
> wrote:
The answer is Yes, we should update. Jira ticket assigned to the next
release should be enough in my view.
D.
On Wed, Aug 16, 2017 at 2:38 AM, Alexey Kuznetsov
wrote:
> Hi, All!
>
> Do we have any policy for updating third-party dependencies?
>
> For example, I found that we are using very old
Hi, All!
Do we have any policy for updating third-party dependencies?
For example, I found that we are using very old Apache Common codec v.1.6
(released in 2011)
And latest is Apache Common codec v.1.10
Do we need to update to new versions from time to time?
And how?
Just create JIRA issue, u
13 matches
Mail list logo
