Re: Spring 6 support for ignite extensions

[Ilya Korol]

Hi. In general proposal looks good to me, but I agree with Andrey that 
sticking to same *major.minor* is too much.
From my perspective using same major is enough. It still will make it 
easier to understand correlation between spring
and corresponding extension module, meanwhile preserving enough room for 
maneuvering.


For example, what it someone would like to develop some additional 
features in the spring extension module,
in this case we supposed to increase minor version. So I don't see any 
issues with having independent minor versions.



On 28.04.2024 19:50, Nusrat Shakarov wrote:

If we talk about semver(https://semver.org/)
You have the PATCH version for bug fixes.

But I agree, that we may want to make some improvement on the same Spring
version, and then the PATCH version won't be suitable.

If we keep major only, then my suggestion is not very useful(it will be
harder to understand correlation between ext version and spring version).

Maybe we can just upgrade the major version and ignore the spring version.

пт, 26 апр. 2024 г. в 13:46, Andrey Novikov:


  5. New versioning approach. Use the same major and minor for spring
extension as the corresponding spring module is used.

What if we need to fix some bug in the module without changing the
corresponding spring module version? I would prefer independent versioning
from spring, but it is fine to change that major version for the module


On Thu, Apr 25, 2024 at 11:31 PM Nusrat Shakarov
wrote:


Hello everyone.

I've created an epic to implement spring 6 support for ignite extensions.
https://issues.apache.org/jira/browse/IGNITE-22096

Spring 5 support is ending(and has already ended for some modules). And

not

all spring-extensions work correctly in the spring 6 environment.
In the epic, I've described a plan. Key changes are:

1. New pipeline on public tc with JDK 17, because spring 6 baseline is
17.
2. If the current extension doesn't work in spring 6 environment,

update

it to spring 6.
3. If it is necessary, it still will be possible to make changes to

the

previous version(checkout from corresponding release version,
cherry-pick
change and release).
4. Add compatibility test to spring 5 extensions, that should work in
spring 6 environment.
5. New versioning approach. Use the same major and minor for spring
extension as the corresponding spring module is used. For example, If
spring-session-core is updated to 3.2.2, the spring-session-ext

version

should be 3.2.x, where x is the revision number.


Pls, share your thoughts and opinions.
If no one objects, I would like to start implementation.

Re: Spring 6 support for ignite extensions

[Nusrat Shakarov]

If we talk about semver(https://semver.org/)
You have the PATCH version for bug fixes.

But I agree, that we may want to make some improvement on the same Spring
version, and then the PATCH version won't be suitable.

If we keep major only, then my suggestion is not very useful(it will be
harder to understand correlation between ext version and spring version).

Maybe we can just upgrade the major version and ignore the spring version.

пт, 26 апр. 2024 г. в 13:46, Andrey Novikov :

> >
> >  5. New versioning approach. Use the same major and minor for spring
> >extension as the corresponding spring module is used.
>
> What if we need to fix some bug in the module without changing the
> corresponding spring module version? I would prefer independent versioning
> from spring, but it is fine to change that major version for the module
>
>
> On Thu, Apr 25, 2024 at 11:31 PM Nusrat Shakarov 
> wrote:
>
> > Hello everyone.
> >
> > I've created an epic to implement spring 6 support for ignite extensions.
> > https://issues.apache.org/jira/browse/IGNITE-22096
> >
> > Spring 5 support is ending(and has already ended for some modules). And
> not
> > all spring-extensions work correctly in the spring 6 environment.
> > In the epic, I've described a plan. Key changes are:
> >
> >1. New pipeline on public tc with JDK 17, because spring 6 baseline is
> >17.
> >2. If the current extension doesn't work in spring 6 environment,
> update
> >it to spring 6.
> >3. If it is necessary, it still will be possible to make changes to
> the
> >previous version(checkout from corresponding release version,
> > cherry-pick
> >change and release).
> >4. Add compatibility test to spring 5 extensions, that should work in
> >spring 6 environment.
> >5. New versioning approach. Use the same major and minor for spring
> >extension as the corresponding spring module is used. For example, If
> >spring-session-core is updated to 3.2.2, the spring-session-ext
> version
> >should be 3.2.x, where x is the revision number.
> >
> >
> > Pls, share your thoughts and opinions.
> > If no one objects, I would like to start implementation.
> >
>

Re: Spring 6 support for ignite extensions

[Andrey Novikov]

>
>  5. New versioning approach. Use the same major and minor for spring
>extension as the corresponding spring module is used.

What if we need to fix some bug in the module without changing the
corresponding spring module version? I would prefer independent versioning
from spring, but it is fine to change that major version for the module


On Thu, Apr 25, 2024 at 11:31 PM Nusrat Shakarov 
wrote:

> Hello everyone.
>
> I've created an epic to implement spring 6 support for ignite extensions.
> https://issues.apache.org/jira/browse/IGNITE-22096
>
> Spring 5 support is ending(and has already ended for some modules). And not
> all spring-extensions work correctly in the spring 6 environment.
> In the epic, I've described a plan. Key changes are:
>
>1. New pipeline on public tc with JDK 17, because spring 6 baseline is
>17.
>2. If the current extension doesn't work in spring 6 environment, update
>it to spring 6.
>3. If it is necessary, it still will be possible to make changes to the
>previous version(checkout from corresponding release version,
> cherry-pick
>change and release).
>4. Add compatibility test to spring 5 extensions, that should work in
>spring 6 environment.
>5. New versioning approach. Use the same major and minor for spring
>extension as the corresponding spring module is used. For example, If
>spring-session-core is updated to 3.2.2, the spring-session-ext version
>should be 3.2.x, where x is the revision number.
>
>
> Pls, share your thoughts and opinions.
> If no one objects, I would like to start implementation.
>

Spring 6 support for ignite extensions

[Nusrat Shakarov]

Hello everyone.

I've created an epic to implement spring 6 support for ignite extensions.
https://issues.apache.org/jira/browse/IGNITE-22096

Spring 5 support is ending(and has already ended for some modules). And not
all spring-extensions work correctly in the spring 6 environment.
In the epic, I've described a plan. Key changes are:

   1. New pipeline on public tc with JDK 17, because spring 6 baseline is
   17.
   2. If the current extension doesn't work in spring 6 environment, update
   it to spring 6.
   3. If it is necessary, it still will be possible to make changes to the
   previous version(checkout from corresponding release version, cherry-pick
   change and release).
   4. Add compatibility test to spring 5 extensions, that should work in
   spring 6 environment.
   5. New versioning approach. Use the same major and minor for spring
   extension as the corresponding spring module is used. For example, If
   spring-session-core is updated to 3.2.2, the spring-session-ext version
   should be 3.2.x, where x is the revision number.


Pls, share your thoughts and opinions.
If no one objects, I would like to start implementation.

Re: Ignite Extensions

[18624049226]

Due to some fix, the spring-data-ext module also needs to be released.

在 2024/1/23 00:19, Ivan Daschinsky 写道:

Also, I have updated dependencies and fixed native BLAS integration (tested
on ubuntu 22.04 with Intel MKL)

пн, 22 янв. 2024 г. в 19:18, Ivan Daschinsky:


Hi, Steven. Currently I am preparing an initial release of the ML
extension. Just thinking about creating a new thread and here you are :)
The release branch is ready, I just need to prepare artifacts and upload
them to staging. Then I am going to start the vote thread.


https://github.com/apache/ignite-extensions/tree/release/ignite-ml-ext-1.0.0

пн, 22 янв. 2024 г. в 18:15, Stephen Darlington:


Hi all,

With Ignite 2.16 now out, is there any movement towards releasing some of
the Ignite Extensions?

We have a question in the user mailing list about the ML extensions, which
were moved from core to extensions. And I'd like to see the SpringBoot
extensions released so that we can support current versions (3.x does not
work with Ignite out of the box).

Regards,
Stephen



--
Sincerely yours, Ivan Daschinskiy

Re: Ignite Extensions

[Stephen Darlington]

Excellent news! Thanks for the update.

On Mon, 22 Jan 2024 at 16:20, Ivan Daschinsky  wrote:

> Also, I have updated dependencies and fixed native BLAS integration (tested
> on ubuntu 22.04 with Intel MKL)
>
> пн, 22 янв. 2024 г. в 19:18, Ivan Daschinsky :
>
> > Hi, Steven. Currently I am preparing an initial release of the ML
> > extension. Just thinking about creating a new thread and here you are :)
> > The release branch is ready, I just need to prepare artifacts and upload
> > them to staging. Then I am going to start the vote thread.
> >
> >
> >
> https://github.com/apache/ignite-extensions/tree/release/ignite-ml-ext-1.0.0
> >
> > пн, 22 янв. 2024 г. в 18:15, Stephen Darlington  >:
> >
> >> Hi all,
> >>
> >> With Ignite 2.16 now out, is there any movement towards releasing some
> of
> >> the Ignite Extensions?
> >>
> >> We have a question in the user mailing list about the ML extensions,
> which
> >> were moved from core to extensions. And I'd like to see the SpringBoot
> >> extensions released so that we can support current versions (3.x does
> not
> >> work with Ignite out of the box).
> >>
> >> Regards,
> >> Stephen
> >>
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>

Re: Ignite Extensions

[Ivan Daschinsky]

Also, I have updated dependencies and fixed native BLAS integration (tested
on ubuntu 22.04 with Intel MKL)

пн, 22 янв. 2024 г. в 19:18, Ivan Daschinsky :

> Hi, Steven. Currently I am preparing an initial release of the ML
> extension. Just thinking about creating a new thread and here you are :)
> The release branch is ready, I just need to prepare artifacts and upload
> them to staging. Then I am going to start the vote thread.
>
>
> https://github.com/apache/ignite-extensions/tree/release/ignite-ml-ext-1.0.0
>
> пн, 22 янв. 2024 г. в 18:15, Stephen Darlington :
>
>> Hi all,
>>
>> With Ignite 2.16 now out, is there any movement towards releasing some of
>> the Ignite Extensions?
>>
>> We have a question in the user mailing list about the ML extensions, which
>> were moved from core to extensions. And I'd like to see the SpringBoot
>> extensions released so that we can support current versions (3.x does not
>> work with Ignite out of the box).
>>
>> Regards,
>> Stephen
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Ignite Extensions

[Ivan Daschinsky]

Hi, Steven. Currently I am preparing an initial release of the ML
extension. Just thinking about creating a new thread and here you are :)
The release branch is ready, I just need to prepare artifacts and upload
them to staging. Then I am going to start the vote thread.

https://github.com/apache/ignite-extensions/tree/release/ignite-ml-ext-1.0.0

пн, 22 янв. 2024 г. в 18:15, Stephen Darlington :

> Hi all,
>
> With Ignite 2.16 now out, is there any movement towards releasing some of
> the Ignite Extensions?
>
> We have a question in the user mailing list about the ML extensions, which
> were moved from core to extensions. And I'd like to see the SpringBoot
> extensions released so that we can support current versions (3.x does not
> work with Ignite out of the box).
>
> Regards,
> Stephen
>


-- 
Sincerely yours, Ivan Daschinskiy

Ignite Extensions

[Stephen Darlington]

Hi all,

With Ignite 2.16 now out, is there any movement towards releasing some of
the Ignite Extensions?

We have a question in the user mailing list about the ML extensions, which
were moved from core to extensions. And I'd like to see the SpringBoot
extensions released so that we can support current versions (3.x does not
work with Ignite out of the box).

Regards,
Stephen

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Ilya Kasnacheev]

Hello!

Can you arrange that?

Regards,
-- 
Ilya Kasnacheev


чт, 19 мая 2022 г. в 09:20, Maxim Muzafarov :

> Ilya,
>
> Should we start a formal vote about the ignite-schedule deletion?
>
> On Mon, 16 May 2022 at 14:28, Ilya Kasnacheev 
> wrote:
> >
> > Hello!
> >
> > In my opinion, the ignite-schedule module needs to be dropped - it has
> bad
> > API, outdated GPL dependency and in general is out of focus of Ignite.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :
> >
> > > Folks,
> > >
> > > I've found that the following modules are rarely used and haven't been
> > > change for a few years, but  they are released each time Ignite being
> > > released. It seems we can safely move all of them to the Extensions
> > > project.
> > >
> > > The list:
> > > - ignite-yarn
> > > - ignite-geospatial
> > > - ignite-schedule
> > >
> > > WDYT?
> > >
>

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Maxim Muzafarov]

Folks,

Let's extend a bit the list of modules for moving to the Ignite Extensions.

The list:

- ignite-yarn
- ignite-geospatial
- ignite-mesos
- ignite-cloud
- ignite-osgi*
- ignite-schedule (deletion proposed)

On Thu, 19 May 2022 at 09:20, Maxim Muzafarov  wrote:
>
> Ilya,
>
> Should we start a formal vote about the ignite-schedule deletion?
>
> On Mon, 16 May 2022 at 14:28, Ilya Kasnacheev  
> wrote:
> >
> > Hello!
> >
> > In my opinion, the ignite-schedule module needs to be dropped - it has bad
> > API, outdated GPL dependency and in general is out of focus of Ignite.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :
> >
> > > Folks,
> > >
> > > I've found that the following modules are rarely used and haven't been
> > > change for a few years, but  they are released each time Ignite being
> > > released. It seems we can safely move all of them to the Extensions
> > > project.
> > >
> > > The list:
> > > - ignite-yarn
> > > - ignite-geospatial
> > > - ignite-schedule
> > >
> > > WDYT?
> > >

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Maxim Muzafarov]

Ilya,

Should we start a formal vote about the ignite-schedule deletion?

On Mon, 16 May 2022 at 14:28, Ilya Kasnacheev  wrote:
>
> Hello!
>
> In my opinion, the ignite-schedule module needs to be dropped - it has bad
> API, outdated GPL dependency and in general is out of focus of Ignite.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :
>
> > Folks,
> >
> > I've found that the following modules are rarely used and haven't been
> > change for a few years, but  they are released each time Ignite being
> > released. It seems we can safely move all of them to the Extensions
> > project.
> >
> > The list:
> > - ignite-yarn
> > - ignite-geospatial
> > - ignite-schedule
> >
> > WDYT?
> >

[ANNOUNCE] Apache Ignite Extensions Released

[Maxim Muzafarov]

The Apache Ignite Community is pleased to announce the release of
the following Apache Ignite Extensions:
- Ignite AWS Extension 1.0.0
- Ignite Azure Extension 1.0.0
- Ignite GCE Extension 1.0.0
- Ignite Spring Data Extension 2.0.0
- Ignite Spring Session Extension 1.0.0
- Ignite Zookeeper Ip Finder Extension 1.0.0

Apache Ignite® is a Distributed Database For High-Performance
Computing With In-Memory Speed.
https://ignite.apache.org

Download the latest Ignite Extensions version from here:
https://ignite.apache.org/download.cgi

Please let us know if you encounter any problems:
https://ignite.apache.org/community/resources.html#ask


Regards,
Maxim Muzafarov on behalf of the Apache Ignite community.

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Ilya Kasnacheev]

Hello!

In my opinion, the ignite-schedule module needs to be dropped - it has bad
API, outdated GPL dependency and in general is out of focus of Ignite.

Regards,
-- 
Ilya Kasnacheev


пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :

> Folks,
>
> I've found that the following modules are rarely used and haven't been
> change for a few years, but  they are released each time Ignite being
> released. It seems we can safely move all of them to the Extensions
> project.
>
> The list:
> - ignite-yarn
> - ignite-geospatial
> - ignite-schedule
>
> WDYT?
>

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[18624049226]

ignite-mesos?

在 2022/5/13 22:51, Maxim Muzafarov 写道:

Folks,

I've found that the following modules are rarely used and haven't been
change for a few years, but  they are released each time Ignite being
released. It seems we can safely move all of them to the Extensions
project.

The list:
- ignite-yarn
- ignite-geospatial
- ignite-schedule

WDYT?

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Николай Ижиков]

+1

> 13 мая 2022 г., в 17:51, Maxim Muzafarov  написал(а):
> 
> Folks,
> 
> I've found that the following modules are rarely used and haven't been
> change for a few years, but  they are released each time Ignite being
> released. It seems we can safely move all of them to the Extensions
> project.
> 
> The list:
> - ignite-yarn
> - ignite-geospatial
> - ignite-schedule
> 
> WDYT?

[DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Maxim Muzafarov]

Folks,

I've found that the following modules are rarely used and haven't been
change for a few years, but  they are released each time Ignite being
released. It seems we can safely move all of them to the Extensions
project.

The list:
- ignite-yarn
- ignite-geospatial
- ignite-schedule

WDYT?

Re: [DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Maxim Muzafarov]

Folks,

I've moved the hibernate modules to the Ignite Extension project,
however, we can't deploy them to the Maven Central since they have the
LGPL dependencies. This is also mentioned in the documentation [1].
Users must build them manually from the sources to use.

Another problem I've faced with - there is a lot of manual work to
include required extension to the Ignite binary distribution (e.g.
build an extension, copy libs etc.). We should provide an ability to
build and prepare the Ignite binary distribution with the extension we
need. The same way as the dependencies-apache-ignite-lgpl.xml does.
I've created an issue for that [2].


[1] https://ignite.apache.org/docs/latest/setup#enabling-modules
[2] https://issues.apache.org/jira/browse/IGNITE-16981

