[jira] [Created] (IGNITE-13708) Add thin client support for Spring Transactions.
Mikhail Petrov created IGNITE-13708: --- Summary: Add thin client support for Spring Transactions. Key: IGNITE-13708 URL: https://issues.apache.org/jira/browse/IGNITE-13708 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov It's needed to add thin client support for Spring Transactions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Ignite 3.0 development approach
Folks, I think we are overly driven away by the phrase 'new repo' rather than the essence of my suggestion. We can keep developing in the same repo, we can even keep developing in the master branch. My point is that Ignite 3.0 is a chance to move on with the architecture, so if we really want to make architectural improvements, we should not strive for incremental changes for *some parts of the code*. Maxim, To comment on your examples: I think that the huge effort that is currently required to make any significant change in Ignite is the perfect example of how we lack structure in the codebase. Yes, theoretically we can introduce incremental changes in the code that will improve the structure, but my question is: we did not do it before, what will enforce us to make these changes now? With the current approach, adding a new feature increases the test time non-linearly because without proper decoupling you have to test all possible combinations of features together. We can move faster than that. I also do not agree that we should reduce the scope of Ignite 3.0 that much. I do not see how the schema-first approach can be properly and reliably implemented without a reliable HA metastorage, which in turn requires a reliable replication protocol to be implemented. Besides, if a number of people want to work on some Ignite feature, why should they wait because not all community members have time to review the changes? Let's indeed focus on Sergey's suggestions on the design->development approach. I back both Nikolay's and Maxim's scope, but I think we should unite them, not intersect, and the minimal list of changes to be included to Ignite 3.0 is: - API & configuration cleanup - New management tool - Schema-first approach - New replication infrastructure Any smaller subset of changes will leave Ignite 3.0 in a transient state with people being too afraid to move to it because there are more major breaking changes scheduled. пт, 13 нояб. 2020 г. в 18:28, Alexey Zinoviev : > I'm -1 for creating a new repo. > Also I support Maxim's plan for 3.0 > > пт, 13 нояб. 2020 г. в 15:50, Maxim Muzafarov : > > > Val, > > > > > > Why *creating a new repo* is the main point we faced with? Would it be > > better to discuss the components design approach and scope management > > first suggested by Sergey Chugunov? I doubt that new repo will solve > > move us forward. > > > > Currently, I'm -1 to create a new repo with the inputs above. > > > > In addition to Nikolay's answer I see the following drawbacks of > > creating new repo: > > - we have very few positive examples of finalizing really huge > > improvements to *production-ready* states the others remains > > incomplete (MVCC, Calcite, Zookeeper, Tracing, Thread per Partition, > > etc) > > - AFAIK, the Native Persistence took a very long period of > > stabilization even after it has been developed (we must take it into > > account for developing new features like IEP-61) > > - feature development for a long period of time (like 3.0) without any > > releases will lead to all these changes became obsolete at the moment > > of release (AFAIK the 2.8 which released a year ago still has no big > > deployments) > > - human resources -- some of the Igniters may lose their interest for > > 3.0 during development, some of them may switch to different projects, > > etc. > > - do we all estimating the scope of 3.0 correct? The 2.8 release took 1.5 > > years. > > > > Have I missed something? > > > > > > I suggest the following plan: > > > > - initiate 3.0 development in the master branch (after 2.10 release > > change version to 3.0-SNAPSHOT instead of 2.11-SNAPSHOT) > > - cleanup and collapse all the current APIs (see To Be Removed List > > For Discussion on Apache Ignite 3.0 Wishlist) > > - reduce the scope for 3.0 even more. I suggest focusing on two > > things: Calcite + Schema-first approach > > - create feature branches for proposed IEPs (for 3.0 only) > > - create the release road map (allocate e.g. IEP-61 to 4.0 etc.) > > > > On Fri, 13 Nov 2020 at 14:03, Ivan Daschinsky > wrote: > > > > > > >> b. Implement IEP-61 - Common Replication Infrastructure > > > I suppose, that this is the main cause of the current discussion. > > > I hardly believe that this activity can be done without at least > > creating a > > > completely new branch. > > > > > > пт, 13 нояб. 2020 г. в 11:12, Nikolay Izhikov : > > > > > > > My suggestion: > > > > > > > > 1. Reduce Ignite3 scope to the following: > > > > a. Delete all deprecated API and support of obsolete internal > > > > protocols. > > > > b. Implement IEP-61 - Common Replication Infrastructure > > > > c. Implement new Ignite management tool ignitectl as > suggested > > > > during Ignite3 discussion. > > > > > > > > 2. Implement and release following improvements like transactions, > > Calcite > > > > based SQL, etc in the ongoing releases - Ignite 4, 5, 6 > > > > > > > > My concern against separate
Re: [DISCUSS] Ignite 3.0 development approach
> Let's indeed focus on Sergey's suggestions on the design->development > approach. +1 > - API & configuration cleanup > - New management tool > - Schema-first approach > - New replication infrastructure +1. > 16 нояб. 2020 г., в 13:40, Alexey Goncharuk > написал(а): > > Folks, > > I think we are overly driven away by the phrase 'new repo' rather than the > essence of my suggestion. We can keep developing in the same repo, we can > even keep developing in the master branch. My point is that Ignite 3.0 is a > chance to move on with the architecture, so if we really want to make > architectural improvements, we should not strive for incremental changes > for *some parts of the code*. > > Maxim, > > To comment on your examples: I think that the huge effort that is currently > required to make any significant change in Ignite is the perfect example of > how we lack structure in the codebase. Yes, theoretically we can introduce > incremental changes in the code that will improve the structure, but my > question is: we did not do it before, what will enforce us to make these > changes now? With the current approach, adding a new feature increases the > test time non-linearly because without proper decoupling you have to test > all possible combinations of features together. We can move faster than > that. > > I also do not agree that we should reduce the scope of Ignite 3.0 that > much. I do not see how the schema-first approach can be properly and > reliably implemented without a reliable HA metastorage, which in turn > requires a reliable replication protocol to be implemented. Besides, if a > number of people want to work on some Ignite feature, why should they wait > because not all community members have time to review the changes? > > Let's indeed focus on Sergey's suggestions on the design->development > approach. I back both Nikolay's and Maxim's scope, but I think we should > unite them, not intersect, and the minimal list of changes to be included > to Ignite 3.0 is: > > - API & configuration cleanup > - New management tool > - Schema-first approach > - New replication infrastructure > > Any smaller subset of changes will leave Ignite 3.0 in a transient state > with people being too afraid to move to it because there are more major > breaking changes scheduled. > > пт, 13 нояб. 2020 г. в 18:28, Alexey Zinoviev : > >> I'm -1 for creating a new repo. >> Also I support Maxim's plan for 3.0 >> >> пт, 13 нояб. 2020 г. в 15:50, Maxim Muzafarov : >> >>> Val, >>> >>> >>> Why *creating a new repo* is the main point we faced with? Would it be >>> better to discuss the components design approach and scope management >>> first suggested by Sergey Chugunov? I doubt that new repo will solve >>> move us forward. >>> >>> Currently, I'm -1 to create a new repo with the inputs above. >>> >>> In addition to Nikolay's answer I see the following drawbacks of >>> creating new repo: >>> - we have very few positive examples of finalizing really huge >>> improvements to *production-ready* states the others remains >>> incomplete (MVCC, Calcite, Zookeeper, Tracing, Thread per Partition, >>> etc) >>> - AFAIK, the Native Persistence took a very long period of >>> stabilization even after it has been developed (we must take it into >>> account for developing new features like IEP-61) >>> - feature development for a long period of time (like 3.0) without any >>> releases will lead to all these changes became obsolete at the moment >>> of release (AFAIK the 2.8 which released a year ago still has no big >>> deployments) >>> - human resources -- some of the Igniters may lose their interest for >>> 3.0 during development, some of them may switch to different projects, >>> etc. >>> - do we all estimating the scope of 3.0 correct? The 2.8 release took 1.5 >>> years. >>> >>> Have I missed something? >>> >>> >>> I suggest the following plan: >>> >>> - initiate 3.0 development in the master branch (after 2.10 release >>> change version to 3.0-SNAPSHOT instead of 2.11-SNAPSHOT) >>> - cleanup and collapse all the current APIs (see To Be Removed List >>> For Discussion on Apache Ignite 3.0 Wishlist) >>> - reduce the scope for 3.0 even more. I suggest focusing on two >>> things: Calcite + Schema-first approach >>> - create feature branches for proposed IEPs (for 3.0 only) >>> - create the release road map (allocate e.g. IEP-61 to 4.0 etc.) >>> >>> On Fri, 13 Nov 2020 at 14:03, Ivan Daschinsky >> wrote: >> b. Implement IEP-61 - Common Replication Infrastructure I suppose, that this is the main cause of the current discussion. I hardly believe that this activity can be done without at least >>> creating a completely new branch. пт, 13 нояб. 2020 г. в 11:12, Nikolay Izhikov : > My suggestion: > > 1. Reduce Ignite3 scope to the following: >a. Delete all deprecated API and support of obsolete internal > protocols. >b. Impl
Re: [DISCUSS] Ignite 3.0 development approach
Igniters, I agree that create or not create is not a question, rephrasing Shakespeare. My main point is that developing new features on top of old 2.x-style architecture is a bad idea. We will write the code and spend some time stabilizing it (which is expected and fine). But then, when we finally decide to fix our architecture and pay our (already huge) technical debt, we will have to rewrite this code again and spend time stabilizing it again. Creating new components on top of 2.x (which is actually 1.x, nothing fundamentally new was introduced in terms of architecture) is equal to wasting time now and creating more worthless work for the future. Earlier I suggested to rank all new features according to their criticality and amount of breaking changes and shape 3.0 scope based on this analysis. Let's get back to this idea and prepare a scope based on publicly shared arguments. One more thing I would add here. Our users are smart people and make decisions about upgrading or not upgrading to a new version based on cost/value balance. Incremental approach keeps cost (public API breaking changes) high but brings questionable amounts of value with each iteration. If we add more valuable features to 3.0 and force users to pay the cost only once they will be happier than if we split really needed changes to several major releases and send our users to hell of endless rewriting their codebases. In the latter case we'll see users to be much more reluctant to upgrade to newer versions. Hope this makes sense. On Mon, Nov 16, 2020 at 2:24 PM Nikolay Izhikov wrote: > > Let's indeed focus on Sergey's suggestions on the design->development > approach. > > +1 > > > - API & configuration cleanup > > - New management tool > > - Schema-first approach > > - New replication infrastructure > > +1. > > > 16 нояб. 2020 г., в 13:40, Alexey Goncharuk > написал(а): > > > > Folks, > > > > I think we are overly driven away by the phrase 'new repo' rather than > the > > essence of my suggestion. We can keep developing in the same repo, we can > > even keep developing in the master branch. My point is that Ignite 3.0 > is a > > chance to move on with the architecture, so if we really want to make > > architectural improvements, we should not strive for incremental changes > > for *some parts of the code*. > > > > Maxim, > > > > To comment on your examples: I think that the huge effort that is > currently > > required to make any significant change in Ignite is the perfect example > of > > how we lack structure in the codebase. Yes, theoretically we can > introduce > > incremental changes in the code that will improve the structure, but my > > question is: we did not do it before, what will enforce us to make these > > changes now? With the current approach, adding a new feature increases > the > > test time non-linearly because without proper decoupling you have to test > > all possible combinations of features together. We can move faster than > > that. > > > > I also do not agree that we should reduce the scope of Ignite 3.0 that > > much. I do not see how the schema-first approach can be properly and > > reliably implemented without a reliable HA metastorage, which in turn > > requires a reliable replication protocol to be implemented. Besides, if a > > number of people want to work on some Ignite feature, why should they > wait > > because not all community members have time to review the changes? > > > > Let's indeed focus on Sergey's suggestions on the design->development > > approach. I back both Nikolay's and Maxim's scope, but I think we should > > unite them, not intersect, and the minimal list of changes to be included > > to Ignite 3.0 is: > > > > - API & configuration cleanup > > - New management tool > > - Schema-first approach > > - New replication infrastructure > > > > Any smaller subset of changes will leave Ignite 3.0 in a transient state > > with people being too afraid to move to it because there are more major > > breaking changes scheduled. > > > > пт, 13 нояб. 2020 г. в 18:28, Alexey Zinoviev : > > > >> I'm -1 for creating a new repo. > >> Also I support Maxim's plan for 3.0 > >> > >> пт, 13 нояб. 2020 г. в 15:50, Maxim Muzafarov : > >> > >>> Val, > >>> > >>> > >>> Why *creating a new repo* is the main point we faced with? Would it be > >>> better to discuss the components design approach and scope management > >>> first suggested by Sergey Chugunov? I doubt that new repo will solve > >>> move us forward. > >>> > >>> Currently, I'm -1 to create a new repo with the inputs above. > >>> > >>> In addition to Nikolay's answer I see the following drawbacks of > >>> creating new repo: > >>> - we have very few positive examples of finalizing really huge > >>> improvements to *production-ready* states the others remains > >>> incomplete (MVCC, Calcite, Zookeeper, Tracing, Thread per Partition, > >>> etc) > >>> - AFAIK, the Native Persistence took a very long period of > >>> stabilization even a
Re: [DISCUSS] Ignite 3.0 development approach
Sergey. > pay our (already huge) technical debt, Can you, please, make your statement more specific? What specific points of technical debt do we have? I think we should write it down and solve the issues step by step. > 16 нояб. 2020 г., в 14:28, Sergey Chugunov > написал(а): > > Igniters, > > I agree that create or not create is not a question, rephrasing > Shakespeare. > > My main point is that developing new features on top of old 2.x-style > architecture is a bad idea. We will write the code and spend some time > stabilizing it (which is expected and fine). But then, when we finally > decide to fix our architecture and pay our (already huge) technical debt, > we will have to rewrite this code again and spend time stabilizing it again. > > Creating new components on top of 2.x (which is actually 1.x, nothing > fundamentally new was introduced in terms of architecture) is equal to > wasting time now and creating more worthless work for the future. > > Earlier I suggested to rank all new features according to their criticality > and amount of breaking changes and shape 3.0 scope based on this analysis. > Let's get back to this idea and prepare a scope based on publicly shared > arguments. > > One more thing I would add here. Our users are smart people and make > decisions about upgrading or not upgrading to a new version based on > cost/value balance. Incremental approach keeps cost (public API breaking > changes) high but brings questionable amounts of value with each iteration. > If we add more valuable features to 3.0 and force users to pay the cost > only once they will be happier than if we split really needed changes to > several major releases and send our users to hell of endless rewriting > their codebases. In the latter case we'll see users to be much more > reluctant to upgrade to newer versions. > > Hope this makes sense. > > On Mon, Nov 16, 2020 at 2:24 PM Nikolay Izhikov wrote: > >>> Let's indeed focus on Sergey's suggestions on the design->development >> approach. >> >> +1 >> >>> - API & configuration cleanup >>> - New management tool >>> - Schema-first approach >>> - New replication infrastructure >> >> +1. >> >>> 16 нояб. 2020 г., в 13:40, Alexey Goncharuk >> написал(а): >>> >>> Folks, >>> >>> I think we are overly driven away by the phrase 'new repo' rather than >> the >>> essence of my suggestion. We can keep developing in the same repo, we can >>> even keep developing in the master branch. My point is that Ignite 3.0 >> is a >>> chance to move on with the architecture, so if we really want to make >>> architectural improvements, we should not strive for incremental changes >>> for *some parts of the code*. >>> >>> Maxim, >>> >>> To comment on your examples: I think that the huge effort that is >> currently >>> required to make any significant change in Ignite is the perfect example >> of >>> how we lack structure in the codebase. Yes, theoretically we can >> introduce >>> incremental changes in the code that will improve the structure, but my >>> question is: we did not do it before, what will enforce us to make these >>> changes now? With the current approach, adding a new feature increases >> the >>> test time non-linearly because without proper decoupling you have to test >>> all possible combinations of features together. We can move faster than >>> that. >>> >>> I also do not agree that we should reduce the scope of Ignite 3.0 that >>> much. I do not see how the schema-first approach can be properly and >>> reliably implemented without a reliable HA metastorage, which in turn >>> requires a reliable replication protocol to be implemented. Besides, if a >>> number of people want to work on some Ignite feature, why should they >> wait >>> because not all community members have time to review the changes? >>> >>> Let's indeed focus on Sergey's suggestions on the design->development >>> approach. I back both Nikolay's and Maxim's scope, but I think we should >>> unite them, not intersect, and the minimal list of changes to be included >>> to Ignite 3.0 is: >>> >>> - API & configuration cleanup >>> - New management tool >>> - Schema-first approach >>> - New replication infrastructure >>> >>> Any smaller subset of changes will leave Ignite 3.0 in a transient state >>> with people being too afraid to move to it because there are more major >>> breaking changes scheduled. >>> >>> пт, 13 нояб. 2020 г. в 18:28, Alexey Zinoviev : >>> I'm -1 for creating a new repo. Also I support Maxim's plan for 3.0 пт, 13 нояб. 2020 г. в 15:50, Maxim Muzafarov : > Val, > > > Why *creating a new repo* is the main point we faced with? Would it be > better to discuss the components design approach and scope management > first suggested by Sergey Chugunov? I doubt that new repo will solve > move us forward. > > Currently, I'm -1 to create a new repo with the inputs above. > > In addition to Nikol
[jira] [Created] (IGNITE-13709) Control.sh API - status
Ivan Bessonov created IGNITE-13709: -- Summary: Control.sh API - status Key: IGNITE-13709 URL: https://issues.apache.org/jira/browse/IGNITE-13709 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Ignite 3.0 development approach
Good, I think we have an intermediate agreement on the scope and significance of the changes we want to make. I suggest creating separate discussion streams and calls for each of the suggested topics so that: - It is clear for the community what is the motivation of the stream (this includes both functional targets and technical debt issues pointed out by Sergey) - Who is planning to take an active part in each of the streams (i.e. the 'design committee', as Sergey suggested) - What are the intermediate and final goals for each of the streams - What are the cross-stream interactions and how we integrate them - How each of the streams will be integrated with the current codebase based on the above (here is where we will see whether drop-in or incremental approaches make more sense)
[jira] [Created] (IGNITE-13710) Calcite integration. Fix or to union rule logic
Igor Seliverstov created IGNITE-13710: - Summary: Calcite integration. Fix or to union rule logic Key: IGNITE-13710 URL: https://issues.apache.org/jira/browse/IGNITE-13710 Project: Ignite Issue Type: Bug Components: sql Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[MTCGA]: new failures in builds [5737288] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master Platform C++ CMake (Linux) https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCPPCMakeLinux?branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 21:07:40 16-11-2020
[MTCGA]: new failures in builds [5733560] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *Test with high flaky rate in master ZookeeperDiscoverySegmentationAndConnectionRestoreTest.testConnectionRestore_Coordinator3 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4905280575008802574&branch=%3Cdefault%3E&tab=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 01:07:47 17-11-2020
Re: IGNITE-12951 Update documents for migrated extensions
Hi Saikat,
Please go ahead with the merge. Do we need to publish this for the Ignite
2.9 docs at some point? Guess, after the extensions are released under
different names.
-
Denis
On Sun, Nov 15, 2020 at 9:57 AM Saikat Maitra
wrote:
> Hi,
>
> As discussed I have updated the PR
> https://github.com/apache/ignite-extensions/pull/30
>
> Please review and share your feedback.
>
> Regards,
> Saikat
>
> On Mon, Nov 9, 2020 at 6:38 PM Saikat Maitra
> wrote:
>
> > Hi Nikolay,
> >
> > Thank you for reviewing the changes. I have made changes only in the
> > README.txt file and updated the artifactId so that it matches with
> pom.xml.
> >
> > I have also updated the version details in the PR so that it matches with
> > our release version.
> >
> > https://github.com/apache/ignite-extensions/pull/30
> >
> > With respect to naming convention I was thinking we would not be required
> > to change the groupId and we will only change the artifactId similar to
> > spring-boot-autoconfigure-ext module.
> >
> >
> >
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-autoconfigure-ext/pom.xml#L33
> >
> > Please review and let me know your thoughts.
> >
> > Regards,
> > Saikat
> >
> >
> >
> >
> > On Mon, Nov 9, 2020 at 12:32 AM Nikolay Izhikov
> > wrote:
> >
> >> Hello, Saikat.
> >>
> >> As far as I can see you changed artifactId of the extensions not only
> >> docs.
> >>
> >> Do we have an agreement to name each extension as «{extension-name}-ext»
> >> like «ignite-camel-ext» or similar?
> >> We don’t have much extensions release, so maybe it will be better to
> have
> >> naming like
> >>
> >> groupId=org.apache.ignite.extensions
> >> artifactId=ignite-camel
> >>
> >> What do you think?
> >>
> >>
> >> > 9 нояб. 2020 г., в 05:36, Saikat Maitra
> >> написал(а):
> >> >
> >> > Hi,
> >> >
> >> > I have raised a PR for the following issue.
> >> >
> >> > Jira : https://issues.apache.org/jira/browse/IGNITE-12951
> >> > PR : https://github.com/apache/ignite-extensions/pull/30
> >> >
> >> > This is an initial PR in Ignite Extensions repo. I will work on
> another
> >> PR
> >> > in ignite repo for the remaining changes.
> >> >
> >> > Regards,
> >> > Saikat
> >>
> >>
>
[MTCGA]: new failures in builds [5735507] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *Test with high flaky rate in master GridCacheRabalancingDelayedPartitionMapExchangeSelfTest.test https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=940920927501890207&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheOrderedPreloadingSelfTest.testPreloadOrderReplicatedReplicated https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2937700972776057027&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheRebalancingAsyncSelfTest.testLoadRebalancing https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-210358662581392886&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master CacheStoreTxPutAllMultiNodeTest.testPutAllInTransaction https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4097131056025547779&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master LruEvictionPolicyFactorySelfTest.testPartitionedNearEnabled https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5121969043861328436&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencyFifoLocal https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3476446086400863042&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master DhtAndNearEvictionTest.testConcurrentWritesAndReadsWithReadThrough https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7476345237794582395&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheRebalancingSyncCheckDataTest.testDataRebalancing https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=1604362041215622318&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheRebalancingAsyncSelfTest.testComplexRebalancing https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8829809273565657995&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCachePreloadingEvictionsSelfTest.testEvictions https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4254510946241133702&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheOrderedPreloadingSelfTest.testPreloadOrderReplicatedPartitioned https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7734695386063508080&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheEvictionLockUnlockSelfTest.testPartitioned https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8487348930090046754&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheEmptyEntriesPartitionedSelfTest.testFifo https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5503818121853551451&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheRebalancingCancelTest.testClientNodeJoinAtRebalancing https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6054426226912856168&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master LruEvictionPolicyFactorySelfTest.testMaxSizePutWithBatch https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=1593110697266009100&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheOrderedPreloadingSelfTest.testPreloadOrderPartitionedReplicated https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6911101754165893919&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheEvictionLockUnlockSelfTest.testReplicated https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2849604517229554538&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master LruEvictionPolicyFactorySelfTest.testPartitionedNearEnabledMultiThreaded https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4769274565415633717&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master GridCacheRebalancingUnmarshallingFailedSelfTest.testBinary https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-471035799730358267&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master DhtAndNearEvictionTest.testRebalancing https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6550302006415857100&branch=%3Cdefault%3E&tab=testDetails *
Re: IGNITE-12951 Update documents for migrated extensions
Hi Denis,
My thoughts are that these README.txt files will be published as part of
source releases for Ignite Extensions.
Regards,
Saikat
On Mon, Nov 16, 2020 at 5:28 PM Denis Magda wrote:
> Hi Saikat,
>
> Please go ahead with the merge. Do we need to publish this for the Ignite
> 2.9 docs at some point? Guess, after the extensions are released under
> different names.
>
> -
> Denis
>
>
> On Sun, Nov 15, 2020 at 9:57 AM Saikat Maitra
> wrote:
>
> > Hi,
> >
> > As discussed I have updated the PR
> > https://github.com/apache/ignite-extensions/pull/30
> >
> > Please review and share your feedback.
> >
> > Regards,
> > Saikat
> >
> > On Mon, Nov 9, 2020 at 6:38 PM Saikat Maitra
> > wrote:
> >
> > > Hi Nikolay,
> > >
> > > Thank you for reviewing the changes. I have made changes only in the
> > > README.txt file and updated the artifactId so that it matches with
> > pom.xml.
> > >
> > > I have also updated the version details in the PR so that it matches
> with
> > > our release version.
> > >
> > > https://github.com/apache/ignite-extensions/pull/30
> > >
> > > With respect to naming convention I was thinking we would not be
> required
> > > to change the groupId and we will only change the artifactId similar to
> > > spring-boot-autoconfigure-ext module.
> > >
> > >
> > >
> >
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-autoconfigure-ext/pom.xml#L33
> > >
> > > Please review and let me know your thoughts.
> > >
> > > Regards,
> > > Saikat
> > >
> > >
> > >
> > >
> > > On Mon, Nov 9, 2020 at 12:32 AM Nikolay Izhikov
> > > wrote:
> > >
> > >> Hello, Saikat.
> > >>
> > >> As far as I can see you changed artifactId of the extensions not only
> > >> docs.
> > >>
> > >> Do we have an agreement to name each extension as
> «{extension-name}-ext»
> > >> like «ignite-camel-ext» or similar?
> > >> We don’t have much extensions release, so maybe it will be better to
> > have
> > >> naming like
> > >>
> > >> groupId=org.apache.ignite.extensions
> > >> artifactId=ignite-camel
> > >>
> > >> What do you think?
> > >>
> > >>
> > >> > 9 нояб. 2020 г., в 05:36, Saikat Maitra
> > >> написал(а):
> > >> >
> > >> > Hi,
> > >> >
> > >> > I have raised a PR for the following issue.
> > >> >
> > >> > Jira : https://issues.apache.org/jira/browse/IGNITE-12951
> > >> > PR : https://github.com/apache/ignite-extensions/pull/30
> > >> >
> > >> > This is an initial PR in Ignite Extensions repo. I will work on
> > another
> > >> PR
> > >> > in ignite repo for the remaining changes.
> > >> >
> > >> > Regards,
> > >> > Saikat
> > >>
> > >>
> >
>
Re: IGNITE-12951 Update documents for migrated extensions
Got it. Didn't pay attention that those changes were in the readme.txt
files.
Are you adjusting the docs on the website as well? I bet you were
submitting a pull-request earlier.
-
Denis
On Mon, Nov 16, 2020 at 6:31 PM Saikat Maitra
wrote:
> Hi Denis,
>
> My thoughts are that these README.txt files will be published as part of
> source releases for Ignite Extensions.
>
> Regards,
> Saikat
>
> On Mon, Nov 16, 2020 at 5:28 PM Denis Magda wrote:
>
> > Hi Saikat,
> >
> > Please go ahead with the merge. Do we need to publish this for the Ignite
> > 2.9 docs at some point? Guess, after the extensions are released under
> > different names.
> >
> > -
> > Denis
> >
> >
> > On Sun, Nov 15, 2020 at 9:57 AM Saikat Maitra
> > wrote:
> >
> > > Hi,
> > >
> > > As discussed I have updated the PR
> > > https://github.com/apache/ignite-extensions/pull/30
> > >
> > > Please review and share your feedback.
> > >
> > > Regards,
> > > Saikat
> > >
> > > On Mon, Nov 9, 2020 at 6:38 PM Saikat Maitra
> > > wrote:
> > >
> > > > Hi Nikolay,
> > > >
> > > > Thank you for reviewing the changes. I have made changes only in the
> > > > README.txt file and updated the artifactId so that it matches with
> > > pom.xml.
> > > >
> > > > I have also updated the version details in the PR so that it matches
> > with
> > > > our release version.
> > > >
> > > > https://github.com/apache/ignite-extensions/pull/30
> > > >
> > > > With respect to naming convention I was thinking we would not be
> > required
> > > > to change the groupId and we will only change the artifactId similar
> to
> > > > spring-boot-autoconfigure-ext module.
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-autoconfigure-ext/pom.xml#L33
> > > >
> > > > Please review and let me know your thoughts.
> > > >
> > > > Regards,
> > > > Saikat
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Nov 9, 2020 at 12:32 AM Nikolay Izhikov >
> > > > wrote:
> > > >
> > > >> Hello, Saikat.
> > > >>
> > > >> As far as I can see you changed artifactId of the extensions not
> only
> > > >> docs.
> > > >>
> > > >> Do we have an agreement to name each extension as
> > «{extension-name}-ext»
> > > >> like «ignite-camel-ext» or similar?
> > > >> We don’t have much extensions release, so maybe it will be better to
> > > have
> > > >> naming like
> > > >>
> > > >> groupId=org.apache.ignite.extensions
> > > >> artifactId=ignite-camel
> > > >>
> > > >> What do you think?
> > > >>
> > > >>
> > > >> > 9 нояб. 2020 г., в 05:36, Saikat Maitra
> > > >> написал(а):
> > > >> >
> > > >> > Hi,
> > > >> >
> > > >> > I have raised a PR for the following issue.
> > > >> >
> > > >> > Jira : https://issues.apache.org/jira/browse/IGNITE-12951
> > > >> > PR : https://github.com/apache/ignite-extensions/pull/30
> > > >> >
> > > >> > This is an initial PR in Ignite Extensions repo. I will work on
> > > another
> > > >> PR
> > > >> > in ignite repo for the remaining changes.
> > > >> >
> > > >> > Regards,
> > > >> > Saikat
> > > >>
> > > >>
> > >
> >
>
