Igniters,
We already had some discussion about using modern Java versions for
Ignite 3.0 development [1] but we still don't have consensus.
As I see from this discussion the strongest argument for Java 11 is
the fact that Java 11 is the latest LTS release which will have
premier support until Sept
I totally support Java 11 for development. It's time to go forward
вт, 8 дек. 2020 г. в 11:40, Andrey Gura :
> Igniters,
>
> We already had some discussion about using modern Java versions for
> Ignite 3.0 development [1] but we still don't have consensus.
> As I see from this discussion the stro
+1, Java 11 seems to be the only right choice at the moment.
On Tue, Dec 8, 2020 at 12:08 PM Alexey Zinoviev
wrote:
> I totally support Java 11 for development. It's time to go forward
>
> вт, 8 дек. 2020 г. в 11:40, Andrey Gura :
>
> > Igniters,
> >
> > We already had some discussion about usin
Hello!
Andrey's arguments are solid.
On Tue, Dec 8, 2020 at 12:23 PM Pavel Tupitsyn wrote:
> +1, Java 11 seems to be the only right choice at the moment.
>
> On Tue, Dec 8, 2020 at 12:08 PM Alexey Zinoviev
> wrote:
>
> > I totally support Java 11 for development. It's time to go forward
> >
>
Igniters,
I want to tackle the topic of modules structure in Ignite 3. So far, the
modules in Ignite are mostly defined intuitively which leads to some
complications:
- Ignite public API is separated from the rest of the code only by
package name. This leads to private classes leaking to pu
+1
08.12.2020, 12:48, "Philipp Masharov" :
> Hello!
>
> Andrey's arguments are solid.
>
> On Tue, Dec 8, 2020 at 12:23 PM Pavel Tupitsyn wrote:
>
>> +1, Java 11 seems to be the only right choice at the moment.
>>
>> On Tue, Dec 8, 2020 at 12:08 PM Alexey Zinoviev
>> wrote:
>>
>> > I totally
Hi team,
I just made a minor change in apache ignite index page documentation.
But I am not sure the pull request raised is sufficient or do I need to
follow any additional steps. Please let me know/advice on the same.
Also is there any way to verify these changes as these are related to
documenta
Sergei Ryzhov created IGNITE-13828:
--
Summary: Change ducktape dependency to own fork
Key: IGNITE-13828
URL: https://issues.apache.org/jira/browse/IGNITE-13828
Project: Ignite
Issue Type: Tas
Sergei Ryzhov created IGNITE-13829:
--
Summary: Add log rotation to ducktape-tests
Key: IGNITE-13829
URL: https://issues.apache.org/jira/browse/IGNITE-13829
Project: Ignite
Issue Type: Task
+1 for using java 11.
> 8 дек. 2020 г., в 13:18, ткаленко кирилл написал(а):
>
> +1
>
> 08.12.2020, 12:48, "Philipp Masharov" :
>> Hello!
>>
>> Andrey's arguments are solid.
>>
>> On Tue, Dec 8, 2020 at 12:23 PM Pavel Tupitsyn wrote:
>>
>>> +1, Java 11 seems to be the only right choice at
Hello, Alexey.
Think we can extend our @IgniteExperimental annotation.
`@IgniteExperimental` - mark features that are truly experimental and can be
completely removed in future releases.
`@NotRecommended` - mark features that widely adopted by the users but
implemented wrong or have known issue
Definitely agree with Alexey. Separating API declaration from
implementation could really improve system design and avoid coupling.
About extending @IgniteExperimental annotation. It doesn't look good
to me. We should consider any API either experimental or stable. Third
option is deprecated API.
Hello, Igniters.
Currently, we have a lot of usages `Future.get` without a timeout in tests.
In case the test that uses `Future.get` is flaky it can lead to the whole suite
hang.
Is there any reason to use the get method without a timeout?
Can we
a. Replace all invocation of get with the timeou
It seems to be a good topic, but it seems to be left to the reviewer's
discretion.
08.12.2020, 18:36, "Nikolay Izhikov" :
> Hello, Igniters.
>
> Currently, we have a lot of usages `Future.get` without a timeout in tests.
> In case the test that uses `Future.get` is flaky it can lead to the whole
+1 for modules
08.12.2020, 16:02, "Andrey Gura" :
> Definitely agree with Alexey. Separating API declaration from
> implementation could really improve system design and avoid coupling.
>
> About extending @IgniteExperimental annotation. It doesn't look good
> to me. We should consider any API eit
Not only futures, there are a lot of latches, barriers etc. with same
problem.
вт, 8 дек. 2020 г. в 18:41, ткаленко кирилл :
> It seems to be a good topic, but it seems to be left to the reviewer's
> discretion.
>
> 08.12.2020, 18:36, "Nikolay Izhikov" :
> > Hello, Igniters.
> >
> > Currently, we
Hello Igniters,
I want to start voting on removing the public API (and eventually all
unused parts) related to the MVCC feature.
This topic has already been discussed many times (at least, [1], [2]) and
the community has agreed the feature implementation must be reapproached,
because using coordi
Hi Sumit,
Thanks for catching the issue and preparing a pull-request! The
pull-request merges changes to your Ignite master branch rather than to the
Ignite master. Not a bid deal. I see where the problem is. @Nikita Safonov
, @Viktor Chemodanov ,
could any of your correct the broken link on the p
+1 for sure. AFAIK, the only thing holding us back from using Java 11 is the
dominance of Java 8, but I'm sure that by the time Ignite 3 is GA, there will
be much fewer Java 8 users if any significant number at all. By the by,
Ignite's sources need minimal effort to be able to be compiled with J
+1
On Tue, Dec 8, 2020 at 8:31 AM Вячеслав Коптилин
wrote:
> Hello Igniters,
>
> I want to start voting on removing the public API (and eventually all
> unused parts) related to the MVCC feature.
>
> This topic has already been discussed many times (at least, [1], [2]) and
> the community has ag
+1
> 8 дек. 2020 г., в 21:54, Valentin Kulichenko
> написал(а):
>
> +1
>
> On Tue, Dec 8, 2020 at 8:31 AM Вячеслав Коптилин
> wrote:
>
>> Hello Igniters,
>>
>> I want to start voting on removing the public API (and eventually all
>> unused parts) related to the MVCC feature.
>>
>> This top
+1 to Alexey's ideas.
As for annotations, I actually can see the difference between Expirimental
and NonStable. The latter means that a feature works, but its API can still
be changed (in other words, no backwards compatibility guarantees). The
former is just something that is under development, c
+1
On Tue, Dec 8, 2020 at 10:02 PM Nikolay Izhikov wrote:
>
> +1
>
> > 8 дек. 2020 г., в 21:54, Valentin Kulichenko
> > написал(а):
> >
> > +1
> >
> > On Tue, Dec 8, 2020 at 8:31 AM Вячеслав Коптилин
> > wrote:
> >
> >> Hello Igniters,
> >>
> >> I want to start voting on removing the public AP
+1
08.12.2020 22:38, Andrey Gura пишет:
+1
On Tue, Dec 8, 2020 at 10:02 PM Nikolay Izhikov wrote:
+1
8 дек. 2020 г., в 21:54, Valentin Kulichenko
написал(а):
+1
On Tue, Dec 8, 2020 at 8:31 AM Вячеслав Коптилин
wrote:
Hello Igniters,
I want to start voting on removing the public API
+1
On Tue, Dec 8, 2020 at 11:22 PM Igor Seliverstov
wrote:
> +1
>
> 08.12.2020 22:38, Andrey Gura пишет:
> > +1
> >
> > On Tue, Dec 8, 2020 at 10:02 PM Nikolay Izhikov
> wrote:
> >> +1
> >>
> >>> 8 дек. 2020 г., в 21:54, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> написал(а):
> >>>
>
Roman created IGNITE-13830:
--
Summary: SQL COPY command: implement table and column names
escaping
Key: IGNITE-13830
URL: https://issues.apache.org/jira/browse/IGNITE-13830
Project: Ignite
Issue Typ
+1
08.12.2020, 23:47, "Andrey Mashenkov" :
> +1
>
> On Tue, Dec 8, 2020 at 11:22 PM Igor Seliverstov
> wrote:
>
>> +1
>>
>> 08.12.2020 22:38, Andrey Gura пишет:
>> > +1
>> >
>> > On Tue, Dec 8, 2020 at 10:02 PM Nikolay Izhikov
>> wrote:
>> >> +1
>> >>
>> >>> 8 дек. 2020 г., в 21:54, Va
+1
ср, 9 дек. 2020 г. в 08:29, ткаленко кирилл :
>
> +1
>
>
> 08.12.2020, 23:47, "Andrey Mashenkov" :
> > +1
> >
> > On Tue, Dec 8, 2020 at 11:22 PM Igor Seliverstov
> > wrote:
> >
> >> +1
> >>
> >> 08.12.2020 22:38, Andrey Gura пишет:
> >> > +1
> >> >
> >> > On Tue, Dec 8, 2020 at 10:02 PM
Hello Nikolay, if i find out introduced features structure in some project, i
would prefer to choose different one )
>
>>
>>>Hello, Alexey.
>>>
>>>Think we can extend our @IgniteExperimental annotation.
>>>
>>>`@IgniteExperimental` - mark features that are truly experimental and can be
>>>c
+1
> On 9 Dec 2020, at 09:39, Nikita Amelchev wrote:
>
> +1
>
> ср, 9 дек. 2020 г. в 08:29, ткаленко кирилл :
>>
>> +1
>>
>>
>> 08.12.2020, 23:47, "Andrey Mashenkov" :
>>> +1
>>>
>>> On Tue, Dec 8, 2020 at 11:22 PM Igor Seliverstov
>>> wrote:
>>>
+1
08.12.2020 22:38, Andr
Conversation shifted into an unintended direction, but I agree.
I think that if API can (or will) be changed then it should be deprecated.
For that
we can introduce @IgniteDeprecated that will contain Ignite version when
API is planned to be removed. Otherwise it's either stable or experimental.
H
This is an awesome idea.
Honestly, I can't come up with strong technical arguments for Java 11 as a
source level, I had no chance to work with it long enough, but it feels
like a
proper time to move to a "modern" technology. Subjectively I can say that
Java 11 has a lot of good optimization and Ig
+1
ср, 9 дек. 2020 г. в 10:03, Petr Ivanov :
> +1
>
>
> > On 9 Dec 2020, at 09:39, Nikita Amelchev wrote:
> >
> > +1
> >
> > ср, 9 дек. 2020 г. в 08:29, ткаленко кирилл :
> >>
> >> +1
> >>
> >>
> >> 08.12.2020, 23:47, "Andrey Mashenkov" :
> >>> +1
> >>>
> >>> On Tue, Dec 8, 2020 at 11:22 PM Igor
I think we should move forward, so java11 seems like a proper choice for 3.
ср, 9 дек. 2020 г. в 10:17, Ivan Bessonov :
> This is an awesome idea.
>
> Honestly, I can't come up with strong technical arguments for Java 11 as a
> source level, I had no chance to work with it long enough, but it fee
Hello, Zhenya, Ivan.
> Hello Nikolay, if i find out introduced features structure in some project, i
> would prefer to choose different one )
Many, of the real world users disagree with you.
Please, take a look at some examples from widely used projects:
Kafka -
https://github.com/apache/kafka
35 matches
Mail list logo