On Thu, 28 Apr 2022 at 15:43, Maxim Muzafarov  wrote:
>
> Folks,
>
> I've created a task:
> https://issues.apache.org/jira/browse/IGNITE-16908
>
> On Tue, 26 Apr 2022 at 23:16, Nikita Amelchev  wrote:
> >
> > +1
> >
> > вт, 26 апр. 2022 г. в 17:22, Anton Vinogradov :
> > >
> > > +1
> > >
> > > On Tue, Apr 26, 2022 at 4:45 PM Николай Ижиков  
> > > wrote:
> > >
> > > > +1
> > > >
> > > > > 26 апр. 2022 г., в 16:24, Maxim Muzafarov 
> > > > написал(а):
> > > > >
> > > > > Hello Igniters,
> > > > >
> > > > >
> > > > > Currently we have a batch of ignite-hibernate modules which provide
> > > > > Hibernate second-level cache (L2 cache) implementation based on the
> > > > > Apache Ignite for different version of hibernate.
> > > > >
> > > > > The following list of modules we have:
> > > > > - ignite-hibernate_4.2
> > > > > - ignite-hibernate_5.1
> > > > > - ignite-hibernate_5.3
> > > > > - ignite-hibernate-core (a common part for all hibernate modules)
> > > > >
> > > > > I propose to use the same approach as was used for the
> > > > > ignite-spring-data module [1] and move all these modules to the Ignite
> > > > > Extesions project.
> > > > >
> > > > > In details:
> > > > >
> > > > > - remove all these modules from the Ignite project.
> > > > > - create ignite-hibernate extension.
> > > > > - move ignite-hibernate-core + ignite-hibernate_4.2 to
> > > > > release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
> > > > > extension will be 4.2.0) and release it on demand;
> > > > > - move ignite-hibernate-core + ignite-hibernate_5.1 to
> > > > > release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
> > > > > extension will be 5.1.0) and release it on demand;
> > > > > - move ignite-hibernate-core + ignite-hibernate_5.3 to the master
> > > > > branch and to the release/ignite-hibernate-5.3.0 branch (the version
> > > > > of ignite-hibernate extension will be 5.3.0) and release it
> > > > > immediately;
> > > > >
> > > > >
> > > > > Is it OK or am I missing something?
> > > > > WDYT?
> > > > >
> > > > >
> > > > > [1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7
> > > >
> > > >
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita

Re: [DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Maxim Muzafarov]

Folks,

I've created a task:
https://issues.apache.org/jira/browse/IGNITE-16908

On Tue, 26 Apr 2022 at 23:16, Nikita Amelchev  wrote:
>
> +1
>
> вт, 26 апр. 2022 г. в 17:22, Anton Vinogradov :
> >
> > +1
> >
> > On Tue, Apr 26, 2022 at 4:45 PM Николай Ижиков  wrote:
> >
> > > +1
> > >
> > > > 26 апр. 2022 г., в 16:24, Maxim Muzafarov 
> > > написал(а):
> > > >
> > > > Hello Igniters,
> > > >
> > > >
> > > > Currently we have a batch of ignite-hibernate modules which provide
> > > > Hibernate second-level cache (L2 cache) implementation based on the
> > > > Apache Ignite for different version of hibernate.
> > > >
> > > > The following list of modules we have:
> > > > - ignite-hibernate_4.2
> > > > - ignite-hibernate_5.1
> > > > - ignite-hibernate_5.3
> > > > - ignite-hibernate-core (a common part for all hibernate modules)
> > > >
> > > > I propose to use the same approach as was used for the
> > > > ignite-spring-data module [1] and move all these modules to the Ignite
> > > > Extesions project.
> > > >
> > > > In details:
> > > >
> > > > - remove all these modules from the Ignite project.
> > > > - create ignite-hibernate extension.
> > > > - move ignite-hibernate-core + ignite-hibernate_4.2 to
> > > > release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
> > > > extension will be 4.2.0) and release it on demand;
> > > > - move ignite-hibernate-core + ignite-hibernate_5.1 to
> > > > release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
> > > > extension will be 5.1.0) and release it on demand;
> > > > - move ignite-hibernate-core + ignite-hibernate_5.3 to the master
> > > > branch and to the release/ignite-hibernate-5.3.0 branch (the version
> > > > of ignite-hibernate extension will be 5.3.0) and release it
> > > > immediately;
> > > >
> > > >
> > > > Is it OK or am I missing something?
> > > > WDYT?
> > > >
> > > >
> > > > [1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7
> > >
> > >
>
>
>
> --
> Best wishes,
> Amelchev Nikita

Re: [DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Nikita Amelchev]

+1

вт, 26 апр. 2022 г. в 17:22, Anton Vinogradov :
>
> +1
>
> On Tue, Apr 26, 2022 at 4:45 PM Николай Ижиков  wrote:
>
> > +1
> >
> > > 26 апр. 2022 г., в 16:24, Maxim Muzafarov 
> > написал(а):
> > >
> > > Hello Igniters,
> > >
> > >
> > > Currently we have a batch of ignite-hibernate modules which provide
> > > Hibernate second-level cache (L2 cache) implementation based on the
> > > Apache Ignite for different version of hibernate.
> > >
> > > The following list of modules we have:
> > > - ignite-hibernate_4.2
> > > - ignite-hibernate_5.1
> > > - ignite-hibernate_5.3
> > > - ignite-hibernate-core (a common part for all hibernate modules)
> > >
> > > I propose to use the same approach as was used for the
> > > ignite-spring-data module [1] and move all these modules to the Ignite
> > > Extesions project.
> > >
> > > In details:
> > >
> > > - remove all these modules from the Ignite project.
> > > - create ignite-hibernate extension.
> > > - move ignite-hibernate-core + ignite-hibernate_4.2 to
> > > release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
> > > extension will be 4.2.0) and release it on demand;
> > > - move ignite-hibernate-core + ignite-hibernate_5.1 to
> > > release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
> > > extension will be 5.1.0) and release it on demand;
> > > - move ignite-hibernate-core + ignite-hibernate_5.3 to the master
> > > branch and to the release/ignite-hibernate-5.3.0 branch (the version
> > > of ignite-hibernate extension will be 5.3.0) and release it
> > > immediately;
> > >
> > >
> > > Is it OK or am I missing something?
> > > WDYT?
> > >
> > >
> > > [1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7
> >
> >



-- 
Best wishes,
Amelchev Nikita

Re: [DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Anton Vinogradov]

+1

On Tue, Apr 26, 2022 at 4:45 PM Николай Ижиков  wrote:

> +1
>
> > 26 апр. 2022 г., в 16:24, Maxim Muzafarov 
> написал(а):
> >
> > Hello Igniters,
> >
> >
> > Currently we have a batch of ignite-hibernate modules which provide
> > Hibernate second-level cache (L2 cache) implementation based on the
> > Apache Ignite for different version of hibernate.
> >
> > The following list of modules we have:
> > - ignite-hibernate_4.2
> > - ignite-hibernate_5.1
> > - ignite-hibernate_5.3
> > - ignite-hibernate-core (a common part for all hibernate modules)
> >
> > I propose to use the same approach as was used for the
> > ignite-spring-data module [1] and move all these modules to the Ignite
> > Extesions project.
> >
> > In details:
> >
> > - remove all these modules from the Ignite project.
> > - create ignite-hibernate extension.
> > - move ignite-hibernate-core + ignite-hibernate_4.2 to
> > release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
> > extension will be 4.2.0) and release it on demand;
> > - move ignite-hibernate-core + ignite-hibernate_5.1 to
> > release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
> > extension will be 5.1.0) and release it on demand;
> > - move ignite-hibernate-core + ignite-hibernate_5.3 to the master
> > branch and to the release/ignite-hibernate-5.3.0 branch (the version
> > of ignite-hibernate extension will be 5.3.0) and release it
> > immediately;
> >
> >
> > Is it OK or am I missing something?
> > WDYT?
> >
> >
> > [1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7
>
>

Re: [DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Николай Ижиков]

+1

> 26 апр. 2022 г., в 16:24, Maxim Muzafarov  написал(а):
> 
> Hello Igniters,
> 
> 
> Currently we have a batch of ignite-hibernate modules which provide
> Hibernate second-level cache (L2 cache) implementation based on the
> Apache Ignite for different version of hibernate.
> 
> The following list of modules we have:
> - ignite-hibernate_4.2
> - ignite-hibernate_5.1
> - ignite-hibernate_5.3
> - ignite-hibernate-core (a common part for all hibernate modules)
> 
> I propose to use the same approach as was used for the
> ignite-spring-data module [1] and move all these modules to the Ignite
> Extesions project.
> 
> In details:
> 
> - remove all these modules from the Ignite project.
> - create ignite-hibernate extension.
> - move ignite-hibernate-core + ignite-hibernate_4.2 to
> release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
> extension will be 4.2.0) and release it on demand;
> - move ignite-hibernate-core + ignite-hibernate_5.1 to
> release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
> extension will be 5.1.0) and release it on demand;
> - move ignite-hibernate-core + ignite-hibernate_5.3 to the master
> branch and to the release/ignite-hibernate-5.3.0 branch (the version
> of ignite-hibernate extension will be 5.3.0) and release it
> immediately;
> 
> 
> Is it OK or am I missing something?
> WDYT?
> 
> 
> [1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7

[DISCUSSION] Move ignite-hibernate modules to the Ignite Extensions

[Maxim Muzafarov]

Hello Igniters,


Currently we have a batch of ignite-hibernate modules which provide
Hibernate second-level cache (L2 cache) implementation based on the
Apache Ignite for different version of hibernate.

The following list of modules we have:
- ignite-hibernate_4.2
- ignite-hibernate_5.1
- ignite-hibernate_5.3
- ignite-hibernate-core (a common part for all hibernate modules)

I propose to use the same approach as was used for the
ignite-spring-data module [1] and move all these modules to the Ignite
Extesions project.

In details:

- remove all these modules from the Ignite project.
- create ignite-hibernate extension.
- move ignite-hibernate-core + ignite-hibernate_4.2 to
release/ignite-hibernate-4.2.0 branch (the version of ignite-hibernate
extension will be 4.2.0) and release it on demand;
- move ignite-hibernate-core + ignite-hibernate_5.1 to
release/ignite-hibernate-5.1.0 branch (the version of ignite-hibernate
extension will be 5.1.0) and release it on demand;
- move ignite-hibernate-core + ignite-hibernate_5.3 to the master
branch and to the release/ignite-hibernate-5.3.0 branch (the version
of ignite-hibernate extension will be 5.3.0) and release it
immediately;


Is it OK or am I missing something?
WDYT?


[1] https://lists.apache.org/thread/b03bny7xj9x5ty371srtdn9ysd72qht7

RE: Re: Move Azure, AWS, GCE to the ignite-extensions

[Stanislav Borisychev]

Thank you it will very help us

> Hello Stephen,
>
> I'm planning to release the extensions soon. Tests are OK, however,
> some TC Suites still need to be configured.
>
> On Wed, 26 Jan 2022 at 21:07, Stephen Darlington
>  wrote:
> >
> > Do we know what happened with this thread? I just saw a question in the 
> > user list asking about where the ignite-aws-ext module is now that Ignite 
> > 2.12 is out.
> >
> > Regards,
> > Stephen
> >

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Hello Stephen,

I'm planning to release the extensions soon. Tests are OK, however,
some TC Suites still need to be configured.

On Wed, 26 Jan 2022 at 21:07, Stephen Darlington
 wrote:
>
> Do we know what happened with this thread? I just saw a question in the user 
> list asking about where the ignite-aws-ext module is now that Ignite 2.12 is 
> out.
>
> Regards,
> Stephen
>
> > On 24 Nov 2021, at 11:11, Maxim Muzafarov  wrote:
> >
> > Petr,
> >
> > There is only the GCE suite left to be configured. I've created an
> > issue [1] to do this. Please, take a look.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-15981
> >
> > On Wed, 24 Nov 2021 at 12:00, Petr Ivanov  wrote:
> >>
> >> Hi, Maksim.
> >>
> >>
> >> Can you file a ticket about recreating test suites for extensions, please?
> >> I will attend to it in nearest time.
> >>
> >>
> >>> On 23 Nov 2021, at 17:14, Maxim Muzafarov  wrote:
> >>>
> >>> Hello Petr,
> >>>
> >>> Can you assist me with configuring the GCE [1] suite on the TC
> >>> Extensions project? Currently, I have an issue with moving environment
> >>> variables from the old GCE suite [2] to the new one.
> >>>
> >>> I need to create the following envs:
> >>> - env.test.gce.account.id
> >>> - env.test.gce.p12.path
> >>> - env.test.gce.project.name
> >>>
> >>> However the `id` seems to be a password, so it's hidden on the admin
> >>> panel. Can you please help me with this?
> >>>
> >>> [1] 
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Gce_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
> >>> [2] 
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_GceOld_IgniteTests24Java8=ignite-2.12=buildTypeStatusDiv
> >>>
> >>> On Mon, 25 Oct 2021 at 14:22, Maxim Muzafarov  wrote:
> >>>>
> >>>> Folks,
> >>>>
> >>>> I've moved the azure, gce, aws modules to the ignite-extensions project.
> >>>> https://issues.apache.org/jira/browse/IGNITE-15541
> >>>>
> >>>> Building the modules in the ignite-extension project will prepare an
> >>>> appropriate release zip file containing all the necessary
> >>>> dependencies:
> >>>> - ignite-aws-ext.zip
> >>>> - ignite-gce-ext.zip
> >>>> - ignite-auzre-ext.zip
> >>>>
> >>>>
> >>>> On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
> >>>>  wrote:
> >>>>>
> >>>>> Okay, I phrased that badly. I mean an extra platform-specific ZIP file 
> >>>>> that I used to augment the generic Ignite ZIP file.
> >>>>>
> >>>>> So, to run on Azure I’d download ignite.zip + azure.zip.
> >>>>>
> >>>>> Extending ignite.sh would also be great, kind of like what’s happening 
> >>>>> with Ignite 3 as far as I can tell.
> >>>>>
> >>>>> What I’m advocating is not needing to use Maven just to run Ignite on 
> >>>>> Azure, AWS, etc.
> >>>>>
> >>>>>> On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
> >>>>>>
> >>>>>> Our self-contained zip file currently is over 400Mb and continues to 
> >>>>>> grow.
> >>>>>> Even considering that internet speeds has grown too, it is nonsense to 
> >>>>>> force user to download such an archive where 90% are useless for most 
> >>>>>> cases.
> >>>>>>
> >>>>>> Also we can:
> >>>>>> — pack all extensions in single binary with latests releases (and 
> >>>>>> update after each extension release) or even one by one
> >>>>>> — extend ignite.sh to download remote libs when extension is activated 
> >>>>>> via command line
> >>>>>>
> >>>>>>
> >>>>>> Antoine de Saint-Exupéry once said that 'perfection is achieved, not 
> >>>>>> when there is nothing more to add, but when there is nothing left to 
> >>>>>> take away'.
> >>>>>> We are not obliged to make Apache Ignite ideal, but we certainly can 
> >>>>>> move that way — I am sure 

Re: Move Azure, AWS, GCE to the ignite-extensions

[Stephen Darlington]

Do we know what happened with this thread? I just saw a question in the user 
list asking about where the ignite-aws-ext module is now that Ignite 2.12 is 
out.

Regards,
Stephen

> On 24 Nov 2021, at 11:11, Maxim Muzafarov  wrote:
> 
> Petr,
> 
> There is only the GCE suite left to be configured. I've created an
> issue [1] to do this. Please, take a look.
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-15981
> 
> On Wed, 24 Nov 2021 at 12:00, Petr Ivanov  wrote:
>> 
>> Hi, Maksim.
>> 
>> 
>> Can you file a ticket about recreating test suites for extensions, please?
>> I will attend to it in nearest time.
>> 
>> 
>>> On 23 Nov 2021, at 17:14, Maxim Muzafarov  wrote:
>>> 
>>> Hello Petr,
>>> 
>>> Can you assist me with configuring the GCE [1] suite on the TC
>>> Extensions project? Currently, I have an issue with moving environment
>>> variables from the old GCE suite [2] to the new one.
>>> 
>>> I need to create the following envs:
>>> - env.test.gce.account.id
>>> - env.test.gce.p12.path
>>> - env.test.gce.project.name
>>> 
>>> However the `id` seems to be a password, so it's hidden on the admin
>>> panel. Can you please help me with this?
>>> 
>>> [1] 
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Gce_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
>>> [2] 
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_GceOld_IgniteTests24Java8=ignite-2.12=buildTypeStatusDiv
>>> 
>>> On Mon, 25 Oct 2021 at 14:22, Maxim Muzafarov  wrote:
>>>> 
>>>> Folks,
>>>> 
>>>> I've moved the azure, gce, aws modules to the ignite-extensions project.
>>>> https://issues.apache.org/jira/browse/IGNITE-15541
>>>> 
>>>> Building the modules in the ignite-extension project will prepare an
>>>> appropriate release zip file containing all the necessary
>>>> dependencies:
>>>> - ignite-aws-ext.zip
>>>> - ignite-gce-ext.zip
>>>> - ignite-auzre-ext.zip
>>>> 
>>>> 
>>>> On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
>>>>  wrote:
>>>>> 
>>>>> Okay, I phrased that badly. I mean an extra platform-specific ZIP file 
>>>>> that I used to augment the generic Ignite ZIP file.
>>>>> 
>>>>> So, to run on Azure I’d download ignite.zip + azure.zip.
>>>>> 
>>>>> Extending ignite.sh would also be great, kind of like what’s happening 
>>>>> with Ignite 3 as far as I can tell.
>>>>> 
>>>>> What I’m advocating is not needing to use Maven just to run Ignite on 
>>>>> Azure, AWS, etc.
>>>>> 
>>>>>> On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
>>>>>> 
>>>>>> Our self-contained zip file currently is over 400Mb and continues to 
>>>>>> grow.
>>>>>> Even considering that internet speeds has grown too, it is nonsense to 
>>>>>> force user to download such an archive where 90% are useless for most 
>>>>>> cases.
>>>>>> 
>>>>>> Also we can:
>>>>>> — pack all extensions in single binary with latests releases (and update 
>>>>>> after each extension release) or even one by one
>>>>>> — extend ignite.sh to download remote libs when extension is activated 
>>>>>> via command line
>>>>>> 
>>>>>> 
>>>>>> Antoine de Saint-Exupéry once said that 'perfection is achieved, not 
>>>>>> when there is nothing more to add, but when there is nothing left to 
>>>>>> take away'.
>>>>>> We are not obliged to make Apache Ignite ideal, but we certainly can 
>>>>>> move that way — I am sure the result will exceed expectations.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 13 Oct 2021, at 16:02, Stephen Darlington 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Having extensions in Maven Central makes perfect sense for tools that 
>>>>>>> need to be built and integrated with other code, Spring integrations 
>>>>>>> for example.
>>>>>>> 
>>>>>>> That’s not the case for extensions that are required just to run 
>>&g

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Ilya Kasnacheev]

Hello!

OK, I'm retracting my claim then. IP-finder may indeed be moved to
extensions.

Regards,
-- 
Ilya Kasnacheev


ср, 22 дек. 2021 г. в 14:00, Ivan Daschinsky :

> >> a lot of code in core code base is dedicated for enabling it.
> It is simply not true. ZookeeperDiscovery has nothing common with
> ZookeeperIpFinder.
>
> The last one is simply one class and similar to others IP finders.
>
> ср, 22 дек. 2021 г. в 13:25, Ilya Kasnacheev :
>
> > Hello!
> >
> > I think it might not be a good idea, since Zookeeper IP Finder is not
> > stand-alone - a lot of code in core code base is dedicated for enabling
> it.
> > This code may break unnoticed if Zookeeper IP Finder is not built/tested
> on
> > every commit.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 22 дек. 2021 г. в 12:09, Sergei Ryzhov :
> >
> > > Hi, igniters,
> > >
> > > I've created an issue [1] to move the zookeeper IP-finder to the
> > > ignite-extensions. The motivation is the same as with migration of
> > > cloud-based IP-finders - to remove integration dependency of the
> > > release cycle on Ignite releases. Also, the log4j dependency with
> > > vulnerabilities (needed for Apache Curator) will be removed from the
> > Ignite
> > > release.
> > >
> > > Any objections?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-16182
> > > --
> > > Best regards,
> > > Sergei Ryzhov
> > >
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Ivan Daschinsky]

Let's explain more thoroughly

Ignite module ignite-zookeeper contains 2 packages

1. org.apache.ignite.spi.discovery.tcp.ipfinder.zk;

It contains one class, TcpDiscoveryZookeeperIpFinder, that is just
implementation of TcpDiscoveryIpFinder, it uses Apache Curator
ServiceDiscovery recipe to
register and retrieve IP addresses of other nodes and use these addresses
in TcpDiscovery process. It is literally few hundred lines of code with
comments and imports.

2. org.apache.ignite.spi.discovery.zk
It contains full blown implementation of DiscoverySpi. Quite complex and a
lot of code.

These two packages have nothing common except substring "zookeeper". I
don't have any idea why they are present in one package.


ср, 22 дек. 2021 г. в 14:00, Ivan Daschinsky :

> I am +1 for removing ZookeeperIpFinder from ignite-zookeeper module. It is
> not needed here.
>
> ср, 22 дек. 2021 г. в 14:00, Ivan Daschinsky :
>
>> >> a lot of code in core code base is dedicated for enabling it.
>> It is simply not true. ZookeeperDiscovery has nothing common with
>> ZookeeperIpFinder.
>>
>> The last one is simply one class and similar to others IP finders.
>>
>> ср, 22 дек. 2021 г. в 13:25, Ilya Kasnacheev :
>>
>>> Hello!
>>>
>>> I think it might not be a good idea, since Zookeeper IP Finder is not
>>> stand-alone - a lot of code in core code base is dedicated for enabling
>>> it.
>>> This code may break unnoticed if Zookeeper IP Finder is not built/tested
>>> on
>>> every commit.
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> ср, 22 дек. 2021 г. в 12:09, Sergei Ryzhov :
>>>
>>> > Hi, igniters,
>>> >
>>> > I've created an issue [1] to move the zookeeper IP-finder to the
>>> > ignite-extensions. The motivation is the same as with migration of
>>> > cloud-based IP-finders - to remove integration dependency of the
>>> > release cycle on Ignite releases. Also, the log4j dependency with
>>> > vulnerabilities (needed for Apache Curator) will be removed from the
>>> Ignite
>>> > release.
>>> >
>>> > Any objections?
>>> >
>>> > [1] https://issues.apache.org/jira/browse/IGNITE-16182
>>> > --
>>> > Best regards,
>>> > Sergei Ryzhov
>>> >
>>>
>>
>>
>> --
>> Sincerely yours, Ivan Daschinskiy
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Ivan Daschinsky]

