C# Thin Client Data Streamer issue

[Timotheus Preisinger]

Hello!

I am saying hi here! I have just created issue IGNITE-155820 
(https://issues.apache.org/jira/browse/IGNITE-15820): Streaming from .NET Thin 
Client does not create table entries.

The issue includes a small sample project in net5 and a proposal for the fix. I 
am now trying to follow the „How to Contribute“ 
(https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Workingonaticket).

Regards,


Timotheus.

Re: Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]

[Pavel Tupitsyn]

Release build issues (IGNITE-15779) should be resolved now.

On Fri, Oct 22, 2021 at 5:38 PM Сергей Утцель  wrote:

> I configured TC bot to 'ignite-2.12' instead of 'ignite-2.11'
>

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: [DISCUSSION] Remove VS project from C++

[Ivan Daschinsky]

FYI: PR is ready [1]. Since we already changed release builds and switched
them to CMake, we can proceed with removing.

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

ср, 15 сент. 2021 г. в 13:03, Pavel Tupitsyn :

> Ivan, thanks for the answers! I retract my "-1". No objections.
>
> On Wed, Sep 15, 2021 at 12:58 PM Ivan Daschinsky 
> wrote:
>
> > >> 1. What percentage of our users rely on existing VS projects?
> > It is impossible to answer, but I suppose not so much. And, again, these
> > projects needs some tweaks in order to work properly in VS 2015+
> > Moreover, you cannot use VS as is, you should tweak them or download
> > dependencies in specific location.
> >
> > >> How much time (in minutes) does it take to switch from using existing
> VS
> > projects to CMake-generated ones?
> > If you use VS 2017 and later -- just a second, they already support CMake
> > out of box
> > https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio/
> > If you use VS2015 and earlielr -- just download cmake and use bundled gui
> > app and generate projects in few clicks.
> >
> > And don't forget about vcpkg [1]. Even microsoft goes towards cmake and
> > make even package manager for it.
> > And it works great, I've tried with Ignite C++.
> >
> > [1] -- https://github.com/microsoft/vcpkg
> >
> > ср, 15 сент. 2021 г. в 12:46, Pavel Tupitsyn :
> >
> > > Ivan,
> > >
> > > Ok, I've got your point.
> > > What's your assessment on the following:
> > >
> > > 1. What percentage of our users rely on existing VS projects?
> > > 2. How much time (in minutes) does it take to switch from using
> existing
> > VS
> > > projects to CMake-generated ones?
> > >
> > >
> > >
> > > On Wed, Sep 15, 2021 at 12:37 PM Ivan Daschinsky 
> > > wrote:
> > >
> > > > >> Currently user
> > > > Sorry typo, I meant developer.
> > > >
> > > > ср, 15 сент. 2021 г. в 12:35, Ivan Daschinsky :
> > > >
> > > > > > How?
> > > > > Currently user must add sources in 2 different places. One of this
> > > places
> > > > > is not specified and not intended to be edit outside VC.
> > > > > CMake can generate VS projects easily and without any problem. I've
> > > done
> > > > > this even in 2008 when I was C++/Qt developer.
> > > > >
> > > > > >> 1. Get all files in the directory
> > > > > >> 2. Filter by TestSuite suffix
> > > > > >> 3. Check if all of them are present in VS files
> > > > > First of all, BOOST_TEST is not NUnit :) Secondly, we can do that,
> > but
> > > it
> > > > > is not so easy as it is in .NET.
> > > > > Yes, we can use boost libraries in tests, but why we should do it?
> > Why
> > > we
> > > > > should invest our time in this activity?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ср, 15 сент. 2021 г. в 12:30, Pavel Tupitsyn  >:
> > > > >
> > > > >> > It makes development much more easier.
> > > > >>
> > > > >> How?
> > > > >>
> > > > >> > I can hardly imagine how it can be done
> > > > >>
> > > > >> 1. Get all files in the directory
> > > > >> 2. Filter by TestSuite suffix
> > > > >> 3. Check if all of them are present in VS files
> > > > >> Am I missing something? We have checks like this for Ignite.NET
> [1]
> > > > >>
> > > > >> [1]
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ProjectFilesTest.cs
> > > > >>
> > > > >>
> > > > >> On Wed, Sep 15, 2021 at 12:22 PM Ivan Daschinsky <
> > ivanda...@gmail.com
> > > >
> > > > >> wrote:
> > > > >>
> > > > >> > >> This may become an obstacle for some of the users and I'm not
> > > sure
> > > > >> how
> > > > >> > it improves anything.
> > > > >> > Please specify more correctly. What is an obstacle? Current VS
> > > > projects
> > > > >> > (odbc) cannot be build on VC 2015+
> > > > >> > without modification. CMake is an industry standard now.
> > > > >> > >> I'm not sure how it improves anything.
> > > > >> > It makes development much more easier.
> > > > >> >
> > > > >> > >> We can add an automatic check for this (in form of a test).
> > > > >> > I can hardly imagine how it can be done. And even if it is
> > possible,
> > > > >> this
> > > > >> > is a sisyphus job.
> > > > >> >
> > > > >> >
> > > > >> > ср, 15 сент. 2021 г. в 12:11, Petr Ivanov  >:
> > > > >> >
> > > > >> > > +1
> > > > >> > >
> > > > >> > > Let's keep the project clean and on the verge of preferable
> tech
> > > > >> stack.
> > > > >> > >
> > > > >> > >
> > > > >> > > > On 15 Sep 2021, at 12:02, Ivan Pavlukhin <
> vololo...@gmail.com
> > >
> > > > >> wrote:
> > > > >> > > >
> > > > >> > > > +1 for removing VS project
> > > > >> > > >
> > > > >> > > > 2021-09-15 12:01 GMT+03:00, Nikolay Izhikov <
> > > nizhi...@apache.org
> > > > >:
> > > > >> > > >> +1
> > > > >> > > >>
> > > > >> > > >>> 15 сент. 2021 г., в 11:57, Pavel Tupitsyn <
> > > ptupit...@apache.org
> > > > >
> > > > >> > > >>> написал(а):
> > > > >> > > >>>
> > > > >> > > >>> -1
> > > > >> > > >>>
> > > > >> > > >>> This may become an obstacle

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 terms of importing maven dependencies (download.cgi 
> >> ). 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
> > re