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 pr
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 preparin
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 :)
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/i
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&branch_IgniteExt
Here is an example - [1].
[1] -
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteExtensions_Tests_SpringTransactions&branch_IgniteExtensions_Tests=%3Cdefault%3E&tab=buildTypeStatusDiv
On 10.02.2021 11:39, Petr Ivanov wrote:
Very good, thanks!
I will prepare build shortly.
About
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
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
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
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
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
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
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
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,
Mikh
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
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 p
Hello.
I think it’s up to the release manager to decide what extension he(or she)
wants to release.
Do we have a release manager who wants to release all extensions?
> 19 нояб. 2020 г., в 10:33, Denis Magda написал(а):
>
> 11+ separate votes is an overkill. We certainly want, and agreed, to b
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 relea
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
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
i
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/mast
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. Sa
+1
> 18 нояб. 2020 г., в 14:38, 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 r
Hi Alexey,
Thank you for sharing your questions.
1. The extensions modules in master branch are pointing to SNAPSHOT version
of ignite-core module so that we can test that master branch of extensions
modules are compatible with master branch of SNAPSHOT version of
ignite-core module.
Our idea w
Nikolay,
> > I thought the extensions should be tested against the latest released
> Ignite version
>
> It seems, we should try to keep extension Ignite version agnostic.
> If it impossible, then yes, we should use latest Ignite version.
>
I doubt it's possible at least for OSGi: the published art
Hello, Alexey.
> Nikolay, for spring autoconfigure, did you do this manually or does maven
> allow to granularly upgrade the modules' version?
Manually.
> I thought the extensions should be tested against the latest released Ignite
> version
It seems, we should try to keep extension Ignite
26 matches
Mail list logo