I am +1 for removing ZookeeperIpFinder from ignite-zookeeper module. It is
not needed here.

ср, 22 дек. 2021 г. в 14:00, Ivan Daschinsky :

> >> a lot of code in core code base is dedicated for enabling it.
> It is simply not true. ZookeeperDiscovery has nothing common with
> ZookeeperIpFinder.
>
> The last one is simply one class and similar to others IP finders.
>
> ср, 22 дек. 2021 г. в 13:25, Ilya Kasnacheev :
>
>> Hello!
>>
>> I think it might not be a good idea, since Zookeeper IP Finder is not
>> stand-alone - a lot of code in core code base is dedicated for enabling
>> it.
>> This code may break unnoticed if Zookeeper IP Finder is not built/tested
>> on
>> every commit.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> ср, 22 дек. 2021 г. в 12:09, Sergei Ryzhov :
>>
>> > Hi, igniters,
>> >
>> > I've created an issue [1] to move the zookeeper IP-finder to the
>> > ignite-extensions. The motivation is the same as with migration of
>> > cloud-based IP-finders - to remove integration dependency of the
>> > release cycle on Ignite releases. Also, the log4j dependency with
>> > vulnerabilities (needed for Apache Curator) will be removed from the
>> Ignite
>> > release.
>> >
>> > Any objections?
>> >
>> > [1] https://issues.apache.org/jira/browse/IGNITE-16182
>> > --
>> > Best regards,
>> > Sergei Ryzhov
>> >
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Ivan Daschinsky]

>> a lot of code in core code base is dedicated for enabling it.
It is simply not true. ZookeeperDiscovery has nothing common with
ZookeeperIpFinder.

The last one is simply one class and similar to others IP finders.

ср, 22 дек. 2021 г. в 13:25, Ilya Kasnacheev :

> Hello!
>
> I think it might not be a good idea, since Zookeeper IP Finder is not
> stand-alone - a lot of code in core code base is dedicated for enabling it.
> This code may break unnoticed if Zookeeper IP Finder is not built/tested on
> every commit.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 22 дек. 2021 г. в 12:09, Sergei Ryzhov :
>
> > Hi, igniters,
> >
> > I've created an issue [1] to move the zookeeper IP-finder to the
> > ignite-extensions. The motivation is the same as with migration of
> > cloud-based IP-finders - to remove integration dependency of the
> > release cycle on Ignite releases. Also, the log4j dependency with
> > vulnerabilities (needed for Apache Curator) will be removed from the
> Ignite
> > release.
> >
> > Any objections?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-16182
> > --
> > Best regards,
> > Sergei Ryzhov
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Ilya Kasnacheev]

Hello!

I think it might not be a good idea, since Zookeeper IP Finder is not
stand-alone - a lot of code in core code base is dedicated for enabling it.
This code may break unnoticed if Zookeeper IP Finder is not built/tested on
every commit.

Regards,
-- 
Ilya Kasnacheev


ср, 22 дек. 2021 г. в 12:09, Sergei Ryzhov :

> Hi, igniters,
>
> I've created an issue [1] to move the zookeeper IP-finder to the
> ignite-extensions. The motivation is the same as with migration of
> cloud-based IP-finders - to remove integration dependency of the
> release cycle on Ignite releases. Also, the log4j dependency with
> vulnerabilities (needed for Apache Curator) will be removed from the Ignite
> release.
>
> Any objections?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-16182
> --
> Best regards,
> Sergei Ryzhov
>

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Anton Vinogradov]

Sergei,

Please make sure this will not break the Ducktests.
AFAIK, we have zookeeper tests there.

On Wed, Dec 22, 2021 at 12:09 PM Sergei Ryzhov 
wrote:

> Hi, igniters,
>
> I've created an issue [1] to move the zookeeper IP-finder to the
> ignite-extensions. The motivation is the same as with migration of
> cloud-based IP-finders - to remove integration dependency of the
> release cycle on Ignite releases. Also, the log4j dependency with
> vulnerabilities (needed for Apache Curator) will be removed from the Ignite
> release.
>
> Any objections?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-16182
> --
> Best regards,
> Sergei Ryzhov
>

Move the Zookeeper IP-finder to the ignite-extensions

[Sergei Ryzhov]

Hi, igniters,

I've created an issue [1] to move the zookeeper IP-finder to the
ignite-extensions. The motivation is the same as with migration of
cloud-based IP-finders - to remove integration dependency of the
release cycle on Ignite releases. Also, the log4j dependency with
vulnerabilities (needed for Apache Curator) will be removed from the Ignite
release.

Any objections?

[1] https://issues.apache.org/jira/browse/IGNITE-16182
-- 
Best regards,
Sergei Ryzhov

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Petr,

There is only the GCE suite left to be configured. I've created an
issue [1] to do this. Please, take a look.

[1] https://issues.apache.org/jira/browse/IGNITE-15981

On Wed, 24 Nov 2021 at 12:00, Petr Ivanov  wrote:
>
> Hi, Maksim.
>
>
> Can you file a ticket about recreating test suites for extensions, please?
> I will attend to it in nearest time.
>
>
> > On 23 Nov 2021, at 17:14, Maxim Muzafarov  wrote:
> >
> > Hello Petr,
> >
> > Can you assist me with configuring the GCE [1] suite on the TC
> > Extensions project? Currently, I have an issue with moving environment
> > variables from the old GCE suite [2] to the new one.
> >
> > I need to create the following envs:
> > - env.test.gce.account.id
> > - env.test.gce.p12.path
> > - env.test.gce.project.name
> >
> > However the `id` seems to be a password, so it's hidden on the admin
> > panel. Can you please help me with this?
> >
> > [1] 
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Gce_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
> > [2] 
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_GceOld_IgniteTests24Java8=ignite-2.12=buildTypeStatusDiv
> >
> > On Mon, 25 Oct 2021 at 14:22, Maxim Muzafarov  wrote:
> >>
> >> Folks,
> >>
> >> I've moved the azure, gce, aws modules to the ignite-extensions project.
> >> https://issues.apache.org/jira/browse/IGNITE-15541
> >>
> >> Building the modules in the ignite-extension project will prepare an
> >> appropriate release zip file containing all the necessary
> >> dependencies:
> >> - ignite-aws-ext.zip
> >> - ignite-gce-ext.zip
> >> - ignite-auzre-ext.zip
> >>
> >>
> >> On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
> >>  wrote:
> >>>
> >>> Okay, I phrased that badly. I mean an extra platform-specific ZIP file 
> >>> that I used to augment the generic Ignite ZIP file.
> >>>
> >>> So, to run on Azure I’d download ignite.zip + azure.zip.
> >>>
> >>> Extending ignite.sh would also be great, kind of like what’s happening 
> >>> with Ignite 3 as far as I can tell.
> >>>
> >>> What I’m advocating is not needing to use Maven just to run Ignite on 
> >>> Azure, AWS, etc.
> >>>
> >>>> On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
> >>>>
> >>>> Our self-contained zip file currently is over 400Mb and continues to 
> >>>> grow.
> >>>> Even considering that internet speeds has grown too, it is nonsense to 
> >>>> force user to download such an archive where 90% are useless for most 
> >>>> cases.
> >>>>
> >>>> Also we can:
> >>>> — pack all extensions in single binary with latests releases (and update 
> >>>> after each extension release) or even one by one
> >>>> — extend ignite.sh to download remote libs when extension is activated 
> >>>> via command line
> >>>>
> >>>>
> >>>> Antoine de Saint-Exupéry once said that 'perfection is achieved, not 
> >>>> when there is nothing more to add, but when there is nothing left to 
> >>>> take away'.
> >>>> We are not obliged to make Apache Ignite ideal, but we certainly can 
> >>>> move that way — I am sure the result will exceed expectations.
> >>>>
> >>>>
> >>>>
> >>>>> On 13 Oct 2021, at 16:02, Stephen Darlington 
> >>>>>  wrote:
> >>>>>
> >>>>> Having extensions in Maven Central makes perfect sense for tools that 
> >>>>> need to be built and integrated with other code, Spring integrations 
> >>>>> for example.
> >>>>>
> >>>>> That’s not the case for extensions that are required just to run 
> >>>>> Ignite. A self-contained zip file for each platform would work.
> >>>>>
> >>>>>> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
> >>>>>>
> >>>>>> Nikolay,
> >>>>>>
> >>>>>> All extensions will be available at the maven central for download.
> >>>>>>
> >>>>>> Previously extensions have a dependent version on the ignite core, so
> >>>>>> each time the Ignite was released it made sense

Re: Move Azure, AWS, GCE to the ignite-extensions

[Petr Ivanov]

Hi, Maksim.


Can you file a ticket about recreating test suites for extensions, please?
I will attend to it in nearest time.


> On 23 Nov 2021, at 17:14, Maxim Muzafarov  wrote:
> 
> Hello Petr,
> 
> Can you assist me with configuring the GCE [1] suite on the TC
> Extensions project? Currently, I have an issue with moving environment
> variables from the old GCE suite [2] to the new one.
> 
> I need to create the following envs:
> - env.test.gce.account.id
> - env.test.gce.p12.path
> - env.test.gce.project.name
> 
> However the `id` seems to be a password, so it's hidden on the admin
> panel. Can you please help me with this?
> 
> [1] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Gce_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
> [2] 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_GceOld_IgniteTests24Java8=ignite-2.12=buildTypeStatusDiv
> 
> On Mon, 25 Oct 2021 at 14:22, Maxim Muzafarov  wrote:
>> 
>> Folks,
>> 
>> I've moved the azure, gce, aws modules to the ignite-extensions project.
>> https://issues.apache.org/jira/browse/IGNITE-15541
>> 
>> Building the modules in the ignite-extension project will prepare an
>> appropriate release zip file containing all the necessary
>> dependencies:
>> - ignite-aws-ext.zip
>> - ignite-gce-ext.zip
>> - ignite-auzre-ext.zip
>> 
>> 
>> On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
>>  wrote:
>>> 
>>> Okay, I phrased that badly. I mean an extra platform-specific ZIP file that 
>>> I used to augment the generic Ignite ZIP file.
>>> 
>>> So, to run on Azure I’d download ignite.zip + azure.zip.
>>> 
>>> Extending ignite.sh would also be great, kind of like what’s happening with 
>>> Ignite 3 as far as I can tell.
>>> 
>>> What I’m advocating is not needing to use Maven just to run Ignite on 
>>> Azure, AWS, etc.
>>> 
>>>> On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
>>>> 
>>>> Our self-contained zip file currently is over 400Mb and continues to grow.
>>>> Even considering that internet speeds has grown too, it is nonsense to 
>>>> force user to download such an archive where 90% are useless for most 
>>>> cases.
>>>> 
>>>> Also we can:
>>>> — pack all extensions in single binary with latests releases (and update 
>>>> after each extension release) or even one by one
>>>> — extend ignite.sh to download remote libs when extension is activated via 
>>>> command line
>>>> 
>>>> 
>>>> Antoine de Saint-Exupéry once said that 'perfection is achieved, not when 
>>>> there is nothing more to add, but when there is nothing left to take away'.
>>>> We are not obliged to make Apache Ignite ideal, but we certainly can move 
>>>> that way — I am sure the result will exceed expectations.
>>>> 
>>>> 
>>>> 
>>>>> On 13 Oct 2021, at 16:02, Stephen Darlington 
>>>>>  wrote:
>>>>> 
>>>>> Having extensions in Maven Central makes perfect sense for tools that 
>>>>> need to be built and integrated with other code, Spring integrations for 
>>>>> example.
>>>>> 
>>>>> That’s not the case for extensions that are required just to run Ignite. 
>>>>> A self-contained zip file for each platform would work.
>>>>> 
>>>>>> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
>>>>>> 
>>>>>> Nikolay,
>>>>>> 
>>>>>> All extensions will be available at the maven central for download.
>>>>>> 
>>>>>> Previously extensions have a dependent version on the ignite core, so
>>>>>> each time the Ignite was released it made sense to include all the
>>>>>> extensions into the uber-zip file. Each extension has its own release
>>>>>> version now, so an extension can be upgraded and used independently,
>>>>>> what is the reason include it in the single uber-zip file? Probably it
>>>>>> would be better to provide a self-contained zip file for each cloud
>>>>>> platform.
>>>>>> 
>>>>>> If I've missed your issue, so can you clarify the problem in more detail?
>>>>>> 
>>>>>> On Wed, 13 Oct 2021 at 14:37, Nikolay Izhikov  
>>>>>> wrote:
>>>>>>

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Hello Petr,

Can you assist me with configuring the GCE [1] suite on the TC
Extensions project? Currently, I have an issue with moving environment
variables from the old GCE suite [2] to the new one.

I need to create the following envs:
- env.test.gce.account.id
- env.test.gce.p12.path
- env.test.gce.project.name

However the `id` seems to be a password, so it's hidden on the admin
panel. Can you please help me with this?

[1] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Gce_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
[2] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_GceOld_IgniteTests24Java8=ignite-2.12=buildTypeStatusDiv

On Mon, 25 Oct 2021 at 14:22, Maxim Muzafarov  wrote:
>
> Folks,
>
> I've moved the azure, gce, aws modules to the ignite-extensions project.
> https://issues.apache.org/jira/browse/IGNITE-15541
>
> Building the modules in the ignite-extension project will prepare an
> appropriate release zip file containing all the necessary
> dependencies:
> - ignite-aws-ext.zip
> - ignite-gce-ext.zip
> - ignite-auzre-ext.zip
>
>
> On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
>  wrote:
> >
> > Okay, I phrased that badly. I mean an extra platform-specific ZIP file that 
> > I used to augment the generic Ignite ZIP file.
> >
> > So, to run on Azure I’d download ignite.zip + azure.zip.
> >
> > Extending ignite.sh would also be great, kind of like what’s happening with 
> > Ignite 3 as far as I can tell.
> >
> > What I’m advocating is not needing to use Maven just to run Ignite on 
> > Azure, AWS, etc.
> >
> > > On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
> > >
> > > Our self-contained zip file currently is over 400Mb and continues to grow.
> > > Even considering that internet speeds has grown too, it is nonsense to 
> > > force user to download such an archive where 90% are useless for most 
> > > cases.
> > >
> > > Also we can:
> > > — pack all extensions in single binary with latests releases (and update 
> > > after each extension release) or even one by one
> > > — extend ignite.sh to download remote libs when extension is activated 
> > > via command line
> > >
> > >
> > > Antoine de Saint-Exupéry once said that 'perfection is achieved, not when 
> > > there is nothing more to add, but when there is nothing left to take 
> > > away'.
> > > We are not obliged to make Apache Ignite ideal, but we certainly can move 
> > > that way — I am sure the result will exceed expectations.
> > >
> > >
> > >
> > >> On 13 Oct 2021, at 16:02, Stephen Darlington 
> > >>  wrote:
> > >>
> > >> Having extensions in Maven Central makes perfect sense for tools that 
> > >> need to be built and integrated with other code, Spring integrations for 
> > >> example.
> > >>
> > >> That’s not the case for extensions that are required just to run Ignite. 
> > >> A self-contained zip file for each platform would work.
> > >>
> > >>> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
> > >>>
> > >>> Nikolay,
> > >>>
> > >>> All extensions will be available at the maven central for download.
> > >>>
> > >>> Previously extensions have a dependent version on the ignite core, so
> > >>> each time the Ignite was released it made sense to include all the
> > >>> extensions into the uber-zip file. Each extension has its own release
> > >>> version now, so an extension can be upgraded and used independently,
> > >>> what is the reason include it in the single uber-zip file? Probably it
> > >>> would be better to provide a self-contained zip file for each cloud
> > >>> platform.
> > >>>
> > >>> If I've missed your issue, so can you clarify the problem in more 
> > >>> detail?
> > >>>
> > >>> On Wed, 13 Oct 2021 at 14:37, Nikolay Izhikov  
> > >>> wrote:
> > >>>>
> > >>>> Maxim.
> > >>>>
> > >>>>> Currently, they are copied from the optional
> > >>>>> directory of the ignite binary package but would be copied from an
> > >>>>> appropriate ignite extension binary package.
> > >>>>
> > >>>> But how, the user will download this binary package?
> > >>>> Right now, all the user need 

Re: [DISCUSS] Release spring-tx-ext and spring-cache-ext Ignite extensions

[Nikita Amelchev]

Igniters,

The spring-tx and spring-cache extensions are ready to be released.

I have created the release branch: `ignite-spring-tx-cache-ext-1.0`.

The updated documentation: spring-tx [1], spring-cache [2].

I will prepare the release candidate at the nearest time.

[1] 
https://github.com/apache/ignite/blob/master/docs/_docs/extensions-and-integrations/spring/spring-tx.adoc
[2] 
https://github.com/apache/ignite/blob/master/docs/_docs/extensions-and-integrations/spring/spring-caching.adoc

вт, 5 окт. 2021 г. в 13:48, Nikolay Izhikov :
>
> +1
>
> > 5 окт. 2021 г., в 11:48, Nikita Amelchev  написал(а):
> >
> > Folks, we should release the spring-data-commons module with the 1.1.0
> > version to release spring-tx, spring-cache modules.
> > It contains some proxies required for the new modules.
> >
> > I suggest:
> >
> > 1. Release the spring-data-commons 1.1.0, spring-tx 1.0.0,
> > spring-cache 1.0.0 modules with separate source packages:
> >
> > /ignite/ignite-extensions/ignite-spring-data-commons/1.1.0/[src]
> > /ignite/ignite-extensions/ignite-spring-tx-ext/1.0.0/[src]
> > /ignite/ignite-extensions/ignite-spring-cache-ext/1.0.0/[src]
> >
> > (The spring-data-commons 1.0.0 was included in the
> > ignite-spring-data-all-ext/1.0.0 source package)
> >
> > 2. Use one voting thread for this activity.
> >
> > Any objections?
> >
> > пт, 24 сент. 2021 г. в 15:14, Nikita Amelchev :
> >>
> >> Igniters,
> >>
> >> Since Ignite 2.11 has been released the following extension modules
> >> can be released too:
> >>
> >> spring-cache-ext
> >> spring-tx-ext
> >>
> >> I want to be a release manager for these if nobody minds.
> >>
> >> The release process can be started after checking documentation.
> >>
> >> --
> >> Best wishes,
> >> Amelchev Nikita
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
>


-- 
Best wishes,
Amelchev Nikita

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Folks,

I've moved the azure, gce, aws modules to the ignite-extensions project.
https://issues.apache.org/jira/browse/IGNITE-15541

Building the modules in the ignite-extension project will prepare an
appropriate release zip file containing all the necessary
dependencies:
- ignite-aws-ext.zip
- ignite-gce-ext.zip
- ignite-auzre-ext.zip


On Wed, 13 Oct 2021 at 17:09, Stephen Darlington
 wrote:
