I've created a PR [1] that implements the above mentioned changes
(also described in [2]).
I triggered a build on TeamCity, here is the result: [3]. Two test
tasks failed, both due to the removal of ignite-spring-data-2.0-ext
and ignite-spring-data-2.2-ext (which was renamed to just
Hello Roman,
+1 to your suggestion.
If you need any help with a review, please let me know.
On Mon, 18 Apr 2022 at 13:17, Roman Puchkovskiy
wrote:
>
> Hi guys.
>
> This thread has been hanging for quite some time (no pun intended).
> While it was hanging, CVE-2022-22965 [1] was discovered which
Hi guys.
This thread has been hanging for quite some time (no pun intended).
While it was hanging, CVE-2022-22965 [1] was discovered which makes it
extremely dangerous to have vulnerable versions of Spring as
dependencies.
As discussed, ignite-extensions has 3 versions of spring-data
> My proposal is not about creating a separate repository for the spring-data
extension - just left a single module
Yeah, you're correct. I mean that we need a single point of truth for
spring-data - single repository or single module. I'm +1 here.
> So creating some branches to store obsolete
Maksim,
Currently, we have a single repository where all extensions are stored
as separate modules - [1]
My proposal is not about creating a separate repository for the
spring-data extension - just left a single module for the spring-data
extension and proceed with its developments the same
Hi Mikhail,
> remove extension modules that are tied to the specific Spring Data versions
- keep only a single spring-data-ext module. For now, it will contain code
for the latest Ignite Spring Data integration - ignite-spring-data-2.2-ext.
I'm +1 for having a single repository for the
Igniters,
Currently, we have three separate modules for Ignite Spring Data
integrations - [1 - 3]. Each of them depends on the specific version of
the Spring Data - 1.0, 2.0, and 2.2, respectively.
I propose to:
1. remove extension modules that are tied to the specific Spring Data