>
> Okay, I phrased that badly. I mean an extra platform-specific ZIP file that I 
> used to augment the generic Ignite ZIP file.
>
> So, to run on Azure I’d download ignite.zip + azure.zip.
>
> Extending ignite.sh would also be great, kind of like what’s happening with 
> Ignite 3 as far as I can tell.
>
> What I’m advocating is not needing to use Maven just to run Ignite on Azure, 
> AWS, etc.
>
> > On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
> >
> > Our self-contained zip file currently is over 400Mb and continues to grow.
> > Even considering that internet speeds has grown too, it is nonsense to 
> > force user to download such an archive where 90% are useless for most cases.
> >
> > Also we can:
> > — pack all extensions in single binary with latests releases (and update 
> > after each extension release) or even one by one
> > — extend ignite.sh to download remote libs when extension is activated via 
> > command line
> >
> >
> > Antoine de Saint-Exupéry once said that 'perfection is achieved, not when 
> > there is nothing more to add, but when there is nothing left to take away'.
> > We are not obliged to make Apache Ignite ideal, but we certainly can move 
> > that way — I am sure the result will exceed expectations.
> >
> >
> >
> >> On 13 Oct 2021, at 16:02, Stephen Darlington 
> >>  wrote:
> >>
> >> Having extensions in Maven Central makes perfect sense for tools that need 
> >> to be built and integrated with other code, Spring integrations for 
> >> example.
> >>
> >> That’s not the case for extensions that are required just to run Ignite. A 
> >> self-contained zip file for each platform would work.
> >>
> >>> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
> >>>
> >>> Nikolay,
> >>>
> >>> All extensions will be available at the maven central for download.
> >>>
> >>> Previously extensions have a dependent version on the ignite core, so
> >>> each time the Ignite was released it made sense to include all the
> >>> extensions into the uber-zip file. Each extension has its own release
> >>> version now, so an extension can be upgraded and used independently,
> >>> what is the reason include it in the single uber-zip file? Probably it
> >>> would be better to provide a self-contained zip file for each cloud
> >>> platform.
> >>>
> >>> If I've missed your issue, so can you clarify the problem in more detail?
> >>>
> >>> On Wed, 13 Oct 2021 at 14:37, Nikolay Izhikov  wrote:
> >>>>
> >>>> Maxim.
> >>>>
> >>>>> Currently, they are copied from the optional
> >>>>> directory of the ignite binary package but would be copied from an
> >>>>> appropriate ignite extension binary package.
> >>>>
> >>>> But how, the user will download this binary package?
> >>>> Right now, all the user need is Ignite distributive.
> >>>>
> >>>>
> >>>>> 13 окт. 2021 г., в 14:32, Maxim Muzafarov  
> >>>>> написал(а):
> >>>>>
> >>>>> Stephen,
> >>>>>
> >>>>> I guess the required classes of IP-finders should be in the classpath
> >>>>> (libs directory). Currently, they are copied from the optional
> >>>>> directory of the ignite binary package but would be copied from an
> >>>>> appropriate ignite extension binary package. Probably I'm missing
> >>>>> something but almost nothing changes in that process from my point of
> >>>>> view. The documentation pages will be updated prior to the release.
> >>>>>
> >>>>> On Wed, 13 Oct 2021 at 13:44, Stephen Darlington
> >>>>>  wrote:
> >>>>>>
> >>>>>> I understand the motivation from a development point of view, but how 
> >>>>>> will this work for end users? Currently, the documentation talks about 
> >>>>>> extensions only in ter

Re: Move Azure, AWS, GCE to the ignite-extensions

[Stephen Darlington]

Okay, I phrased that badly. I mean an extra platform-specific ZIP file that I 
used to augment the generic Ignite ZIP file.

So, to run on Azure I’d download ignite.zip + azure.zip.

Extending ignite.sh would also be great, kind of like what’s happening with 
Ignite 3 as far as I can tell.

What I’m advocating is not needing to use Maven just to run Ignite on Azure, 
AWS, etc.

> On 13 Oct 2021, at 14:35, Petr Ivanov  wrote:
> 
> Our self-contained zip file currently is over 400Mb and continues to grow.
> Even considering that internet speeds has grown too, it is nonsense to force 
> user to download such an archive where 90% are useless for most cases.
> 
> Also we can:
> — pack all extensions in single binary with latests releases (and update 
> after each extension release) or even one by one
> — extend ignite.sh to download remote libs when extension is activated via 
> command line
> 
> 
> Antoine de Saint-Exupéry once said that 'perfection is achieved, not when 
> there is nothing more to add, but when there is nothing left to take away'.
> We are not obliged to make Apache Ignite ideal, but we certainly can move 
> that way — I am sure the result will exceed expectations.
> 
> 
> 
>> On 13 Oct 2021, at 16:02, Stephen Darlington 
>>  wrote:
>> 
>> Having extensions in Maven Central makes perfect sense for tools that need 
>> to be built and integrated with other code, Spring integrations for example.
>> 
>> That’s not the case for extensions that are required just to run Ignite. A 
>> self-contained zip file for each platform would work.
>> 
>>> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
>>> 
>>> Nikolay,
>>> 
>>> All extensions will be available at the maven central for download.
>>> 
>>> Previously extensions have a dependent version on the ignite core, so
>>> each time the Ignite was released it made sense to include all the
>>> extensions into the uber-zip file. Each extension has its own release
>>> version now, so an extension can be upgraded and used independently,
>>> what is the reason include it in the single uber-zip file? Probably it
>>> would be better to provide a self-contained zip file for each cloud
>>> platform.
>>> 
>>> If I've missed your issue, so can you clarify the problem in more detail?
>>> 
>>> On Wed, 13 Oct 2021 at 14:37, Nikolay Izhikov  wrote:
>>>> 
>>>> Maxim.
>>>> 
>>>>> Currently, they are copied from the optional
>>>>> directory of the ignite binary package but would be copied from an
>>>>> appropriate ignite extension binary package.
>>>> 
>>>> But how, the user will download this binary package?
>>>> Right now, all the user need is Ignite distributive.
>>>> 
>>>> 
>>>>> 13 окт. 2021 г., в 14:32, Maxim Muzafarov  написал(а):
>>>>> 
>>>>> Stephen,
>>>>> 
>>>>> I guess the required classes of IP-finders should be in the classpath
>>>>> (libs directory). Currently, they are copied from the optional
>>>>> directory of the ignite binary package but would be copied from an
>>>>> appropriate ignite extension binary package. Probably I'm missing
>>>>> something but almost nothing changes in that process from my point of
>>>>> view. The documentation pages will be updated prior to the release.
>>>>> 
>>>>> On Wed, 13 Oct 2021 at 13:44, Stephen Darlington
>>>>>  wrote:
>>>>>> 
>>>>>> I understand the motivation from a development point of view, but how 
>>>>>> will this work for end users? Currently, the documentation talks about 
>>>>>> extensions only in terms of importing maven dependencies (download.cgi 
>>>>>> <https://ignite.apache.org/download.cgi#extensions>). If I’m trying to 
>>>>>> start a cluster on Azure, how does that work? Do I need to build my own 
>>>>>> server?
>>>>>> 
>>>>>> Regards,
>>>>>> Stephen
>>>>>> 
>>>>>>> On 13 Oct 2021, at 11:35, Nikita Amelchev  wrote:
>>>>>>> 
>>>>>>> +1 to migrate and include to the Ignite 2.12 scope
>>>>>>> 
>>>>>>> пн, 20 сент. 2021 г. в 17:09, Denis Magda :
>>>>>>>> 
>>>>>>>> Perfect, thanks, Maxim!
>>>>>>>> 
>>>>>>>> -
>>>>>>>> Denis
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Folks,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I've created an issue [1] to move all cloud-based IP-finders to the
>>>>>>>>> ignite-extensions. The motivation is the same as with migration of
>>>>>>>>> Spring Data integration - to remove integration dependency of the
>>>>>>>>> release cycle on Ignite releases.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-15541
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Best wishes,
>>>>>>> Amelchev Nikita
>>>>>> 
>>>>>> 
>>>> 
>> 
>> 
> 

Re: Move Azure, AWS, GCE to the ignite-extensions

[Petr Ivanov]

Our self-contained zip file currently is over 400Mb and continues to grow.
Even considering that internet speeds has grown too, it is nonsense to force 
user to download such an archive where 90% are useless for most cases.

Also we can:
 — pack all extensions in single binary with latests releases (and update after 
each extension release) or even one by one
 — extend ignite.sh to download remote libs when extension is activated via 
command line


Antoine de Saint-Exupéry once said that 'perfection is achieved, not when there 
is nothing more to add, but when there is nothing left to take away'.
We are not obliged to make Apache Ignite ideal, but we certainly can move that 
way — I am sure the result will exceed expectations.



> On 13 Oct 2021, at 16:02, Stephen Darlington 
>  wrote:
> 
> Having extensions in Maven Central makes perfect sense for tools that need to 
> be built and integrated with other code, Spring integrations for example.
> 
> That’s not the case for extensions that are required just to run Ignite. A 
> self-contained zip file for each platform would work.
> 
>> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
>> 
>> Nikolay,
>> 
>> All extensions will be available at the maven central for download.
>> 
>> Previously extensions have a dependent version on the ignite core, so
>> each time the Ignite was released it made sense to include all the
>> extensions into the uber-zip file. Each extension has its own release
>> version now, so an extension can be upgraded and used independently,
>> what is the reason include it in the single uber-zip file? Probably it
>> would be better to provide a self-contained zip file for each cloud
>> platform.
>> 
>> If I've missed your issue, so can you clarify the problem in more detail?
>> 
>> On Wed, 13 Oct 2021 at 14:37, Nikolay Izhikov  wrote:
>>> 
>>> Maxim.
>>> 
>>>> Currently, they are copied from the optional
>>>> directory of the ignite binary package but would be copied from an
>>>> appropriate ignite extension binary package.
>>> 
>>> But how, the user will download this binary package?
>>> Right now, all the user need is Ignite distributive.
>>> 
>>> 
>>>> 13 окт. 2021 г., в 14:32, Maxim Muzafarov  написал(а):
>>>> 
>>>> Stephen,
>>>> 
>>>> I guess the required classes of IP-finders should be in the classpath
>>>> (libs directory). Currently, they are copied from the optional
>>>> directory of the ignite binary package but would be copied from an
>>>> appropriate ignite extension binary package. Probably I'm missing
>>>> something but almost nothing changes in that process from my point of
>>>> view. The documentation pages will be updated prior to the release.
>>>> 
>>>> On Wed, 13 Oct 2021 at 13:44, Stephen Darlington
>>>>  wrote:
>>>>> 
>>>>> I understand the motivation from a development point of view, but how 
>>>>> will this work for end users? Currently, the documentation talks about 
>>>>> extensions only in terms of importing maven dependencies (download.cgi 
>>>>> <https://ignite.apache.org/download.cgi#extensions>). If I’m trying to 
>>>>> start a cluster on Azure, how does that work? Do I need to build my own 
>>>>> server?
>>>>> 
>>>>> Regards,
>>>>> Stephen
>>>>> 
>>>>>> On 13 Oct 2021, at 11:35, Nikita Amelchev  wrote:
>>>>>> 
>>>>>> +1 to migrate and include to the Ignite 2.12 scope
>>>>>> 
>>>>>> пн, 20 сент. 2021 г. в 17:09, Denis Magda :
>>>>>>> 
>>>>>>> Perfect, thanks, Maxim!
>>>>>>> 
>>>>>>> -
>>>>>>> Denis
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Folks,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I've created an issue [1] to move all cloud-based IP-finders to the
>>>>>>>> ignite-extensions. The motivation is the same as with migration of
>>>>>>>> Spring Data integration - to remove integration dependency of the
>>>>>>>> release cycle on Ignite releases.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-15541
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Best wishes,
>>>>>> Amelchev Nikita
>>>>> 
>>>>> 
>>> 
> 
> 

Re: Move Azure, AWS, GCE to the ignite-extensions

[Stephen Darlington]

Having extensions in Maven Central makes perfect sense for tools that need to 
be built and integrated with other code, Spring integrations for example.

That’s not the case for extensions that are required just to run Ignite. A 
self-contained zip file for each platform would work.

> On 13 Oct 2021, at 13:41, Maxim Muzafarov  wrote:
> 
> Nikolay,
> 
> All extensions will be available at the maven central for download.
> 
> Previously extensions have a dependent version on the ignite core, so
> each time the Ignite was released it made sense to include all the
> extensions into the uber-zip file. Each extension has its own release
> version now, so an extension can be upgraded and used independently,
> what is the reason include it in the single uber-zip file? Probably it
> would be better to provide a self-contained zip file for each cloud
> platform.
> 
> If I've missed your issue, so can you clarify the problem in more detail?
> 
> On Wed, 13 Oct 2021 at 14:37, Nikolay Izhikov  wrote:
>> 
>> Maxim.
>> 
>>> Currently, they are copied from the optional
>>> directory of the ignite binary package but would be copied from an
>>> appropriate ignite extension binary package.
>> 
>> But how, the user will download this binary package?
>> Right now, all the user need is Ignite distributive.
>> 
>> 
>>> 13 окт. 2021 г., в 14:32, Maxim Muzafarov  написал(а):
>>> 
>>> Stephen,
>>> 
>>> I guess the required classes of IP-finders should be in the classpath
>>> (libs directory). Currently, they are copied from the optional
>>> directory of the ignite binary package but would be copied from an
>>> appropriate ignite extension binary package. Probably I'm missing
>>> something but almost nothing changes in that process from my point of
>>> view. The documentation pages will be updated prior to the release.
>>> 
>>> On Wed, 13 Oct 2021 at 13:44, Stephen Darlington
>>>  wrote:
>>>> 
>>>> I understand the motivation from a development point of view, but how will 
>>>> this work for end users? Currently, the documentation talks about 
>>>> extensions only in terms of importing maven dependencies (download.cgi 
>>>> <https://ignite.apache.org/download.cgi#extensions>). If I’m trying to 
>>>> start a cluster on Azure, how does that work? Do I need to build my own 
>>>> server?
>>>> 
>>>> Regards,
>>>> Stephen
>>>> 
>>>>> On 13 Oct 2021, at 11:35, Nikita Amelchev  wrote:
>>>>> 
>>>>> +1 to migrate and include to the Ignite 2.12 scope
>>>>> 
>>>>> пн, 20 сент. 2021 г. в 17:09, Denis Magda :
>>>>>> 
>>>>>> Perfect, thanks, Maxim!
>>>>>> 
>>>>>> -
>>>>>> Denis
>>>>>> 
>>>>>> 
>>>>>> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  
>>>>>> wrote:
>>>>>> 
>>>>>>> Folks,
>>>>>>> 
>>>>>>> 
>>>>>>> I've created an issue [1] to move all cloud-based IP-finders to the
>>>>>>> ignite-extensions. The motivation is the same as with migration of
>>>>>>> Spring Data integration - to remove integration dependency of the
>>>>>>> release cycle on Ignite releases.
>>>>>>> 
>>>>>>> 
>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-15541
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best wishes,
>>>>> Amelchev Nikita
>>>> 
>>>> 
>> 

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Nikolay,

All extensions will be available at the maven central for download.

Previously extensions have a dependent version on the ignite core, so
each time the Ignite was released it made sense to include all the
extensions into the uber-zip file. Each extension has its own release
version now, so an extension can be upgraded and used independently,
what is the reason include it in the single uber-zip file? Probably it
would be better to provide a self-contained zip file for each cloud
platform.

If I've missed your issue, so can you clarify the problem in more detail?

On Wed, 13 Oct 2021 at 14:37, Nikolay Izhikov  wrote:
>
> Maxim.
>
> > Currently, they are copied from the optional
> > directory of the ignite binary package but would be copied from an
> > appropriate ignite extension binary package.
>
> But how, the user will download this binary package?
> Right now, all the user need is Ignite distributive.
>
>
> > 13 окт. 2021 г., в 14:32, Maxim Muzafarov  написал(а):
> >
> > Stephen,
> >
> > I guess the required classes of IP-finders should be in the classpath
> > (libs directory). Currently, they are copied from the optional
> > directory of the ignite binary package but would be copied from an
> > appropriate ignite extension binary package. Probably I'm missing
> > something but almost nothing changes in that process from my point of
> > view. The documentation pages will be updated prior to the release.
> >
> > On Wed, 13 Oct 2021 at 13:44, Stephen Darlington
> >  wrote:
> >>
> >> I understand the motivation from a development point of view, but how will 
> >> this work for end users? Currently, the documentation talks about 
> >> extensions only in terms of importing maven dependencies (download.cgi 
> >> <https://ignite.apache.org/download.cgi#extensions>). If I’m trying to 
> >> start a cluster on Azure, how does that work? Do I need to build my own 
> >> server?
> >>
> >> Regards,
> >> Stephen
> >>
> >>> On 13 Oct 2021, at 11:35, Nikita Amelchev  wrote:
> >>>
> >>> +1 to migrate and include to the Ignite 2.12 scope
> >>>
> >>> пн, 20 сент. 2021 г. в 17:09, Denis Magda :
> >>>>
> >>>> Perfect, thanks, Maxim!
> >>>>
> >>>> -
> >>>> Denis
> >>>>
> >>>>
> >>>> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  
> >>>> wrote:
> >>>>
> >>>>> Folks,
> >>>>>
> >>>>>
> >>>>> I've created an issue [1] to move all cloud-based IP-finders to the
> >>>>> ignite-extensions. The motivation is the same as with migration of
> >>>>> Spring Data integration - to remove integration dependency of the
> >>>>> release cycle on Ignite releases.
> >>>>>
> >>>>>
> >>>>> [1] https://issues.apache.org/jira/browse/IGNITE-15541
> >>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best wishes,
> >>> Amelchev Nikita
> >>
> >>
>

Re: Move Azure, AWS, GCE to the ignite-extensions

[Nikolay Izhikov]

Maxim.

> Currently, they are copied from the optional
> directory of the ignite binary package but would be copied from an
> appropriate ignite extension binary package.

But how, the user will download this binary package?
Right now, all the user need is Ignite distributive.


> 13 окт. 2021 г., в 14:32, Maxim Muzafarov  написал(а):
> 
> Stephen,
> 
> I guess the required classes of IP-finders should be in the classpath
> (libs directory). Currently, they are copied from the optional
> directory of the ignite binary package but would be copied from an
> appropriate ignite extension binary package. Probably I'm missing
> something but almost nothing changes in that process from my point of
> view. The documentation pages will be updated prior to the release.
> 
> On Wed, 13 Oct 2021 at 13:44, Stephen Darlington
>  wrote:
>> 
>> I understand the motivation from a development point of view, but how will 
>> this work for end users? Currently, the documentation talks about extensions 
>> only in terms of importing maven dependencies (download.cgi 
>> <https://ignite.apache.org/download.cgi#extensions>). If I’m trying to start 
>> a cluster on Azure, how does that work? Do I need to build my own server?
>> 
>> Regards,
>> Stephen
>> 
>>> On 13 Oct 2021, at 11:35, Nikita Amelchev  wrote:
>>> 
>>> +1 to migrate and include to the Ignite 2.12 scope
>>> 
>>> пн, 20 сент. 2021 г. в 17:09, Denis Magda :
>>>> 
>>>> Perfect, thanks, Maxim!
>>>> 
>>>> -
>>>> Denis
>>>> 
>>>> 
>>>> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  wrote:
>>>> 
>>>>> Folks,
>>>>> 
>>>>> 
>>>>> I've created an issue [1] to move all cloud-based IP-finders to the
>>>>> ignite-extensions. The motivation is the same as with migration of
>>>>> Spring Data integration - to remove integration dependency of the
>>>>> release cycle on Ignite releases.
>>>>> 
>>>>> 
>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-15541
>>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Best wishes,
>>> Amelchev Nikita
>> 
>> 

Re: Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Stephen,

I guess the required classes of IP-finders should be in the classpath
(libs directory). Currently, they are copied from the optional
directory of the ignite binary package but would be copied from an
appropriate ignite extension binary package. Probably I'm missing
something but almost nothing changes in that process from my point of
view. The documentation pages will be updated prior to the release.

On Wed, 13 Oct 2021 at 13:44, Stephen Darlington
 wrote:
>
> I understand the motivation from a development point of view, but how will 
> this work for end users? Currently, the documentation talks about extensions 
> only in terms of importing maven dependencies (download.cgi 
> <https://ignite.apache.org/download.cgi#extensions>). If I’m trying to start 
> a cluster on Azure, how does that work? Do I need to build my own server?
>
> Regards,
> Stephen
>
> > On 13 Oct 2021, at 11:35, Nikita Amelchev  wrote:
> >
> > +1 to migrate and include to the Ignite 2.12 scope
> >
> > пн, 20 сент. 2021 г. в 17:09, Denis Magda :
> >>
> >> Perfect, thanks, Maxim!
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  wrote:
> >>
> >>> Folks,
> >>>
> >>>
> >>> I've created an issue [1] to move all cloud-based IP-finders to the
> >>> ignite-extensions. The motivation is the same as with migration of
> >>> Spring Data integration - to remove integration dependency of the
> >>> release cycle on Ignite releases.
> >>>
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-15541
> >>>
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
>
>

Re: Move Azure, AWS, GCE to the ignite-extensions

[Stephen Darlington]

I understand the motivation from a development point of view, but how will this 
work for end users? Currently, the documentation talks about extensions only in 
terms of importing maven dependencies (download.cgi 
<https://ignite.apache.org/download.cgi#extensions>). If I’m trying to start a 
cluster on Azure, how does that work? Do I need to build my own server?

Regards,
Stephen

> On 13 Oct 2021, at 11:35, Nikita Amelchev  wrote:
> 
> +1 to migrate and include to the Ignite 2.12 scope
> 
> пн, 20 сент. 2021 г. в 17:09, Denis Magda :
>> 
>> Perfect, thanks, Maxim!
>> 
>> -
>> Denis
>> 
>> 
>> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  wrote:
>> 
>>> Folks,
>>> 
>>> 
>>> I've created an issue [1] to move all cloud-based IP-finders to the
>>> ignite-extensions. The motivation is the same as with migration of
>>> Spring Data integration - to remove integration dependency of the
>>> release cycle on Ignite releases.
>>> 
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-15541
>>> 
> 
> 
> 
> -- 
> Best wishes,
> Amelchev Nikita

Re: Move Azure, AWS, GCE to the ignite-extensions

[Petr Ivanov]

+1


Those parts still very optional nowadays.

> On 20 Sep 2021, at 15:29, Maxim Muzafarov  wrote:
> 
> Folks,
> 
> 
> I've created an issue [1] to move all cloud-based IP-finders to the
> ignite-extensions. The motivation is the same as with migration of
> Spring Data integration - to remove integration dependency of the
> release cycle on Ignite releases.
> 
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-15541

Re: Move Azure, AWS, GCE to the ignite-extensions

[Nikita Amelchev]

+1 to migrate and include to the Ignite 2.12 scope

пн, 20 сент. 2021 г. в 17:09, Denis Magda :
>
> Perfect, thanks, Maxim!
>
> -
> Denis
>
>
> On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  wrote:
>
> > Folks,
> >
> >
> > I've created an issue [1] to move all cloud-based IP-finders to the
> > ignite-extensions. The motivation is the same as with migration of
> > Spring Data integration - to remove integration dependency of the
> > release cycle on Ignite releases.
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-15541
> >



-- 
Best wishes,
Amelchev Nikita

Re: [DISCUSS] Release spring-tx-ext and spring-cache-ext Ignite extensions

[Nikolay Izhikov]

+1

> 5 окт. 2021 г., в 11:48, Nikita Amelchev  написал(а):
> 
> Folks, we should release the spring-data-commons module with the 1.1.0
> version to release spring-tx, spring-cache modules.
> It contains some proxies required for the new modules.
> 
> I suggest:
> 
> 1. Release the spring-data-commons 1.1.0, spring-tx 1.0.0,
> spring-cache 1.0.0 modules with separate source packages:
> 
> /ignite/ignite-extensions/ignite-spring-data-commons/1.1.0/[src]
> /ignite/ignite-extensions/ignite-spring-tx-ext/1.0.0/[src]
> /ignite/ignite-extensions/ignite-spring-cache-ext/1.0.0/[src]
> 
> (The spring-data-commons 1.0.0 was included in the
> ignite-spring-data-all-ext/1.0.0 source package)
> 
> 2. Use one voting thread for this activity.
> 
> Any objections?
> 
> пт, 24 сент. 2021 г. в 15:14, Nikita Amelchev :
>> 
>> Igniters,
>> 
>> Since Ignite 2.11 has been released the following extension modules
>> can be released too:
>> 
>> spring-cache-ext
>> spring-tx-ext
>> 
>> I want to be a release manager for these if nobody minds.
>> 
>> The release process can be started after checking documentation.
>> 
>> --
>> Best wishes,
>> Amelchev Nikita
> 
> 
> 
> -- 
> Best wishes,
> Amelchev Nikita

Re: Migration of CacheSpringStoreSessionListener to ignite-extensions

[Ivan Daschinsky]

+1 As for me. It is pretty weird that this few lines of code depend on full
spring :)

вт, 5 окт. 2021 г. в 11:24, Nikita Amelchev :

> Mikhail,
>
> +1 to migrate and include to the ignite-spring-tx 1.0.0, Ignite 2.12 scopes
>
> Please, create an issue.
>
> пн, 4 окт. 2021 г. в 18:51, Mikhail Petrov :
> >
> > Igniters, I propose to migrate CacheSpringStoreSessionListener to
> > ignite-extensions in the ignite-spring-tx module as part of Spring
> > Transactions integration migration. It also helps to
> > 1. Make the ignite-spring module responsible only for parsing XML
> > configurations.
> > 2. Reduce the number of dependencies that the ignite-spring module
> > relies on to just spring-context.
> >
> > PRs with the migration - [1] and [2].
> >
> > Any objections?
> >
> > [1]  - https://github.com/apache/ignite-extensions/pull/74
> > [2] -  https://github.com/apache/ignite/pull/9467
> >
> > --
> > Mikhail
> >
>
>
> --
> Best wishes,
> Amelchev Nikita
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSS] Release spring-tx-ext and spring-cache-ext Ignite extensions

[Nikita Amelchev]

Folks, we should release the spring-data-commons module with the 1.1.0
version to release spring-tx, spring-cache modules.
It contains some proxies required for the new modules.

I suggest:

1. Release the spring-data-commons 1.1.0, spring-tx 1.0.0,
spring-cache 1.0.0 modules with separate source packages:

/ignite/ignite-extensions/ignite-spring-data-commons/1.1.0/[src]
/ignite/ignite-extensions/ignite-spring-tx-ext/1.0.0/[src]
/ignite/ignite-extensions/ignite-spring-cache-ext/1.0.0/[src]

(The spring-data-commons 1.0.0 was included in the
ignite-spring-data-all-ext/1.0.0 source package)

2. Use one voting thread for this activity.

Any objections?

пт, 24 сент. 2021 г. в 15:14, Nikita Amelchev :
>
> Igniters,
>
> Since Ignite 2.11 has been released the following extension modules
> can be released too:
>
> spring-cache-ext
> spring-tx-ext
>
> I want to be a release manager for these if nobody minds.
>
> The release process can be started after checking documentation.
>
> --
> Best wishes,
> Amelchev Nikita



-- 
Best wishes,
Amelchev Nikita

Re: Migration of CacheSpringStoreSessionListener to ignite-extensions

[Nikita Amelchev]

Mikhail,

+1 to migrate and include to the ignite-spring-tx 1.0.0, Ignite 2.12 scopes

Please, create an issue.

пн, 4 окт. 2021 г. в 18:51, Mikhail Petrov :
>
> Igniters, I propose to migrate CacheSpringStoreSessionListener to
> ignite-extensions in the ignite-spring-tx module as part of Spring
> Transactions integration migration. It also helps to
> 1. Make the ignite-spring module responsible only for parsing XML
> configurations.
> 2. Reduce the number of dependencies that the ignite-spring module
> relies on to just spring-context.
>
> PRs with the migration - [1] and [2].
>
> Any objections?
>
> [1]  - https://github.com/apache/ignite-extensions/pull/74
> [2] -  https://github.com/apache/ignite/pull/9467
>
> --
> Mikhail
>


-- 
Best wishes,
Amelchev Nikita

Migration of CacheSpringStoreSessionListener to ignite-extensions

[Mikhail Petrov]

Igniters, I propose to migrate CacheSpringStoreSessionListener to 
ignite-extensions in the ignite-spring-tx module as part of Spring 
Transactions integration migration. It also helps to
1. Make the ignite-spring module responsible only for parsing XML 
configurations.
2. Reduce the number of dependencies that the ignite-spring module 
relies on to just spring-context.


PRs with the migration - [1] and [2].

Any objections?

[1]  - https://github.com/apache/ignite-extensions/pull/74
[2] -  https://github.com/apache/ignite/pull/9467

--
Mikhail

[DISCUSS] Release spring-tx-ext and spring-cache-ext Ignite extensions

[Nikita Amelchev]

Igniters,

Since Ignite 2.11 has been released the following extension modules
can be released too:

spring-cache-ext
spring-tx-ext

I want to be a release manager for these if nobody minds.

The release process can be started after checking documentation.

-- 
Best wishes,
Amelchev Nikita

Re: Move Azure, AWS, GCE to the ignite-extensions

[Denis Magda]

Perfect, thanks, Maxim!

-
Denis


On Mon, Sep 20, 2021 at 8:29 AM Maxim Muzafarov  wrote:

> Folks,
>
>
> I've created an issue [1] to move all cloud-based IP-finders to the
> ignite-extensions. The motivation is the same as with migration of
> Spring Data integration - to remove integration dependency of the
> release cycle on Ignite releases.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-15541
>

Move Azure, AWS, GCE to the ignite-extensions

[Maxim Muzafarov]

Folks,


I've created an issue [1] to move all cloud-based IP-finders to the
ignite-extensions. The motivation is the same as with migration of
Spring Data integration - to remove integration dependency of the
release cycle on Ignite releases.


[1] https://issues.apache.org/jira/browse/IGNITE-15541

[jira] [Created] (IGNITE-14621) Ignite Extensions: change spring-data-*-ext modules names to align with a directory name

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-14621:


 Summary: Ignite Extensions: change spring-data-*-ext modules names 
to align with a directory name
 Key: IGNITE-14621
 URL: https://issues.apache.org/jira/browse/IGNITE-14621
 Project: Ignite
  Issue Type: Task
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


Change the following modules names:
{{ignite-spring-data_2.2-ext}}
{{ignite-spring-data_2.0-ext}}
on
{{ignite-spring-data-2.2-ext}}
{{ignite-spring-data-2.0-ext}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14570) Ignite Extensions: Add default checkpoint methods to the IgnitePerformanceStatisticsHandler handler

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-14570:


 Summary: Ignite Extensions: Add default checkpoint methods to the 
IgnitePerformanceStatisticsHandler handler
 Key: IGNITE-14570
 URL: https://issues.apache.org/jira/browse/IGNITE-14570
 Project: Ignite
  Issue Type: Task
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


Add default checkpoint methods to the IgnitePerformanceStatisticsHandler 
handler to fix compilation after 
[IGNITE-14385|https://issues.apache.org/jira/browse/IGNITE-14385].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Maxim Muzafarov]

Denis,

If the initial release of some of the extension happens there is no
need to release each time a new Ignite version is released (if there
are no changes of a particular extension). So we should release the
initial release as fast as possible and do the others according to
needs. This is my view, but maybe I'm missing something.

On Mon, 5 Apr 2021 at 15:57, Denis Magda  wrote:
>
> Hi Maxim,
>
> I would suggest we time a release of the Ignite core and the extensions in
> the future. As of now, I can't switch to Ignite 2.10 only due to the Spring
> Data module. Not the end of the world but delays the upgrade to the new
> version.
>
> -
> Denis
>
>
> On Mon, Apr 5, 2021 at 6:32 AM Maxim Muzafarov  wrote:
>
> > Denis,
> >
> > There is no spring data artifact for the 2.10 release. We should
> > prepare the release of these extensions as fast as possible.
> >
> > On Fri, 2 Apr 2021 at 20:06, Denis Magda  wrote:
> > >
> > > Is this the first time we're releasing spring data 2.2 as an ext? Can't
> > > find any version available for 2.10? What should I use if I need Spring
> > > Data integration now for Ignite 2.10?
> > >
> > https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data_2.2
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Fri, Mar 26, 2021 at 12:55 AM Nikita Amelchev 
> > > wrote:
> > >
> > > > Hi, Denis.
> > > >
> > > > > - How is the performance stats ext is different from the profiling
> > tool
> > > > >   released in 2.10?
> > > >
> > > > The performance statistics extension is a script to build an HTML
> > > > report. The core module collects statistics to binary files and this
> > > > feature was released in 2.10.
> > > >
> > > > чт, 25 мар. 2021 г. в 21:05, Denis Magda :
> > > > >
> > > > > +1
> > > > >
> > > > > I missed our progress on the extensions frontier. Great to see more
> > > > > capabilities added to the Spring framework support.
> > > > >
> > > > > Several questions (but, I fully support the release of the
> > extensions):
> > > > >
> > > > >- How is the performance stats ext is different from the profiling
> > > > tool
> > > > >released in 2.10?
> > > > >- I've created this tutorial[1] a while ago for the Spring Data
> > > > >integration. Would you advise updating it considering any new
> > features
> > > > >(such as thin-client support)?
> > > > >- Don't you want guys to submit a talk to the Ignite Summit[2]?
> > It can
> > > > >be a "hitchhiker guide to the Spring support in Ignite" or "Using
> > > > Profiling
> > > > >to Solve Performance issues in Ignite". Happy to help with an
> > > > abstract.
> > > > >
> > > > >
> > > > > [1]
> > > > https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
> > > > > [2] https://ignite-summit.org
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev <
> > namelc...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > Since Ignite 2.10 has been released, I think we can now release new
> > > > > > extension modules:
> > > > > >
> > > > > > performance-statistics-ext
> > > > > > spring-data-ext
> > > > > > spring-tx-ext
> > > > > >
> > > > > > I want to be a release manager for these if nobody minds.
> > > > > >
> > > > > > The release process can be started after resolving a few
> > documentation
> > > > > > issues:
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/IGNITE-14417
> > > > > > https://issues.apache.org/jira/browse/IGNITE-14398
> > > > > > https://issues.apache.org/jira/browse/IGNITE-14397
> > > > > > https://issues.apache.org/jira/browse/IGNITE-13769
> > > > > >
> > > > > > --
> > > > > > Best wishes,
> > > > > > Amelchev Nikita
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best wishes,
> > > > Amelchev Nikita
> > > >
> >

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Denis Magda]

Hi Maxim,

I would suggest we time a release of the Ignite core and the extensions in
the future. As of now, I can't switch to Ignite 2.10 only due to the Spring
Data module. Not the end of the world but delays the upgrade to the new
version.

-
Denis


On Mon, Apr 5, 2021 at 6:32 AM Maxim Muzafarov  wrote:

> Denis,
>
> There is no spring data artifact for the 2.10 release. We should
> prepare the release of these extensions as fast as possible.
>
> On Fri, 2 Apr 2021 at 20:06, Denis Magda  wrote:
> >
> > Is this the first time we're releasing spring data 2.2 as an ext? Can't
> > find any version available for 2.10? What should I use if I need Spring
> > Data integration now for Ignite 2.10?
> >
> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data_2.2
> >
> > -
> > Denis
> >
> >
> > On Fri, Mar 26, 2021 at 12:55 AM Nikita Amelchev 
> > wrote:
> >
> > > Hi, Denis.
> > >
> > > > - How is the performance stats ext is different from the profiling
> tool
> > > >   released in 2.10?
> > >
> > > The performance statistics extension is a script to build an HTML
> > > report. The core module collects statistics to binary files and this
> > > feature was released in 2.10.
> > >
> > > чт, 25 мар. 2021 г. в 21:05, Denis Magda :
> > > >
> > > > +1
> > > >
> > > > I missed our progress on the extensions frontier. Great to see more
> > > > capabilities added to the Spring framework support.
> > > >
> > > > Several questions (but, I fully support the release of the
> extensions):
> > > >
> > > >- How is the performance stats ext is different from the profiling
> > > tool
> > > >released in 2.10?
> > > >- I've created this tutorial[1] a while ago for the Spring Data
> > > >integration. Would you advise updating it considering any new
> features
> > > >(such as thin-client support)?
> > > >- Don't you want guys to submit a talk to the Ignite Summit[2]?
> It can
> > > >be a "hitchhiker guide to the Spring support in Ignite" or "Using
> > > Profiling
> > > >to Solve Performance issues in Ignite". Happy to help with an
> > > abstract.
> > > >
> > > >
> > > > [1]
> > > https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
> > > > [2] https://ignite-summit.org
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev <
> namelc...@apache.org>
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > Since Ignite 2.10 has been released, I think we can now release new
> > > > > extension modules:
> > > > >
> > > > > performance-statistics-ext
> > > > > spring-data-ext
> > > > > spring-tx-ext
> > > > >
> > > > > I want to be a release manager for these if nobody minds.
> > > > >
> > > > > The release process can be started after resolving a few
> documentation
> > > > > issues:
> > > > >
> > > > > https://issues.apache.org/jira/browse/IGNITE-14417
> > > > > https://issues.apache.org/jira/browse/IGNITE-14398
> > > > > https://issues.apache.org/jira/browse/IGNITE-14397
> > > > > https://issues.apache.org/jira/browse/IGNITE-13769
> > > > >
> > > > > --
> > > > > Best wishes,
> > > > > Amelchev Nikita
> > > > >
> > >
> > >
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
>

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Maxim Muzafarov]

Denis,

There is no spring data artifact for the 2.10 release. We should
prepare the release of these extensions as fast as possible.

On Fri, 2 Apr 2021 at 20:06, Denis Magda  wrote:
>
> Is this the first time we're releasing spring data 2.2 as an ext? Can't
> find any version available for 2.10? What should I use if I need Spring
> Data integration now for Ignite 2.10?
> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data_2.2
>
> -
> Denis
>
>
> On Fri, Mar 26, 2021 at 12:55 AM Nikita Amelchev 
> wrote:
>
> > Hi, Denis.
> >
> > > - How is the performance stats ext is different from the profiling tool
> > >   released in 2.10?
> >
> > The performance statistics extension is a script to build an HTML
> > report. The core module collects statistics to binary files and this
> > feature was released in 2.10.
> >
> > чт, 25 мар. 2021 г. в 21:05, Denis Magda :
> > >
> > > +1
> > >
> > > I missed our progress on the extensions frontier. Great to see more
> > > capabilities added to the Spring framework support.
> > >
> > > Several questions (but, I fully support the release of the extensions):
> > >
> > >- How is the performance stats ext is different from the profiling
> > tool
> > >released in 2.10?
> > >- I've created this tutorial[1] a while ago for the Spring Data
> > >integration. Would you advise updating it considering any new features
> > >(such as thin-client support)?
> > >- Don't you want guys to submit a talk to the Ignite Summit[2]? It can
> > >be a "hitchhiker guide to the Spring support in Ignite" or "Using
> > Profiling
> > >to Solve Performance issues in Ignite". Happy to help with an
> > abstract.
> > >
> > >
> > > [1]
> > https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
> > > [2] https://ignite-summit.org
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev 
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > Since Ignite 2.10 has been released, I think we can now release new
> > > > extension modules:
> > > >
> > > > performance-statistics-ext
> > > > spring-data-ext
> > > > spring-tx-ext
> > > >
> > > > I want to be a release manager for these if nobody minds.
> > > >
> > > > The release process can be started after resolving a few documentation
> > > > issues:
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-14417
> > > > https://issues.apache.org/jira/browse/IGNITE-14398
> > > > https://issues.apache.org/jira/browse/IGNITE-14397
> > > > https://issues.apache.org/jira/browse/IGNITE-13769
> > > >
> > > > --
> > > > Best wishes,
> > > > Amelchev Nikita
> > > >
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Denis Magda]

Is this the first time we're releasing spring data 2.2 as an ext? Can't
find any version available for 2.10? What should I use if I need Spring
Data integration now for Ignite 2.10?
https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data_2.2

-
Denis


On Fri, Mar 26, 2021 at 12:55 AM Nikita Amelchev 
wrote:

> Hi, Denis.
>
> > - How is the performance stats ext is different from the profiling tool
> >   released in 2.10?
>
> The performance statistics extension is a script to build an HTML
> report. The core module collects statistics to binary files and this
> feature was released in 2.10.
>
> чт, 25 мар. 2021 г. в 21:05, Denis Magda :
> >
> > +1
> >
> > I missed our progress on the extensions frontier. Great to see more
> > capabilities added to the Spring framework support.
> >
> > Several questions (but, I fully support the release of the extensions):
> >
> >- How is the performance stats ext is different from the profiling
> tool
> >released in 2.10?
> >- I've created this tutorial[1] a while ago for the Spring Data
> >integration. Would you advise updating it considering any new features
> >(such as thin-client support)?
> >- Don't you want guys to submit a talk to the Ignite Summit[2]? It can
> >be a "hitchhiker guide to the Spring support in Ignite" or "Using
> Profiling
> >to Solve Performance issues in Ignite". Happy to help with an
> abstract.
> >
> >
> > [1]
> https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
> > [2] https://ignite-summit.org
> >
> > -
> > Denis
> >
> >
> > On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev 
> > wrote:
> >
> > > Igniters,
> > >
> > > Since Ignite 2.10 has been released, I think we can now release new
> > > extension modules:
> > >
> > > performance-statistics-ext
> > > spring-data-ext
> > > spring-tx-ext
> > >
> > > I want to be a release manager for these if nobody minds.
> > >
> > > The release process can be started after resolving a few documentation
> > > issues:
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-14417
> > > https://issues.apache.org/jira/browse/IGNITE-14398
> > > https://issues.apache.org/jira/browse/IGNITE-14397
> > > https://issues.apache.org/jira/browse/IGNITE-13769
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>

[jira] [Created] (IGNITE-14456) Ignite Extensions: change copyrights to 2021

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-14456:


 Summary: Ignite Extensions: change copyrights to 2021
 Key: IGNITE-14456
 URL: https://issues.apache.org/jira/browse/IGNITE-14456
 Project: Ignite
  Issue Type: Task
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


The copyrights must be changed to 2021.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Nikita Amelchev]

Hi, Denis.

> - How is the performance stats ext is different from the profiling tool
>   released in 2.10?

The performance statistics extension is a script to build an HTML
report. The core module collects statistics to binary files and this
feature was released in 2.10.

чт, 25 мар. 2021 г. в 21:05, Denis Magda :
>
> +1
>
> I missed our progress on the extensions frontier. Great to see more
> capabilities added to the Spring framework support.
>
> Several questions (but, I fully support the release of the extensions):
>
>- How is the performance stats ext is different from the profiling tool
>released in 2.10?
>- I've created this tutorial[1] a while ago for the Spring Data
>integration. Would you advise updating it considering any new features
>(such as thin-client support)?
>- Don't you want guys to submit a talk to the Ignite Summit[2]? It can
>be a "hitchhiker guide to the Spring support in Ignite" or "Using Profiling
>to Solve Performance issues in Ignite". Happy to help with an abstract.
>
>
> [1] https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
> [2] https://ignite-summit.org
>
> -
> Denis
>
>
> On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev 
> wrote:
>
> > Igniters,
> >
> > Since Ignite 2.10 has been released, I think we can now release new
> > extension modules:
> >
> > performance-statistics-ext
> > spring-data-ext
> > spring-tx-ext
> >
> > I want to be a release manager for these if nobody minds.
> >
> > The release process can be started after resolving a few documentation
> > issues:
> >
> > https://issues.apache.org/jira/browse/IGNITE-14417
> > https://issues.apache.org/jira/browse/IGNITE-14398
> > https://issues.apache.org/jira/browse/IGNITE-14397
> > https://issues.apache.org/jira/browse/IGNITE-13769
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >



-- 
Best wishes,
Amelchev Nikita

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Denis Magda]

+1

I missed our progress on the extensions frontier. Great to see more
capabilities added to the Spring framework support.

Several questions (but, I fully support the release of the extensions):

   - How is the performance stats ext is different from the profiling tool
   released in 2.10?
   - I've created this tutorial[1] a while ago for the Spring Data
   integration. Would you advise updating it considering any new features
   (such as thin-client support)?
   - Don't you want guys to submit a talk to the Ignite Summit[2]? It can
   be a "hitchhiker guide to the Spring support in Ignite" or "Using Profiling
   to Solve Performance issues in Ignite". Happy to help with an abstract.


[1] https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial
[2] https://ignite-summit.org

-
Denis


On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev 
wrote:

> Igniters,
>
> Since Ignite 2.10 has been released, I think we can now release new
> extension modules:
>
> performance-statistics-ext
> spring-data-ext
> spring-tx-ext
>
> I want to be a release manager for these if nobody minds.
>
> The release process can be started after resolving a few documentation
> issues:
>
> https://issues.apache.org/jira/browse/IGNITE-14417
> https://issues.apache.org/jira/browse/IGNITE-14398
> https://issues.apache.org/jira/browse/IGNITE-14397
> https://issues.apache.org/jira/browse/IGNITE-13769
>
> --
> Best wishes,
> Amelchev Nikita
>

Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Maxim Muzafarov]

Hello Nikita,

+1 to follow your suggestion.
Please let me know if you need any help.

I also think the issues mentioned by you can be done in parallel and
they don't block the release :-)

On Thu, 25 Mar 2021 at 17:26, Nikita Amelchev  wrote:
>
> Igniters,
>
> Since Ignite 2.10 has been released, I think we can now release new
> extension modules:
>
> performance-statistics-ext
> spring-data-ext
> spring-tx-ext
>
> I want to be a release manager for these if nobody minds.
>
> The release process can be started after resolving a few documentation issues:
>
> https://issues.apache.org/jira/browse/IGNITE-14417
> https://issues.apache.org/jira/browse/IGNITE-14398
> https://issues.apache.org/jira/browse/IGNITE-14397
> https://issues.apache.org/jira/browse/IGNITE-13769
>
> --
> Best wishes,
> Amelchev Nikita

[DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions

[Nikita Amelchev]

Igniters,

Since Ignite 2.10 has been released, I think we can now release new
extension modules:

performance-statistics-ext
spring-data-ext
spring-tx-ext

I want to be a release manager for these if nobody minds.

The release process can be started after resolving a few documentation issues:

https://issues.apache.org/jira/browse/IGNITE-14417
https://issues.apache.org/jira/browse/IGNITE-14398
https://issues.apache.org/jira/browse/IGNITE-14397
https://issues.apache.org/jira/browse/IGNITE-13769

-- 
Best wishes,
Amelchev Nikita

[jira] [Created] (IGNITE-14273) ignite-extensions: Export data from snapshot to custom format

[Maxim Muzafarov (Jira)]

Maxim Muzafarov created IGNITE-14273:


 Summary: ignite-extensions: Export data from snapshot to custom 
format
 Key: IGNITE-14273
 URL: https://issues.apache.org/jira/browse/IGNITE-14273
 Project: Ignite
  Issue Type: Improvement
  Components: extensions
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov


The user must be able to use offline command-line tools to export data from a 
snapshot to an external appropriate format e.g. CSV, parquet, JSON.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14264) Ignite extensions: Ignite client cache manager may create cache with incorrect name

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-14264:
---

 Summary: Ignite extensions: Ignite client cache manager may create 
cache with incorrect name  
 Key: IGNITE-14264
 URL: https://issues.apache.org/jira/browse/IGNITE-14264
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Petrov
Assignee: Mikhail Petrov
 Attachments: image-2021-03-02-13-43-04-186.png

During concurrent  cache creation and calling getDynamicCacheConfiguration by 
IgniteClientCacheManager it is possible that the cache name will not be set 
correctly. To solve this problem, it is suggested to copy the dynamic cache 
configuration every time.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14249) Ignite extensions: Flaky IgniteSourceConnectorTest.testEventsInjectedIntoKafkaWithoutFilter test

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-14249:
---

 Summary: Ignite extensions: Flaky 
IgniteSourceConnectorTest.testEventsInjectedIntoKafkaWithoutFilter test
 Key: IGNITE-14249
 URL: https://issues.apache.org/jira/browse/IGNITE-14249
 Project: Ignite
  Issue Type: Test
Reporter: Mikhail Petrov


IgniteSourceConnectorTest.testEventsInjectedIntoKafkaWithoutFilter is flaky. 
See [TC 
build|https://ci.ignite.apache.org/viewLog.html?buildId=5892624=buildResultsDiv=IgniteExtensions_Tests_Kafka#testNameId788555262623894619]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14213) Ignite extensions: javadoc ignitelink tag is unsupported

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-14213:
---

 Summary: Ignite extensions: javadoc ignitelink tag is unsupported 
 Key: IGNITE-14213
 URL: https://issues.apache.org/jira/browse/IGNITE-14213
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Petrov


"ignitelink" tag is not processed in Ignite extensions (only processed in 
Ignite), we should think about how to replace it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Ignite Extensions tests

[Petr Ivanov]

Can you pinpoint exact string in log where another Ignite node is interfering, 
please?


> On 10 Feb 2021, at 11:50, Mikhail Petrov  wrote:
> 
> Here is an example - [1].
> 
> [1] - 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_SpringTransactions_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
>  
> On 10.02.2021 11:39, Petr Ivanov wrote:
>> Very good, thanks!
>> I will prepare build shortly.
>> 
>> About flakiness — send me link to build where problem is, I will try to 
>> investigate.
>> 
>>> On 10 Feb 2021, at 11:17, Mikhail Petrov  wrote:
>>> 
>>> Petr, ticket [1] was merged to the master branch. TC build is ok now - [2]. 
>>> Sometimes i faced that some tests can be flaky because test nodes were 
>>> trying to join extra incompatible node that does not belong to the test. 
>>> But I think we could investigate it in a separate ticket.
>>> 
>>> Could I ask you to create separate test suite for the Spring Cache 
>>> extension similar to Spring Transactions for the following PR:  
>>> https://github.com/apache/ignite-extensions/pull/42
>>> 
>>> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
>>> 
>>> [2] - 
>>> https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests_IgniteExtensions_Tests=%3Cdefault%3E
>>> 
>>> On 10.02.2021 10:40, Petr Ivanov wrote:
>>>> I've updated Extensions template to use only Linux agents.
>>>> 
>>>> Will wait for ticket in master, thanks!
>>>> 
>>>> 
>>>> 
>>>>> On 10 Feb 2021, at 01:05, Mikhail Petrov  wrote:
>>>>> 
>>>>> Hi, Petr.
>>>>> 
>>>>> It seems that the problem is in an outdated version of the maven surefire 
>>>>> plugin that is used in ignite-extensions.
>>>>> 
>>>>> I created the corresponding ticket [1].
>>>>> 
>>>>> I also faced that current ignite-extensions build is broken on windows 
>>>>> agents - [2]. It fails with the following error:
>>>>> 
>>>>> /[22:47:43]'#!' is not recognized as an internal or external command,
>>>>> [22:47:43]operable program or batch file.
>>>>> [22:47:43]Environment variable -o nounset; set -o errexit; set -o 
>>>>> pipefail; set -o errtrace; set -o functrace not defined
>>>>> [22:47:43]Environment variable -x not defined
>>>>> [22:47:43]'rm' is not recognized as an internal or external command,
>>>>> [22:47:43]operable program or batch file.
>>>>> [22:47:43]The syntax of the command is incorrect.
>>>>> [22:47:43]'cp' is not recognized as an internal or external command,
>>>>> [22:47:43]operable program or batch file.
>>>>> [22:47:43]Process exited with code 1/
>>>>> 
>>>>> 
>>>>> Could you check it, please?
>>>>> 
>>>>> 
>>>>> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
>>>>> 
>>>>> [2] - 
>>>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
>>>>> 
>>>>> On 09.02.2021 13:36, Petr Ivanov wrote:
>>>>>> Hi, Nikolay.
>>>>>> 
>>>>>> 
>>>>>> I've created a set of tests for extensions, and part of them are failing 
>>>>>> with:
>>>>>> 
>>>>>> JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
>>>>>>  » NoSuchMethod
>>>>>> java.lang.NoSuchMethodError: 
>>>>>> org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
>>>>>> at 
>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>>>> at 
>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>>>> at 
>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>>>> at 
>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>>>> 
>>>>>> 
>>>>>> Could you check [1] please?
>>>>>> 
>>>>>> 
>>>>>> [1] 
>>>>>> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list
>>>>>> 

Re: Ignite Extensions tests

[Mikhail Petrov]

Here is an example - [1].

[1] - 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_SpringTransactions_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv 


On 10.02.2021 11:39, Petr Ivanov wrote:

Very good, thanks!
I will prepare build shortly.

About flakiness — send me link to build where problem is, I will try to 
investigate.


On 10 Feb 2021, at 11:17, Mikhail Petrov  wrote:

Petr, ticket [1] was merged to the master branch. TC build is ok now - [2]. 
Sometimes i faced that some tests can be flaky because test nodes were trying 
to join extra incompatible node that does not belong to the test. But I think 
we could investigate it in a separate ticket.

Could I ask you to create separate test suite for the Spring Cache extension 
similar to Spring Transactions for the following PR:  
https://github.com/apache/ignite-extensions/pull/42

[1] - https://issues.apache.org/jira/browse/IGNITE-14150

[2] - 
https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests_IgniteExtensions_Tests=%3Cdefault%3E

On 10.02.2021 10:40, Petr Ivanov wrote:

I've updated Extensions template to use only Linux agents.

Will wait for ticket in master, thanks!




On 10 Feb 2021, at 01:05, Mikhail Petrov  wrote:

Hi, Petr.

It seems that the problem is in an outdated version of the maven surefire 
plugin that is used in ignite-extensions.

I created the corresponding ticket [1].

I also faced that current ignite-extensions build is broken on windows agents - 
[2]. It fails with the following error:

/[22:47:43]'#!' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]Environment variable -o nounset; set -o errexit; set -o pipefail; set 
-o errtrace; set -o functrace not defined
[22:47:43]Environment variable -x not defined
[22:47:43]'rm' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]The syntax of the command is incorrect.
[22:47:43]'cp' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]Process exited with code 1/


Could you check it, please?


[1] - https://issues.apache.org/jira/browse/IGNITE-14150

[2] - 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv

On 09.02.2021 13:36, Petr Ivanov wrote:

Hi, Nikolay.


I've created a set of tests for extensions, and part of them are failing with:

JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
 » NoSuchMethod
java.lang.NoSuchMethodError: 
org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)


Could you check [1] please?


[1] 
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list

Re: Ignite Extensions tests

[Petr Ivanov]

Very good, thanks!
I will prepare build shortly.

About flakiness — send me link to build where problem is, I will try to 
investigate.

> On 10 Feb 2021, at 11:17, Mikhail Petrov  wrote:
> 
> Petr, ticket [1] was merged to the master branch. TC build is ok now - [2]. 
> Sometimes i faced that some tests can be flaky because test nodes were trying 
> to join extra incompatible node that does not belong to the test. But I think 
> we could investigate it in a separate ticket.
> 
> Could I ask you to create separate test suite for the Spring Cache extension 
> similar to Spring Transactions for the following PR:  
> https://github.com/apache/ignite-extensions/pull/42
> 
> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
> 
> [2] - 
> https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests_IgniteExtensions_Tests=%3Cdefault%3E
> 
> On 10.02.2021 10:40, Petr Ivanov wrote:
>> I've updated Extensions template to use only Linux agents.
>> 
>> Will wait for ticket in master, thanks!
>> 
>> 
>> 
>>> On 10 Feb 2021, at 01:05, Mikhail Petrov  wrote:
>>> 
>>> Hi, Petr.
>>> 
>>> It seems that the problem is in an outdated version of the maven surefire 
>>> plugin that is used in ignite-extensions.
>>> 
>>> I created the corresponding ticket [1].
>>> 
>>> I also faced that current ignite-extensions build is broken on windows 
>>> agents - [2]. It fails with the following error:
>>> 
>>> /[22:47:43]'#!' is not recognized as an internal or external command,
>>> [22:47:43]operable program or batch file.
>>> [22:47:43]Environment variable -o nounset; set -o errexit; set -o pipefail; 
>>> set -o errtrace; set -o functrace not defined
>>> [22:47:43]Environment variable -x not defined
>>> [22:47:43]'rm' is not recognized as an internal or external command,
>>> [22:47:43]operable program or batch file.
>>> [22:47:43]The syntax of the command is incorrect.
>>> [22:47:43]'cp' is not recognized as an internal or external command,
>>> [22:47:43]operable program or batch file.
>>> [22:47:43]Process exited with code 1/
>>> 
>>> 
>>> Could you check it, please?
>>> 
>>> 
>>> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
>>> 
>>> [2] - 
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
>>> 
>>> On 09.02.2021 13:36, Petr Ivanov wrote:
>>>> Hi, Nikolay.
>>>> 
>>>> 
>>>> I've created a set of tests for extensions, and part of them are failing 
>>>> with:
>>>> 
>>>> JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
>>>>  » NoSuchMethod
>>>> java.lang.NoSuchMethodError: 
>>>> org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
>>>> at 
>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>> at 
>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>> at 
>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>> at 
>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>> 
>>>> 
>>>> Could you check [1] please?
>>>> 
>>>> 
>>>> [1] 
>>>> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list
>>>> 

Re: Ignite Extensions tests

[Mikhail Petrov]

Petr, ticket [1] was merged to the master branch. TC build is ok now - 
[2]. Sometimes i faced that some tests can be flaky because test nodes 
were trying to join extra incompatible node that does not belong to the 
test. But I think we could investigate it in a separate ticket.


Could I ask you to create separate test suite for the Spring Cache 
extension similar to Spring Transactions for the following PR:  
https://github.com/apache/ignite-extensions/pull/42


[1] - https://issues.apache.org/jira/browse/IGNITE-14150

[2] - 
https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions_Tests_IgniteExtensions_Tests=%3Cdefault%3E


On 10.02.2021 10:40, Petr Ivanov wrote:

I've updated Extensions template to use only Linux agents.

Will wait for ticket in master, thanks!




On 10 Feb 2021, at 01:05, Mikhail Petrov  wrote:

Hi, Petr.

It seems that the problem is in an outdated version of the maven surefire 
plugin that is used in ignite-extensions.

I created the corresponding ticket [1].

I also faced that current ignite-extensions build is broken on windows agents - 
[2]. It fails with the following error:

/[22:47:43]'#!' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]Environment variable -o nounset; set -o errexit; set -o pipefail; set 
-o errtrace; set -o functrace not defined
[22:47:43]Environment variable -x not defined
[22:47:43]'rm' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]The syntax of the command is incorrect.
[22:47:43]'cp' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]Process exited with code 1/


Could you check it, please?


[1] - https://issues.apache.org/jira/browse/IGNITE-14150

[2] - 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv

On 09.02.2021 13:36, Petr Ivanov wrote:

Hi, Nikolay.


I've created a set of tests for extensions, and part of them are failing with:

JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
 » NoSuchMethod
java.lang.NoSuchMethodError: 
org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)


Could you check [1] please?


[1] 
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list

Re: Ignite Extensions tests

[Petr Ivanov]

I've updated Extensions template to use only Linux agents.

Will wait for ticket in master, thanks!



> On 10 Feb 2021, at 01:05, Mikhail Petrov  wrote:
> 
> Hi, Petr.
> 
> It seems that the problem is in an outdated version of the maven surefire 
> plugin that is used in ignite-extensions.
> 
> I created the corresponding ticket [1].
> 
> I also faced that current ignite-extensions build is broken on windows agents 
> - [2]. It fails with the following error:
> 
> /[22:47:43]'#!' is not recognized as an internal or external command,
> [22:47:43]operable program or batch file.
> [22:47:43]Environment variable -o nounset; set -o errexit; set -o pipefail; 
> set -o errtrace; set -o functrace not defined
> [22:47:43]Environment variable -x not defined
> [22:47:43]'rm' is not recognized as an internal or external command,
> [22:47:43]operable program or batch file.
> [22:47:43]The syntax of the command is incorrect.
> [22:47:43]'cp' is not recognized as an internal or external command,
> [22:47:43]operable program or batch file.
> [22:47:43]Process exited with code 1/
> 
> 
> Could you check it, please?
> 
> 
> [1] - https://issues.apache.org/jira/browse/IGNITE-14150
> 
> [2] - 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv
> 
> On 09.02.2021 13:36, Petr Ivanov wrote:
>> Hi, Nikolay.
>> 
>> 
>> I've created a set of tests for extensions, and part of them are failing 
>> with:
>> 
>> JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
>>  » NoSuchMethod
>> java.lang.NoSuchMethodError: 
>> org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
>> at 
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>> at 
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>> at 
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>> at 
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>> 
>> 
>> Could you check [1] please?
>> 
>> 
>> [1] 
>> https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list
>> 

Re: Ignite Extensions tests

[Mikhail Petrov]

Hi, Petr.

It seems that the problem is in an outdated version of the maven 
surefire plugin that is used in ignite-extensions.


I created the corresponding ticket [1].

I also faced that current ignite-extensions build is broken on windows 
agents - [2]. It fails with the following error:


/[22:47:43]'#!' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]Environment variable -o nounset; set -o errexit; set -o 
pipefail; set -o errtrace; set -o functrace not defined

[22:47:43]Environment variable -x not defined
[22:47:43]'rm' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]The syntax of the command is incorrect.
[22:47:43]'cp' is not recognized as an internal or external command,
[22:47:43]operable program or batch file.
[22:47:43]Process exited with code 1/


Could you check it, please?


[1] - https://issues.apache.org/jira/browse/IGNITE-14150

[2] - 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_Flink_IgniteExtensions_Tests=%3Cdefault%3E=buildTypeStatusDiv


On 09.02.2021 13:36, Petr Ivanov wrote:

Hi, Nikolay.


I've created a set of tests for extensions, and part of them are failing with:

JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
 » NoSuchMethod
java.lang.NoSuchMethodError: 
org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)


Could you check [1] please?


[1] 
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list

[jira] [Created] (IGNITE-14150) Update version of surefire plugin in ignite-extensions

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-14150:
---

 Summary: Update version of surefire plugin in ignite-extensions
 Key: IGNITE-14150
 URL: https://issues.apache.org/jira/browse/IGNITE-14150
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Petrov
Assignee: Mikhail Petrov


It's needed to update version of surefire plugin in ignite-extensions to 
3.0.0-M4. 

Mismatch of surefire plugin version between ignite-tools and ignite-extensions 
causes the following error during tests execution:
{code:java}
java.lang.NoSuchMethodError: 
org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
{code}
 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Ignite Extensions tests

[Petr Ivanov]

Hi, Nikolay.


I've created a set of tests for extensions, and part of them are failing with:

JUnit4Provider.invoke:159->executeTestSet:238->executeWithRerun:273->execute:365
 » NoSuchMethod
java.lang.NoSuchMethodError: 
org.apache.maven.surefire.report.SimpleReportEntry.withException(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lorg/apache/maven/surefire/report/StackTraceWriter;)Lorg/apache/maven/surefire/report/SimpleReportEntry;
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)


Could you check [1] please?


[1] 
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests/5864907?buildTab=dependencies=list

Re: Access to Ignite Extensions TeamCity project

[Sergey D]

Hi, Petr.

Now I have access.

Thanks!

пн, 25 янв. 2021 г. в 11:28, Petr Ivanov :

> Hi, Sergey.
>
>
> Check you permissions, please.
>
> > On 24 Jan 2021, at 21:00, Sergey D  wrote:
> >
> > Hi Igniters,
> >
> > I want to start work on a ticket in ignite extension project, but it
> seems
> > that i don`t have permission to this project in TeamCity.
> > "You do not have enough permissions to access project with id
> > IgniteExtensions_Tests"
> >
> > My username is  stalkxt .
> >
> > Can you help me please?
> >
> > --
> > *Best regards, Sergey.*
>
>

-- 
*Best regards, Sergey.*

Re: Access to Ignite Extensions TeamCity project

[Petr Ivanov]

Hi, Sergey.


Check you permissions, please.

> On 24 Jan 2021, at 21:00, Sergey D  wrote:
> 
> Hi Igniters,
> 
> I want to start work on a ticket in ignite extension project, but it seems
> that i don`t have permission to this project in TeamCity.
> "You do not have enough permissions to access project with id
> IgniteExtensions_Tests"
> 
> My username is  stalkxt .
> 
> Can you help me please?
> 
> -- 
> *Best regards, Sergey.*

Access to Ignite Extensions TeamCity project

[Sergey D]

Hi Igniters,

I want to start work on a ticket in ignite extension project, but it seems
that i don`t have permission to this project in TeamCity.
"You do not have enough permissions to access project with id
IgniteExtensions_Tests"

My username is  stalkxt .

Can you help me please?

-- 
*Best regards, Sergey.*

[jira] [Created] (IGNITE-14010) Ignite-extensions: KafkaIgniteSteamerSelfTest is flaky

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-14010:
---

 Summary: Ignite-extensions: KafkaIgniteSteamerSelfTest is flaky
 Key: IGNITE-14010
 URL: https://issues.apache.org/jira/browse/IGNITE-14010
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Petrov
Assignee: Mikhail Petrov


KafkaIgniteSteamerSelfTest test is flaky - [TC 
build|https://ci.ignite.apache.org/test/4285346063968224069?currentProjectId=IgniteExtensions_Tests=IgniteExtensions_Tests_Build=].
 It fails with the following error: 
{code:java}
java.lang.AssertionError: Failed to wait latch completion, still wait 100 
events  at 
org.apache.ignite.stream.kafka.KafkaIgniteStreamerSelfTest.consumerStream(KafkaIgniteStreamerSelfTest.java:242)
  at 
org.apache.ignite.stream.kafka.KafkaIgniteStreamerSelfTest.testKafkaStreamer(KafkaIgniteStreamerSelfTest.java:113)
{code}
This needs to be fixed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14009) Ignite-extensions: PubSubStreamerSelfTest is flaky

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-14009:
---

 Summary: Ignite-extensions: PubSubStreamerSelfTest is flaky
 Key: IGNITE-14009
 URL: https://issues.apache.org/jira/browse/IGNITE-14009
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Petrov


PubSubStreamerSelfTest is flaky -  [TC 
build|https://ci.ignite.apache.org/test/-1227012852016489408?currentProjectId=IgniteExtensions_Tests=IgniteExtensions_Tests_Build=pull%2F34%2F].
 This needs to be fixed. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14007) Ignite-extensions: ignite-kafka integration test suite fails TC build

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-14007:
---

 Summary: Ignite-extensions: ignite-kafka integration test suite 
fails TC build
 Key: IGNITE-14007
 URL: https://issues.apache.org/jira/browse/IGNITE-14007
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Petrov
Assignee: Mikhail Petrov


JVM exits with code 130 during ignite-kafka-ext:IgniteSourceConnectorTest 
execution that causes TC build failure - [TC 
build|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Build/5831371?showLog=5831371_14949_1587.14949=debug]

It happens because 
 1. Started in FlinkIgniteSunkSelfTest ignite instance remains unclosed. And 
since it s started in separate test suite it is not closed automatically by 
Ignite test framework since maven surefire plugin uses different classloaders 
to load classes from different test suites.
 2. Extra node causes error in marshalling of remote event filter because of  
[IGNITE-14006]|https://issues.apache.org/jira/browse/IGNITE-14006]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Apache Ignite Extensions TeamCity project

[Saikat Maitra]

Hi Petr,

I am able to access the project.

Thank you

Regards,
Saikat

On Wed, Jan 13, 2021 at 2:17 AM Petr Ivanov  wrote:

> Added you to Ignite Test Managers.
> Please check access level.
>
>
> > On 13 Jan 2021, at 03:49, Saikat Maitra  wrote:
> >
> > Hi Petr,
> >
> > Thank you for your response. I am not able to access the project due to
> > error
> >
> > "You do not have enough permissions to access project with id
> > IgniteExtensions_Tests"
> >
> > Can you please provide me access? My username is samaitra
> >
> > Regards,
> > Saikat
> >
> > On Mon, Jan 11, 2021 at 2:55 AM Petr Ivanov  wrote:
> >
> >> Hi.
> >>
> >>
> >> I've refactored the hierarchy of the project and moved it here:
> >> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds
> <
> >> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds
> >
> >> Check your permissions, please.
> >>
> >>> On 11 Jan 2021, at 01:01, Saikat Maitra 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> We had a project for IgniteExtensions under Tests main project in
> >> TeamCity.
> >>>
> >>>
> >>
> https://ci.ignite.apache.org/project.html?projectId=Tests_IgniteExtensions
> >>>
> >>> I am no longer able to access the IgniteExtensions project.
> >>>
> >>> Was it refactored and moved to another location?
> >>>
> >>> Regards,
> >>> Saikat
> >>
> >>
>
>

[jira] [Created] (IGNITE-13993) Ignite-extensions: Change version of Ignite dependency to 2.11.0

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-13993:
---

 Summary: Ignite-extensions: Change version of Ignite dependency to 
2.11.0
 Key: IGNITE-13993
 URL: https://issues.apache.org/jira/browse/IGNITE-13993
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Petrov
Assignee: Mikhail Petrov


It's needed to change version of Ignite dependency to 2.11.0-SNAPSHOT. Now it 
causes TC ignite-extensions build failure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13992) Migrate spring-transactions integration to ignite-extensions

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-13992:
---

 Summary: Migrate spring-transactions integration to 
ignite-extensions
 Key: IGNITE-13992
 URL: https://issues.apache.org/jira/browse/IGNITE-13992
 Project: Ignite
  Issue Type: Improvement
Reporter: Mikhail Petrov
Assignee: Mikhail Petrov


It's needed to migrate spring-transactions integration to ignite-extensions 
repository.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Migration of Spring Cache and Spring Transactions integrations to ignite-extensions.

[Mikhail Petrov]

Igniters,

I propose to migrate the Spring Transactions [1] and Spring Cache [2] 
integrations, that are currently stored in the ignite-spring module [3], 
to the ignite-extensions repository and split them as two separate 
modules - ignite-spring-transactions-ext and ignite-spring-cache-ext.



The motivation is the same as with migration of Spring Data integration 
[4] - to remove Spring integration releases cycle dependency on Ignite 
releases.
It can also help us reuse classes that are common across all Spring 
integrations.


WDYT? Any objections?

Regards,
Mikhail.

[1] - 
https://github.com/apache/ignite/tree/master/modules/spring/src/main/java/org/apache/ignite/transactions/spring
[2] - 
https://github.com/apache/ignite/tree/master/modules/spring/src/main/java/org/apache/ignite/cache/spring

[3] - https://github.com/apache/ignite/tree/master/modules/spring
[4] - 
http://apache-ignite-developers.2346864.n4.nabble.com/Migration-of-spring-data-modules-to-ignite-extensions-td49566.html

Re: Apache Ignite Extensions TeamCity project

[Petr Ivanov]

Added you to Ignite Test Managers.
Please check access level.


> On 13 Jan 2021, at 03:49, Saikat Maitra  wrote:
> 
> Hi Petr,
> 
> Thank you for your response. I am not able to access the project due to
> error
> 
> "You do not have enough permissions to access project with id
> IgniteExtensions_Tests"
> 
> Can you please provide me access? My username is samaitra
> 
> Regards,
> Saikat
> 
> On Mon, Jan 11, 2021 at 2:55 AM Petr Ivanov  wrote:
> 
>> Hi.
>> 
>> 
>> I've refactored the hierarchy of the project and moved it here:
>> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds <
>> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds>
>> Check your permissions, please.
>> 
>>> On 11 Jan 2021, at 01:01, Saikat Maitra  wrote:
>>> 
>>> Hi,
>>> 
>>> We had a project for IgniteExtensions under Tests main project in
>> TeamCity.
>>> 
>>> 
>> https://ci.ignite.apache.org/project.html?projectId=Tests_IgniteExtensions
>>> 
>>> I am no longer able to access the IgniteExtensions project.
>>> 
>>> Was it refactored and moved to another location?
>>> 
>>> Regards,
>>> Saikat
>> 
>> 

Re: Apache Ignite Extensions TeamCity project

[Saikat Maitra]

Hi Petr,

Thank you for your response. I am not able to access the project due to
error

"You do not have enough permissions to access project with id
IgniteExtensions_Tests"

Can you please provide me access? My username is samaitra

Regards,
Saikat

On Mon, Jan 11, 2021 at 2:55 AM Petr Ivanov  wrote:

> Hi.
>
>
> I've refactored the hierarchy of the project and moved it here:
> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds <
> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds>
> Check your permissions, please.
>
> > On 11 Jan 2021, at 01:01, Saikat Maitra  wrote:
> >
> > Hi,
> >
> > We had a project for IgniteExtensions under Tests main project in
> TeamCity.
> >
> >
> https://ci.ignite.apache.org/project.html?projectId=Tests_IgniteExtensions
> >
> > I am no longer able to access the IgniteExtensions project.
> >
> > Was it refactored and moved to another location?
> >
> > Regards,
> > Saikat
>
>

Re: Apache Ignite Extensions TeamCity project

[Petr Ivanov]

Hi.


I've refactored the hierarchy of the project and moved it here: 
https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds 

Check your permissions, please.

> On 11 Jan 2021, at 01:01, Saikat Maitra  wrote:
> 
> Hi,
> 
> We had a project for IgniteExtensions under Tests main project in TeamCity.
> 
> https://ci.ignite.apache.org/project.html?projectId=Tests_IgniteExtensions
> 
> I am no longer able to access the IgniteExtensions project.
> 
> Was it refactored and moved to another location?
> 
> Regards,
> Saikat

Apache Ignite Extensions TeamCity project

[Saikat Maitra]

Hi,

We had a project for IgniteExtensions under Tests main project in TeamCity.

https://ci.ignite.apache.org/project.html?projectId=Tests_IgniteExtensions

I am no longer able to access the IgniteExtensions project.

Was it refactored and moved to another location?

Regards,
Saikat

Re: [DISCUSS] Release pub-sub Ignite extensions

[Saikat Maitra]

Thank you Alexey for preparing the release process. We should be good to
release all the migrated modules.

Regards,
Saikat

On Fri, Nov 20, 2020 at 5:43 AM Alexey Goncharuk 
wrote:

> Igniters,
>
> I think we a bit overdue for releasing already migrated extension modules
> which were removed in Ignite 2.9. As Saikat mentioned, I suggest releasing
> the following modules:
> ignite-flink-ext
> ignite-flume-ext
> ignite-pub-sub-ext
> ignite-zeromq-ext
> ignite-twitter-ext
> ignite-rocketmq-ext
> ignite-mqtt-ext
> ignite-storm-ext
> ignite-camel-ext
> ignite-jms11-ext
> ignite-kafka-ext
>
> I can be a release manager for these (I discussed this with Mikhail Petrov
> - he was not intending to release these modules together with spring data).
> Each extension will be released separately (a separate tag), but I suggest
> having a single vote for them.
>
> Let me know if you have any objections. Meanwhile, I'll start preparing the
> artifacts and branches/tags.
>
> --AG
>

Re: Ignite extensions - ignite-spring-data release.

[Saikat Maitra]

Hi Mikhail,

Since spring-data-commons is common module and used internally we should be
ok to not rename it to spring-data-commons-ext.

Thank you for clarifying.

Regards,
Saikat

On Thu, Nov 19, 2020 at 5:02 AM Mikhail Petrov 
wrote:

> Petr,
>
> The purpose of the spring-data-commons modules is to store the general
> classes needed by spring-data extensions to avoid redundant code
> duplication between different version of Spring Data integration. I
> don't think it can be reused outside the "extensions" scope. Why can't
> it be placed in the ignite-extensions repository?
>
> Alexey,
>
> I don't mind if all extensions are released. I proposed to release
> spring-data modules in the first place because Spring Data thin client
> support is not included in any Ignite release and is crucial for some
> users.
>
> Regards,
> Mikhail
>
> On 19.11.2020 12:31, Petr Ivanov wrote:
> > If it is not an extensions, so why do we put it to ignite-extensions
> repository?
> >
> > Do we need additional separate ignite-utilities repository for modules
> like spring-data-commons?
> >
> >
> >
> >> On 19 Nov 2020, at 12:08, Mikhail Petrov  wrote:
> >>
> >> Saikat,
> >>
> >> spring-data-commons is a utility Ignite module that does not provide
> integration with anything and is only needed to store Spring Data
> version-independent classes for "spring-data" modules.
> >> So, spring-data-commons is not an "extension".
> >>
> >> Should we rename it in this case?
> >>
> >> Regards,
> >> Mikhail
> >>
> >>
> >> On 19.11.2020 10:55, Petr Ivanov wrote:
> >>> No 11 separate votes, but 11 separate tags is all I am proposing :)
> >>>
> >>>
> >>>> On 19 Nov 2020, at 10:33, Denis Magda  wrote:
> >>>>
> >>>> 11+ separate votes is an overkill. We certainly want, and agreed, to
> be
> >>>> able to release each extension separately. But I see nothing wrong if
> >>>> releases of N extensions are passed through a single vote.
> >>>>
> >>>> On Wednesday, November 18, 2020, Petr Ivanov 
> wrote:
> >>>>
> >>>>> I would object against all together release of these modules if this
> >>>>> process will be done in single release branch / tag.
> >>>>> Despite of the fact that all these extensions are in single
> repository, we
> >>>>> have to treat them as separate projects with separate release cycle
> and
> >>>>> release each one of them in their own tag with correct naming we were
> >>>>> discussing previously.
> >>>>>
> >>>>>
> >>>>>> On 19 Nov 2020, at 04:26, Saikat Maitra 
> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Mikhail, Can we please rename ignite-spring-data-commons to
> >>>>>> ignite-spring-data-commons-ext?
> >>>>>>
> >>>>>> Denis,
> >>>>>>
> >>>>>> We are good to release the following migrated modules as well...
> >>>>>>
> >>>>>> ignite-flink-ext
> >>>>>> ignite-flume-ext
> >>>>>> ignite-pub-sub-ext
> >>>>>> ignite-zeromq-ext
> >>>>>> ignite-twitter-ext
> >>>>>> ignite-rocketmq-ext
> >>>>>> ignite-mqtt-ext
> >>>>>> ignite-storm-ext
> >>>>>> ignite-camel-ext
> >>>>>> ignite-jms11-ext
> >>>>>> ignite-kafka-ext
> >>>>>>
> >>>>>> It will be great if we can release all these modules also together.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Saikat
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Nov 18, 2020 at 8:00 AM Mikhail Petrov <
> pmgheap@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Denis,
> >>>>>>>
> >>>>>>> I omitted "-ext" for simplicity. Currently, this suffix is present
> in
> >>>>>>> the name of  all Spring Data integration modules [1], [2]

[DISCUSS] Release pub-sub Ignite extensions

[Alexey Goncharuk]

Igniters,

I think we a bit overdue for releasing already migrated extension modules
which were removed in Ignite 2.9. As Saikat mentioned, I suggest releasing
the following modules:
ignite-flink-ext
ignite-flume-ext
ignite-pub-sub-ext
ignite-zeromq-ext
ignite-twitter-ext
ignite-rocketmq-ext
ignite-mqtt-ext
ignite-storm-ext
ignite-camel-ext
ignite-jms11-ext
ignite-kafka-ext

I can be a release manager for these (I discussed this with Mikhail Petrov
- he was not intending to release these modules together with spring data).
Each extension will be released separately (a separate tag), but I suggest
having a single vote for them.

Let me know if you have any objections. Meanwhile, I'll start preparing the
artifacts and branches/tags.

--AG

Re: Ignite extensions - ignite-spring-data release.

[Mikhail Petrov]

Petr,

The purpose of the spring-data-commons modules is to store the general 
classes needed by spring-data extensions to avoid redundant code 
duplication between different version of Spring Data integration. I 
don't think it can be reused outside the "extensions" scope. Why can't 
it be placed in the ignite-extensions repository?


Alexey,

I don't mind if all extensions are released. I proposed to release 
spring-data modules in the first place because Spring Data thin client 
support is not included in any Ignite release and is crucial for some users.


Regards,
Mikhail

On 19.11.2020 12:31, Petr Ivanov wrote:

If it is not an extensions, so why do we put it to ignite-extensions repository?

Do we need additional separate ignite-utilities repository for modules like 
spring-data-commons?




On 19 Nov 2020, at 12:08, Mikhail Petrov  wrote:

Saikat,

spring-data-commons is a utility Ignite module that does not provide integration with 
anything and is only needed to store Spring Data version-independent classes for 
"spring-data" modules.
So, spring-data-commons is not an "extension".

Should we rename it in this case?

Regards,
Mikhail


On 19.11.2020 10:55, Petr Ivanov wrote:

No 11 separate votes, but 11 separate tags is all I am proposing :)



On 19 Nov 2020, at 10:33, Denis Magda  wrote:

11+ separate votes is an overkill. We certainly want, and agreed, to be
able to release each extension separately. But I see nothing wrong if
releases of N extensions are passed through a single vote.

On Wednesday, November 18, 2020, Petr Ivanov  wrote:


I would object against all together release of these modules if this
process will be done in single release branch / tag.
Despite of the fact that all these extensions are in single repository, we
have to treat them as separate projects with separate release cycle and
release each one of them in their own tag with correct naming we were
discussing previously.



On 19 Nov 2020, at 04:26, Saikat Maitra  wrote:

Hi,

Mikhail, Can we please rename ignite-spring-data-commons to
ignite-spring-data-commons-ext?

Denis,

We are good to release the following migrated modules as well...

ignite-flink-ext
ignite-flume-ext
ignite-pub-sub-ext
ignite-zeromq-ext
ignite-twitter-ext
ignite-rocketmq-ext
ignite-mqtt-ext
ignite-storm-ext
ignite-camel-ext
ignite-jms11-ext
ignite-kafka-ext

It will be great if we can release all these modules also together.

Regards,
Saikat







On Wed, Nov 18, 2020 at 8:00 AM Mikhail Petrov 
wrote:


Denis,

I omitted "-ext" for simplicity. Currently, this suffix is present in
the name of  all Spring Data integration modules [1], [2], [3].

[1] -

https://github.com/apache/ignite-extensions/tree/master/

modules/spring-data-2.2-ext

[2] -

https://github.com/apache/ignite-extensions/tree/master/

modules/spring-data-2.0-ext

[3] -

https://github.com/apache/ignite-extensions/tree/master/

modules/spring-data-ext

Regards,
Mikhail

On 18.11.2020 16:26, Denis Magda wrote:

Are we keeping the original names of theses Spring modules? In separate
threads I saw that the names of other extensions end with “ext”.

Also, how about making a single release of all the extensions that were
migrated from the main Ignite repo. There are many of them waiting for

this

to happen. Saikat, Alex Goncharuk what do you think?

Denis

On Wednesday, November 18, 2020, Mikhail Petrov 
Hello, Igniters.

Since the migration of Ignite Spring Data modules to extensions, thin
client support for Spring Data integration was implemented. - [1].

To make this feature available for users, I propose to start the

release

process of the following modules:

* ignite-spring-data
* ignite-spring-data_2.0
* ignite-spring-data_2.2
* ignite-spring-data-commons


Any objections to it?


[1] - https://issues.apache.org/jira/browse/IGNITE-13519

Regards,
Mikhail



--
-
Denis

Re: Ignite extensions - ignite-spring-data release.

[Petr Ivanov]

If it is not an extensions, so why do we put it to ignite-extensions repository?

Do we need additional separate ignite-utilities repository for modules like 
spring-data-commons?



> On 19 Nov 2020, at 12:08, Mikhail Petrov  wrote:
> 
> Saikat,
> 
> spring-data-commons is a utility Ignite module that does not provide 
> integration with anything and is only needed to store Spring Data 
> version-independent classes for "spring-data" modules.
> So, spring-data-commons is not an "extension".
> 
> Should we rename it in this case?
> 
> Regards,
> Mikhail
> 
> 
> On 19.11.2020 10:55, Petr Ivanov wrote:
>> No 11 separate votes, but 11 separate tags is all I am proposing :)
>> 
>> 
>>> On 19 Nov 2020, at 10:33, Denis Magda  wrote:
>>> 
>>> 11+ separate votes is an overkill. We certainly want, and agreed, to be
>>> able to release each extension separately. But I see nothing wrong if
>>> releases of N extensions are passed through a single vote.
>>> 
>>> On Wednesday, November 18, 2020, Petr Ivanov  wrote:
>>> 
>>>> I would object against all together release of these modules if this
>>>> process will be done in single release branch / tag.
>>>> Despite of the fact that all these extensions are in single repository, we
>>>> have to treat them as separate projects with separate release cycle and
>>>> release each one of them in their own tag with correct naming we were
>>>> discussing previously.
>>>> 
>>>> 
>>>>> On 19 Nov 2020, at 04:26, Saikat Maitra  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Mikhail, Can we please rename ignite-spring-data-commons to
>>>>> ignite-spring-data-commons-ext?
>>>>> 
>>>>> Denis,
>>>>> 
>>>>> We are good to release the following migrated modules as well...
>>>>> 
>>>>> ignite-flink-ext
>>>>> ignite-flume-ext
>>>>> ignite-pub-sub-ext
>>>>> ignite-zeromq-ext
>>>>> ignite-twitter-ext
>>>>> ignite-rocketmq-ext
>>>>> ignite-mqtt-ext
>>>>> ignite-storm-ext
>>>>> ignite-camel-ext
>>>>> ignite-jms11-ext
>>>>> ignite-kafka-ext
>>>>> 
>>>>> It will be great if we can release all these modules also together.
>>>>> 
>>>>> Regards,
>>>>> Saikat
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Nov 18, 2020 at 8:00 AM Mikhail Petrov 
>>>>> wrote:
>>>>> 
>>>>>> Denis,
>>>>>> 
>>>>>> I omitted "-ext" for simplicity. Currently, this suffix is present in
>>>>>> the name of  all Spring Data integration modules [1], [2], [3].
>>>>>> 
>>>>>> [1] -
>>>>>> 
>>>>>> https://github.com/apache/ignite-extensions/tree/master/
>>>> modules/spring-data-2.2-ext
>>>>>> [2] -
>>>>>> 
>>>>>> https://github.com/apache/ignite-extensions/tree/master/
>>>> modules/spring-data-2.0-ext
>>>>>> [3] -
>>>>>> 
>>>>>> https://github.com/apache/ignite-extensions/tree/master/
>>>> modules/spring-data-ext
>>>>>> Regards,
>>>>>> Mikhail
>>>>>> 
>>>>>> On 18.11.2020 16:26, Denis Magda wrote:
>>>>>>> Are we keeping the original names of theses Spring modules? In separate
>>>>>>> threads I saw that the names of other extensions end with “ext”.
>>>>>>> 
>>>>>>> Also, how about making a single release of all the extensions that were
>>>>>>> migrated from the main Ignite repo. There are many of them waiting for
>>>>>> this
>>>>>>> to happen. Saikat, Alex Goncharuk what do you think?
>>>>>>> 
>>>>>>> Denis
>>>>>>> 
>>>>>>> On Wednesday, November 18, 2020, Mikhail Petrov >>>>>> wrote:
>>>>>>> 
>>>>>>>> Hello, Igniters.
>>>>>>>> 
>>>>>>>> Since the migration of Ignite Spring Data modules to extensions, thin
>>>>>>>> client support for Spring Data integration was implemented. - [1].
>>>>>>>> 
>>>>>>>> To make this feature available for users, I propose to start the
>>>> release
>>>>>>>> process of the following modules:
>>>>>>>> 
>>>>>>>> * ignite-spring-data
>>>>>>>> * ignite-spring-data_2.0
>>>>>>>> * ignite-spring-data_2.2
>>>>>>>> * ignite-spring-data-commons
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Any objections to it?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> [1] - https://issues.apache.org/jira/browse/IGNITE-13519
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Mikhail
>>>>>>>> 
>>>>>>>> 
>>>> 
>>> -- 
>>> -
>>> Denis

Re: Ignite extensions - ignite-spring-data release.

[Mikhail Petrov]

Saikat,

spring-data-commons is a utility Ignite module that does not provide 
integration with anything and is only needed to store Spring Data 
version-independent classes for "spring-data" modules.

So, spring-data-commons is not an "extension".

Should we rename it in this case?

Regards,
Mikhail


On 19.11.2020 10:55, Petr Ivanov wrote:

No 11 separate votes, but 11 separate tags is all I am proposing :)



On 19 Nov 2020, at 10:33, Denis Magda  wrote:

11+ separate votes is an overkill. We certainly want, and agreed, to be
able to release each extension separately. But I see nothing wrong if
releases of N extensions are passed through a single vote.

On Wednesday, November 18, 2020, Petr Ivanov  wrote:


I would object against all together release of these modules if this
process will be done in single release branch / tag.
Despite of the fact that all these extensions are in single repository, we
have to treat them as separate projects with separate release cycle and
release each one of them in their own tag with correct naming we were
discussing previously.



On 19 Nov 2020, at 04:26, Saikat Maitra  wrote:

Hi,

Mikhail, Can we please rename ignite-spring-data-commons to
ignite-spring-data-commons-ext?

Denis,

We are good to release the following migrated modules as well...

ignite-flink-ext
ignite-flume-ext
ignite-pub-sub-ext
ignite-zeromq-ext
ignite-twitter-ext
ignite-rocketmq-ext
ignite-mqtt-ext
ignite-storm-ext
ignite-camel-ext
ignite-jms11-ext
ignite-kafka-ext

It will be great if we can release all these modules also together.

Regards,
Saikat







On Wed, Nov 18, 2020 at 8:00 AM Mikhail Petrov 
wrote:


Denis,

I omitted "-ext" for simplicity. Currently, this suffix is present in
the name of  all Spring Data integration modules [1], [2], [3].

[1] -

https://github.com/apache/ignite-extensions/tree/master/

modules/spring-data-2.2-ext

[2] -

https://github.com/apache/ignite-extensions/tree/master/

modules/spring-data-2.0-ext

[3] -

https://github.com/apache/ignite-extensions/tree/master/

modules/spring-data-ext

Regards,
Mikhail

On 18.11.2020 16:26, Denis Magda wrote:

Are we keeping the original names of theses Spring modules? In separate
threads I saw that the names of other extensions end with “ext”.

Also, how about making a single release of all the extensions that were
migrated from the main Ignite repo. There are many of them waiting for

this

to happen. Saikat, Alex Goncharuk what do you think?

Denis

On Wednesday, November 18, 2020, Mikhail Petrov 
Hello, Igniters.

Since the migration of Ignite Spring Data modules to extensions, thin
client support for Spring Data integration was implemented. - [1].

To make this feature available for users, I propose to start the

release

process of the following modules:

* ignite-spring-data
* ignite-spring-data_2.0
* ignite-spring-data_2.2
* ignite-spring-data-commons


Any objections to it?


[1] - https://issues.apache.org/jira/browse/IGNITE-13519

Regards,
Mikhail





--
-
Denis

Re: Ignite extensions - ignite-spring-data release.

[Alexey Goncharuk]

I support having a single vote for all the extensions. Mikhail, do you mind
releasing the rest of the modules together with spring-boot? If you do, I
can take care of them but looks like this will be a separate vote, though.

чт, 19 нояб. 2020 г. в 10:55, Petr Ivanov :

> No 11 separate votes, but 11 separate tags is all I am proposing :)
>
>
> > On 19 Nov 2020, at 10:33, Denis Magda  wrote:
> >
> > 11+ separate votes is an overkill. We certainly want, and agreed, to be
> > able to release each extension separately. But I see nothing wrong if
> > releases of N extensions are passed through a single vote.
> >
> > On Wednesday, November 18, 2020, Petr Ivanov 
> wrote:
> >
> >> I would object against all together release of these modules if this
> >> process will be done in single release branch / tag.
> >> Despite of the fact that all these extensions are in single repository,
> we
> >> have to treat them as separate projects with separate release cycle and
> >> release each one of them in their own tag with correct naming we were
> >> discussing previously.
> >>
> >>
> >>> On 19 Nov 2020, at 04:26, Saikat Maitra 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Mikhail, Can we please rename ignite-spring-data-commons to
> >>> ignite-spring-data-commons-ext?
> >>>
> >>> Denis,
> >>>
> >>> We are good to release the following migrated modules as well...
> >>>
> >>> ignite-flink-ext
> >>> ignite-flume-ext
> >>> ignite-pub-sub-ext
> >>> ignite-zeromq-ext
> >>> ignite-twitter-ext
> >>> ignite-rocketmq-ext
> >>> ignite-mqtt-ext
> >>> ignite-storm-ext
> >>> ignite-camel-ext
> >>> ignite-jms11-ext
> >>> ignite-kafka-ext
> >>>
> >>> It will be great if we can release all these modules also together.
> >>>
> >>> Regards,
> >>> Saikat
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Nov 18, 2020 at 8:00 AM Mikhail Petrov 
> >>> wrote:
> >>>
> >>>> Denis,
> >>>>
> >>>> I omitted "-ext" for simplicity. Currently, this suffix is present in
> >>>> the name of  all Spring Data integration modules [1], [2], [3].
> >>>>
> >>>> [1] -
> >>>>
> >>>> https://github.com/apache/ignite-extensions/tree/master/
> >> modules/spring-data-2.2-ext
> >>>>
> >>>> [2] -
> >>>>
> >>>> https://github.com/apache/ignite-extensions/tree/master/
> >> modules/spring-data-2.0-ext
> >>>>
> >>>> [3] -
> >>>>
> >>>> https://github.com/apache/ignite-extensions/tree/master/
> >> modules/spring-data-ext
> >>>>
> >>>> Regards,
> >>>> Mikhail
> >>>>
> >>>> On 18.11.2020 16:26, Denis Magda wrote:
> >>>>> Are we keeping the original names of theses Spring modules? In
> separate
> >>>>> threads I saw that the names of other extensions end with “ext”.
> >>>>>
> >>>>> Also, how about making a single release of all the extensions that
> were
> >>>>> migrated from the main Ignite repo. There are many of them waiting
> for
> >>>> this
> >>>>> to happen. Saikat, Alex Goncharuk what do you think?
> >>>>>
> >>>>> Denis
> >>>>>
> >>>>> On Wednesday, November 18, 2020, Mikhail Petrov <
> pmgheap@gmail.com
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hello, Igniters.
> >>>>>>
> >>>>>> Since the migration of Ignite Spring Data modules to extensions,
> thin
> >>>>>> client support for Spring Data integration was implemented. - [1].
> >>>>>>
> >>>>>> To make this feature available for users, I propose to start the
> >> release
> >>>>>> process of the following modules:
> >>>>>>
> >>>>>> * ignite-spring-data
> >>>>>> * ignite-spring-data_2.0
> >>>>>> * ignite-spring-data_2.2
> >>>>>> * ignite-spring-data-commons
> >>>>>>
> >>>>>>
> >>>>>> Any objections to it?
> >>>>>>
> >>>>>>
> >>>>>> [1] - https://issues.apache.org/jira/browse/IGNITE-13519
> >>>>>>
> >>>>>> Regards,
> >>>>>> Mikhail
> >>>>>>
> >>>>>>
> >>>>
> >>
> >>
> >
> > --
> > -
> > Denis
>
>

Re: Ignite extensions - ignite-spring-data release.

[Petr Ivanov]

No 11 separate votes, but 11 separate tags is all I am proposing :)


> On 19 Nov 2020, at 10:33, Denis Magda  wrote:
> 
> 11+ separate votes is an overkill. We certainly want, and agreed, to be
> able to release each extension separately. But I see nothing wrong if
> releases of N extensions are passed through a single vote.
> 
> On Wednesday, November 18, 2020, Petr Ivanov  wrote:
> 
>> I would object against all together release of these modules if this
>> process will be done in single release branch / tag.
>> Despite of the fact that all these extensions are in single repository, we
>> have to treat them as separate projects with separate release cycle and
>> release each one of them in their own tag with correct naming we were
>> discussing previously.
>> 
>> 
>>> On 19 Nov 2020, at 04:26, Saikat Maitra  wrote:
>>> 
>>> Hi,
>>> 
>>> Mikhail, Can we please rename ignite-spring-data-commons to
>>> ignite-spring-data-commons-ext?
>>> 
>>> Denis,
>>> 
>>> We are good to release the following migrated modules as well...
>>> 
>>> ignite-flink-ext
>>> ignite-flume-ext
>>> ignite-pub-sub-ext
>>> ignite-zeromq-ext
>>> ignite-twitter-ext
>>> ignite-rocketmq-ext
>>> ignite-mqtt-ext
>>> ignite-storm-ext
>>> ignite-camel-ext
>>> ignite-jms11-ext
>>> ignite-kafka-ext
>>> 
>>> It will be great if we can release all these modules also together.
>>> 
>>> Regards,
>>> Saikat
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Nov 18, 2020 at 8:00 AM Mikhail Petrov 
>>> wrote:
>>> 
>>>> Denis,
>>>> 
>>>> I omitted "-ext" for simplicity. Currently, this suffix is present in
>>>> the name of  all Spring Data integration modules [1], [2], [3].
>>>> 
>>>> [1] -
>>>> 
>>>> https://github.com/apache/ignite-extensions/tree/master/
>> modules/spring-data-2.2-ext
>>>> 
>>>> [2] -
>>>> 
>>>> https://github.com/apache/ignite-extensions/tree/master/
>> modules/spring-data-2.0-ext
>>>> 
>>>> [3] -
>>>> 
>>>> https://github.com/apache/ignite-extensions/tree/master/
>> modules/spring-data-ext
>>>> 
>>>> Regards,
>>>> Mikhail
>>>> 
>>>> On 18.11.2020 16:26, Denis Magda wrote:
>>>>> Are we keeping the original names of theses Spring modules? In separate
>>>>> threads I saw that the names of other extensions end with “ext”.
>>>>> 
>>>>> Also, how about making a single release of all the extensions that were
>>>>> migrated from the main Ignite repo. There are many of them waiting for
>>>> this
>>>>> to happen. Saikat, Alex Goncharuk what do you think?
>>>>> 
>>>>> Denis
>>>>> 
>>>>> On Wednesday, November 18, 2020, Mikhail Petrov >> 
>>>>> wrote:
>>>>> 
>>>>>> Hello, Igniters.
>>>>>> 
>>>>>> Since the migration of Ignite Spring Data modules to extensions, thin
>>>>>> client support for Spring Data integration was implemented. - [1].
>>>>>> 
>>>>>> To make this feature available for users, I propose to start the
>> release
>>>>>> process of the following modules:
>>>>>> 
>>>>>> * ignite-spring-data
>>>>>> * ignite-spring-data_2.0
>>>>>> * ignite-spring-data_2.2
>>>>>> * ignite-spring-data-commons
>>>>>> 
>>>>>> 
>>>>>> Any objections to it?
>>>>>> 
>>>>>> 
>>>>>> [1] - https://issues.apache.org/jira/browse/IGNITE-13519
>>>>>> 
>>>>>> Regards,
>>>>>> Mikhail
>>>>>> 
>>>>>> 
>>>> 
>> 
>> 
> 
> -- 
> -
> Denis