Abbreviation code-style requirement.

[Dmitriy Pavlov]

Hi Yakov, thank you for your efforts.

I think no one is suggesting de-abbreviate, it would be no-sense work to
do. I think the initial reason to start this discussion was the case when
abbreviation seemed as hiding meaning, and multi-word. I'm glad we agree
multiword complex variables may be non-abbreviated if it is meaningful.

Vyacheslav D.,

could you please take a look and would you like to change abbrev plugin
rules?

Sincerely,
Dmitriy Pavlov

чт, 1 нояб. 2018 г. в 17:27, Yakov Zhdanov <[hidden email]>:

> Igniters,
>
> I have shortened the list of abbreviation rules and edited our wiki page -
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.
> Thanks to Vladimir Ozerov and Alexey Goncharuk for their useful feedback.
> My idea was to leave only "common sense" abbreviations and those that are
> Ignite domain specific.
>
> I would also suggest that we treat names mentioned in the table on the page
> as names that are required to be abbreviated. Please take this into account
> when conducting code reviews.
>
> Thanks!
>
> --Yakov
>

[daradurvs]

Hi Dmitry, it's easy to update abbrev plugin rules.

Once nobody has objections about updated abbreviations list I'll do it.
On Thu, Nov 1, 2018 at 5:33 PM Dmitriy Pavlov <[hidden email]> wrote:

>
> Hi Yakov, thank you for your efforts.
>
> I think no one is suggesting de-abbreviate, it would be no-sense work to do. I think the initial reason to start this discussion was the case when abbreviation seemed as hiding meaning, and multi-word. I'm glad we agree multiword complex variables may be non-abbreviated if it is meaningful.
>
> Vyacheslav D.,
>
> could you please take a look and would you like to change abbrev plugin rules?
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 1 нояб. 2018 г. в 17:27, Yakov Zhdanov <[hidden email]>:
>>
>> Igniters,
>>
>> I have shortened the list of abbreviation rules and edited our wiki page -
>> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.
>> Thanks to Vladimir Ozerov and Alexey Goncharuk for their useful feedback.
>> My idea was to leave only "common sense" abbreviations and those that are
>> Ignite domain specific.
>>
>> I would also suggest that we treat names mentioned in the table on the page
>> as names that are required to be abbreviated. Please take this into account
>> when conducting code reviews.
>>
>> Thanks!
>>
>> --Yakov

--
Best Regards, Vyacheslav D.

[Ivan Pavlukhin]

Hi Yakov and all,

Recently I went through abbreviations list [1] to find items which are not
clear
for me. After the list was shortened by Yakov and others most of them have
gone.
But pay attention to "lic -> license". I cannot find usages of it in Ignite
codebase?
Could it be removed as well?

And a little follow up. I worry how comfortable is contribution for an
external
contributor with presence of abbreviation rules. I always thought that long
names are common practice in Java world. And our abbreviations might
distract
a typical Java engineer. Does it make any sense?

[1]
https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation

чт, 1 нояб. 2018 г. в 17:33, Dmitriy Pavlov <[hidden email]>:

> Hi Yakov, thank you for your efforts.
>
> I think no one is suggesting de-abbreviate, it would be no-sense work to
> do. I think the initial reason to start this discussion was the case when
> abbreviation seemed as hiding meaning, and multi-word. I'm glad we agree
> multiword complex variables may be non-abbreviated if it is meaningful.
>
> Vyacheslav D.,
>
> could you please take a look and would you like to change abbrev plugin
> rules?
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 1 нояб. 2018 г. в 17:27, Yakov Zhdanov <[hidden email]>:
>
> > Igniters,
> >
> > I have shortened the list of abbreviation rules and edited our wiki page
> -
> > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.
> > Thanks to Vladimir Ozerov and Alexey Goncharuk for their useful feedback.
> > My idea was to leave only "common sense" abbreviations and those that are
> > Ignite domain specific.
> >
> > I would also suggest that we treat names mentioned in the table on the
> page
> > as names that are required to be abbreviated. Please take this into
> account
> > when conducting code reviews.
> >
> > Thanks!
> >
> > --Yakov
> >
>

--
Best regards,
Ivan Pavlukhin

[Andrey Kuznetsov]

Ivan, I think it's harder to read others' code than write new code, so well
known abbreviations may be helpful. As for writing, it's a matter of habit,
and also abbeviation plugin is a good aid.

I like current abbreviation list, except 'fut'. Never saw this before
Ignite. 'f' or 'future' could look better to me. Also, futures often denote
some asynchronous action, and it could be more expressive to use the name
of the action as identifier instead of 'fut'.

чт, 1 нояб. 2018 г. в 17:46, Павлухин Иван <[hidden email]>:

> Hi Yakov and all,
>
> Recently I went through abbreviations list [1] to find items which are not
> clear
> for me. After the list was shortened by Yakov and others most of them have
> gone.
> But pay attention to "lic -> license". I cannot find usages of it in Ignite
> codebase?
> Could it be removed as well?
>
> And a little follow up. I worry how comfortable is contribution for an
> external
> contributor with presence of abbreviation rules. I always thought that long
> names are common practice in Java world. And our abbreviations might
> distract
> a typical Java engineer. Does it make any sense?
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation
>
> чт, 1 нояб. 2018 г. в 17:33, Dmitriy Pavlov <[hidden email]>:
>
> > Hi Yakov, thank you for your efforts.
> >
> > I think no one is suggesting de-abbreviate, it would be no-sense work to
> > do. I think the initial reason to start this discussion was the case when
> > abbreviation seemed as hiding meaning, and multi-word. I'm glad we agree
> > multiword complex variables may be non-abbreviated if it is meaningful.
> >
> > Vyacheslav D.,
> >
> > could you please take a look and would you like to change abbrev plugin
> > rules?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > чт, 1 нояб. 2018 г. в 17:27, Yakov Zhdanov <[hidden email]>:
> >
> > > Igniters,
> > >
> > > I have shortened the list of abbreviation rules and edited our wiki
> page
> > -
> > > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.
> > > Thanks to Vladimir Ozerov and Alexey Goncharuk for their useful
> feedback.
> > > My idea was to leave only "common sense" abbreviations and those that
> are
> > > Ignite domain specific.
> > >
> > > I would also suggest that we treat names mentioned in the table on the
> > page
> > > as names that are required to be abbreviated. Please take this into
> > account
> > > when conducting code reviews.
> > >
> > > Thanks!
> > >
> > > --Yakov
> > >
> >
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

--
Best regards,
  Andrey Kuznetsov.

[yzhdanov]

Ivan I removed "lic" from the list. Thanks for catch!

Agree with Andrey. After several code reviews newcomers will get used to
abbreviations.

Andrey, try searching for "fut" and make sure to have "Word" checked. You
will see plenty of usages. "f" is also ok for future in case it does not
bring confusion and does not hurt readability.

Let's keep using abbreviations and treat them as mandatory requirement.
This is important for keeping our codebase consistent and tidy.

--Yakov

[Ivan Pavlukhin]

Andrey, Yakov,

Actually my concert is more about one-time contributions. I imagine
the following. Someone finds a bug a decides to contribute a fix.
I think it is quite common scenario in Open Source.
He creates a PR and awaits a review. I think that a smooth and fast
review process will encourage for new contributions. But if the review
process is not such the contributor can simply give up.

P.S. In my mind there are quite uncommon code style rules in Ignite
project. But it is definitely not for that topic. I imagine some "New
Contributor Survey".

чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov <[hidden email]>:

> Ivan I removed "lic" from the list. Thanks for catch!
>
> Agree with Andrey. After several code reviews newcomers will get used to
> abbreviations.
>
> Andrey, try searching for "fut" and make sure to have "Word" checked. You
> will see plenty of usages. "f" is also ok for future in case it does not
> bring confusion and does not hurt readability.
>
> Let's keep using abbreviations and treat them as mandatory requirement.
> This is important for keeping our codebase consistent and tidy.
>
> --Yakov
>

--
Best regards,
Ivan Pavlukhin

[Andrey Kuznetsov]

Ivan, I agree with you: some our code style rules are really uncommon.

As for one-time contributions, if somebody decides to make a contribution
to some project, it's ok to adopt that project rules. Moreover, reviewing
committer can silently fix minor code style issues himself upon merge.

пт, 2 нояб. 2018 г. в 10:08, Павлухин Иван <[hidden email]>:

> Andrey, Yakov,
>
> Actually my concert is more about one-time contributions. I imagine
> the following. Someone finds a bug a decides to contribute a fix.
> I think it is quite common scenario in Open Source.
> He creates a PR and awaits a review. I think that a smooth and fast
> review process will encourage for new contributions. But if the review
> process is not such the contributor can simply give up.
>
> P.S. In my mind there are quite uncommon code style rules in Ignite
> project. But it is definitely not for that topic. I imagine some "New
> Contributor Survey".
>
> чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov <[hidden email]>:
>
> > Ivan I removed "lic" from the list. Thanks for catch!
> >
> > Agree with Andrey. After several code reviews newcomers will get used to
> > abbreviations.
> >
> > Andrey, try searching for "fut" and make sure to have "Word" checked. You
> > will see plenty of usages. "f" is also ok for future in case it does not
> > bring confusion and does not hurt readability.
> >
> > Let's keep using abbreviations and treat them as mandatory requirement.
> > This is important for keeping our codebase consistent and tidy.
> >
> > --Yakov
> >
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

--
Best regards,
  Andrey Kuznetsov.

[Dmitriy Pavlov]

Hi Ivan,

provided that committer has installed ignite-abbrev-plugin it is not a big
deal to abbreviate common words before a merge.

I had the same impression about abbreviations when I came to the project:
"all other development world tends to expose as much meaning as it is
humanly possible in code, but Ignite has abbreviations seemed to hide this
meaning".  But later I've used to most common abbreviations, like ctx, and
I always understand that this implies context.

Sincerely,
Dmitriy Pavlov

пт, 2 нояб. 2018 г. в 10:21, Andrey Kuznetsov <[hidden email]>:

> Ivan, I agree with you: some our code style rules are really uncommon.
>
> As for one-time contributions, if somebody decides to make a contribution
> to some project, it's ok to adopt that project rules. Moreover, reviewing
> committer can silently fix minor code style issues himself upon merge.
>
> пт, 2 нояб. 2018 г. в 10:08, Павлухин Иван <[hidden email]>:
>
> > Andrey, Yakov,
> >
> > Actually my concert is more about one-time contributions. I imagine
> > the following. Someone finds a bug a decides to contribute a fix.
> > I think it is quite common scenario in Open Source.
> > He creates a PR and awaits a review. I think that a smooth and fast
> > review process will encourage for new contributions. But if the review
> > process is not such the contributor can simply give up.
> >
> > P.S. In my mind there are quite uncommon code style rules in Ignite
> > project. But it is definitely not for that topic. I imagine some "New
> > Contributor Survey".
> >
> > чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov <[hidden email]>:
> >
> > > Ivan I removed "lic" from the list. Thanks for catch!
> > >
> > > Agree with Andrey. After several code reviews newcomers will get used
> to
> > > abbreviations.
> > >
> > > Andrey, try searching for "fut" and make sure to have "Word" checked.
> You
> > > will see plenty of usages. "f" is also ok for future in case it does
> not
> > > bring confusion and does not hurt readability.
> > >
> > > Let's keep using abbreviations and treat them as mandatory requirement.
> > > This is important for keeping our codebase consistent and tidy.
> > >
> > > --Yakov
> > >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>
>
> --
> Best regards,
>   Andrey Kuznetsov.
>

[Ivan Pavlukhin]

Andrey, Dmitry,

If we have a practice of formatting a code before merge by committer
then it is already much better. But do we have such a practice?

As for me personally. I have not felt much discomfort with abbreviations.
I already used them extensively. Even "cctx", "ccfg" which are not
mandatory today.

пт, 2 нояб. 2018 г. в 10:58, Dmitriy Pavlov <[hidden email]>:

> Hi Ivan,
>
> provided that committer has installed ignite-abbrev-plugin it is not a big
> deal to abbreviate common words before a merge.
>
> I had the same impression about abbreviations when I came to the project:
> "all other development world tends to expose as much meaning as it is
> humanly possible in code, but Ignite has abbreviations seemed to hide this
> meaning".  But later I've used to most common abbreviations, like ctx, and
> I always understand that this implies context.
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 2 нояб. 2018 г. в 10:21, Andrey Kuznetsov <[hidden email]>:
>
> > Ivan, I agree with you: some our code style rules are really uncommon.
> >
> > As for one-time contributions, if somebody decides to make a contribution
> > to some project, it's ok to adopt that project rules. Moreover, reviewing
> > committer can silently fix minor code style issues himself upon merge.
> >
> > пт, 2 нояб. 2018 г. в 10:08, Павлухин Иван <[hidden email]>:
> >
> > > Andrey, Yakov,
> > >
> > > Actually my concert is more about one-time contributions. I imagine
> > > the following. Someone finds a bug a decides to contribute a fix.
> > > I think it is quite common scenario in Open Source.
> > > He creates a PR and awaits a review. I think that a smooth and fast
> > > review process will encourage for new contributions. But if the review
> > > process is not such the contributor can simply give up.
> > >
> > > P.S. In my mind there are quite uncommon code style rules in Ignite
> > > project. But it is definitely not for that topic. I imagine some "New
> > > Contributor Survey".
> > >
> > > чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov <[hidden email]>:
> > >
> > > > Ivan I removed "lic" from the list. Thanks for catch!
> > > >
> > > > Agree with Andrey. After several code reviews newcomers will get used
> > to
> > > > abbreviations.
> > > >
> > > > Andrey, try searching for "fut" and make sure to have "Word" checked.
> > You
> > > > will see plenty of usages. "f" is also ok for future in case it does
> > not
> > > > bring confusion and does not hurt readability.
> > > >
> > > > Let's keep using abbreviations and treat them as mandatory
> requirement.
> > > > This is important for keeping our codebase consistent and tidy.
> > > >
> > > > --Yakov
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
> >
>

--
Best regards,
Ivan Pavlukhin

[daradurvs]

I've faced such practice.

Very first my contribution, when I have not been familiar with style
guidelines, Yakov Zhdanov kindly fixed code style issues himself.

I think it depends on a reviewer:
- in one case reviewer can fix issues independently
- in other case ask a contributor to solve them

On Fri, Nov 2, 2018 at 11:31 AM Павлухин Иван <[hidden email]> wrote:

>
> Andrey, Dmitry,
>
> If we have a practice of formatting a code before merge by committer
> then it is already much better. But do we have such a practice?
>
> As for me personally. I have not felt much discomfort with abbreviations.
> I already used them extensively. Even "cctx", "ccfg" which are not
> mandatory today.
>
> пт, 2 нояб. 2018 г. в 10:58, Dmitriy Pavlov <[hidden email]>:
>
> > Hi Ivan,
> >
> > provided that committer has installed ignite-abbrev-plugin it is not a big
> > deal to abbreviate common words before a merge.
> >
> > I had the same impression about abbreviations when I came to the project:
> > "all other development world tends to expose as much meaning as it is
> > humanly possible in code, but Ignite has abbreviations seemed to hide this
> > meaning".  But later I've used to most common abbreviations, like ctx, and
> > I always understand that this implies context.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 2 нояб. 2018 г. в 10:21, Andrey Kuznetsov <[hidden email]>:
> >
> > > Ivan, I agree with you: some our code style rules are really uncommon.
> > >
> > > As for one-time contributions, if somebody decides to make a contribution
> > > to some project, it's ok to adopt that project rules. Moreover, reviewing
> > > committer can silently fix minor code style issues himself upon merge.
> > >
> > > пт, 2 нояб. 2018 г. в 10:08, Павлухин Иван <[hidden email]>:
> > >
> > > > Andrey, Yakov,
> > > >
> > > > Actually my concert is more about one-time contributions. I imagine
> > > > the following. Someone finds a bug a decides to contribute a fix.
> > > > I think it is quite common scenario in Open Source.
> > > > He creates a PR and awaits a review. I think that a smooth and fast
> > > > review process will encourage for new contributions. But if the review
> > > > process is not such the contributor can simply give up.
> > > >
> > > > P.S. In my mind there are quite uncommon code style rules in Ignite
> > > > project. But it is definitely not for that topic. I imagine some "New
> > > > Contributor Survey".
> > > >
> > > > чт, 1 нояб. 2018 г. в 18:28, Yakov Zhdanov <[hidden email]>:
> > > >
> > > > > Ivan I removed "lic" from the list. Thanks for catch!
> > > > >
> > > > > Agree with Andrey. After several code reviews newcomers will get used
> > > to
> > > > > abbreviations.
> > > > >
> > > > > Andrey, try searching for "fut" and make sure to have "Word" checked.
> > > You
> > > > > will see plenty of usages. "f" is also ok for future in case it does
> > > not
> > > > > bring confusion and does not hurt readability.
> > > > >
> > > > > Let's keep using abbreviations and treat them as mandatory
> > requirement.
> > > > > This is important for keeping our codebase consistent and tidy.
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > >   Andrey Kuznetsov.
> > >
> >
>
>
> --
> Best regards,
> Ivan Pavlukhin

--
Best Regards, Vyacheslav D.

[yzhdanov]

Agree with Vyacheslav - reviewers can either fix the issues or ask to fix
them. After several PRs new contributors will get used with project
requirements.

As far as one time contributions, they are usually pretty simple and should
not take any significant time to fix. If one time contirbutor returns with
more contributions then he or she should account all the changes made on
review and, again, come to a point where all project requirements are
staisfied.

Btw, Vyacheslav, can we have abbreviations.properties in the project under
git and have plugin use it?

--Yakov

[daradurvs]

Yes, it's under git already in Dmitry Pavlov's GitHub account [1].
AFAIK donation to ASF is in progress [2]. (Dmitry Pavlov, please,
correct me if I'm wrong)

[1] https://github.com/dspavlov/ignite-abbrev-plugin/blob/master/src/abbreviation.properties
[2] http://apache-ignite-developers.2346864.n4.nabble.com/Re-Place-Ignite-Abbrev-Plugin-to-ASF-Ignite-supplementary-git-repo-tp32745p32764.html
On Fri, Nov 2, 2018 at 12:30 PM Yakov Zhdanov <[hidden email]> wrote:

>
> Agree with Vyacheslav - reviewers can either fix the issues or ask to fix
> them. After several PRs new contributors will get used with project
> requirements.
>
> As far as one time contributions, they are usually pretty simple and should
> not take any significant time to fix. If one time contirbutor returns with
> more contributions then he or she should account all the changes made on
> review and, again, come to a point where all project requirements are
> staisfied.
>
> Btw, Vyacheslav, can we have abbreviations.properties in the project under
> git and have plugin use it?
>
> --Yakov

--
Best Regards, Vyacheslav D.

[yzhdanov]

No, I meant under Ignite's git so any change to resource file arrives with
project workspace updates and gets automatically picked up by plugin.

Makes sense?

--Yakov

[daradurvs]

I like your idea about auto updates.

In this case, abbr-plugin should be improved to check and download
updates from external URI or local repo.
Looks like it could be implemented using Intellij's SDK virtual file [1].

But as I can see that abbreviations list update is the very rare case,
therefore I'm not sure that we really need to do it.

Also, I have another idea we can try to use IDEA inspections and it's
naming conventions rules.
IDEA inspections are under the project's git already.

[1] https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html
On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov <[hidden email]> wrote:
>
> No, I meant under Ignite's git so any change to resource file arrives with
> project workspace updates and gets automatically picked up by plugin.
>
> Makes sense?
>
> --Yakov



--
Best Regards, Vyacheslav D.

[daradurvs]

I've double checked, we are really able to use IDEA inspection's to
inspect abbreviations by inspection's structure search and replace
templates.
It rather not intuitive and requires complex regex patterns.

Also, at first sight, it shouldn't be difficult to work with the
project's local properties from the plugin.

On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur <[hidden email]> wrote:

>
> I like your idea about auto updates.
>
> In this case, abbr-plugin should be improved to check and download
> updates from external URI or local repo.
> Looks like it could be implemented using Intellij's SDK virtual file [1].
>
> But as I can see that abbreviations list update is the very rare case,
> therefore I'm not sure that we really need to do it.
>
> Also, I have another idea we can try to use IDEA inspections and it's
> naming conventions rules.
> IDEA inspections are under the project's git already.
>
> [1] https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html
> On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov <[hidden email]> wrote:
> >
> > No, I meant under Ignite's git so any change to resource file arrives with
> > project workspace updates and gets automatically picked up by plugin.
> >
> > Makes sense?
> >
> > --Yakov
>
>
>
> --
> Best Regards, Vyacheslav D.

--
Best Regards, Vyacheslav D.

[Dmitriy Pavlov]

Hi Vyacheslav,

I'm sorry I almost gave up with this donation

http://apache-ignite-developers.2346864.n4.nabble.com/Re-Place-Ignite-Abbrev-Plugin-to-ASF-Ignite-supplementary-git-repo-tp32745p32764.html
because
we need someone to sign a software grant agreement, but there were several
people who contributed to the plugin.

Some of the authors are not active contributors anymore. So I've stuck with
finding a way how to donate.

Sincerely,
Dmitriy Pavlov

пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur <[hidden email]>:

> I've double checked, we are really able to use IDEA inspection's to
> inspect abbreviations by inspection's structure search and replace
> templates.
> It rather not intuitive and requires complex regex patterns.
>
> Also, at first sight, it shouldn't be difficult to work with the
> project's local properties from the plugin.
>
> On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur <[hidden email]>
> wrote:
> >
> > I like your idea about auto updates.
> >
> > In this case, abbr-plugin should be improved to check and download
> > updates from external URI or local repo.
> > Looks like it could be implemented using Intellij's SDK virtual file [1].
> >
> > But as I can see that abbreviations list update is the very rare case,
> > therefore I'm not sure that we really need to do it.
> >
> > Also, I have another idea we can try to use IDEA inspections and it's
> > naming conventions rules.
> > IDEA inspections are under the project's git already.
> >
> > [1]
> https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html
> > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov <[hidden email]>
> wrote:
> > >
> > > No, I meant under Ignite's git so any change to resource file arrives
> with
> > > project workspace updates and gets automatically picked up by plugin.
> > >
> > > Makes sense?
> > >
> > > --Yakov
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[Ivan Pavlukhin]

Hi Dmitriy, Vyacheslav,

I created a ticket [1] and PR [2] for updating a list of abbreviations
used by the plugin. The changes in the plugin itself looks trivial.
But some extra build and publish steps are required (see the ticket).
Also if I understand it correctly plugin should be build with scala
support. I will need some time to ensure that I can build it properly.

[1] https://issues.apache.org/jira/browse/IGNITE-10704
[2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2

2018-11-02 21:38 GMT+03:00, Dmitriy Pavlov <[hidden email]>:

> Hi Vyacheslav,
>
> I'm sorry I almost gave up with this donation
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Place-Ignite-Abbrev-Plugin-to-ASF-Ignite-supplementary-git-repo-tp32745p32764.html
> because
> we need someone to sign a software grant agreement, but there were several
> people who contributed to the plugin.
>
> Some of the authors are not active contributors anymore. So I've stuck with
> finding a way how to donate.
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur <[hidden email]>:
>
>> I've double checked, we are really able to use IDEA inspection's to
>> inspect abbreviations by inspection's structure search and replace
>> templates.
>> It rather not intuitive and requires complex regex patterns.
>>
>> Also, at first sight, it shouldn't be difficult to work with the
>> project's local properties from the plugin.
>>
>> On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur <[hidden email]>
>> wrote:
>> >
>> > I like your idea about auto updates.
>> >
>> > In this case, abbr-plugin should be improved to check and download
>> > updates from external URI or local repo.
>> > Looks like it could be implemented using Intellij's SDK virtual file
>> > [1].
>> >
>> > But as I can see that abbreviations list update is the very rare case,
>> > therefore I'm not sure that we really need to do it.
>> >
>> > Also, I have another idea we can try to use IDEA inspections and it's
>> > naming conventions rules.
>> > IDEA inspections are under the project's git already.
>> >
>> > [1]
>> https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html
>> > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov <[hidden email]>
>> wrote:
>> > >
>> > > No, I meant under Ignite's git so any change to resource file arrives
>> with
>> > > project workspace updates and gets automatically picked up by plugin.
>> > >
>> > > Makes sense?
>> > >
>> > > --Yakov
>> >
>> >
>> >
>> > --
>> > Best Regards, Vyacheslav D.
>>
>>
>>
>> --
>> Best Regards, Vyacheslav D.
>>
>

--
Best regards,
Ivan Pavlukhin

[daradurvs]

Ivan, thank you!

PR looks good to me in general, but I've noticed a possible typo in
the PR and Wiki:
'lable' -> 'label'

Also, according to the wiki, the following rules should be added:
'topologyVersion' -> 'topVer'
'regularExpression' -> 'regex'

Am I miss something?

On Sat, Dec 15, 2018 at 11:17 AM Павлухин Иван <[hidden email]> wrote:

>
> Hi Dmitriy, Vyacheslav,
>
> I created a ticket [1] and PR [2] for updating a list of abbreviations
> used by the plugin. The changes in the plugin itself looks trivial.
> But some extra build and publish steps are required (see the ticket).
> Also if I understand it correctly plugin should be build with scala
> support. I will need some time to ensure that I can build it properly.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10704
> [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2
>
> 2018-11-02 21:38 GMT+03:00, Dmitriy Pavlov <[hidden email]>:
> > Hi Vyacheslav,
> >
> > I'm sorry I almost gave up with this donation
> >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Re-Place-Ignite-Abbrev-Plugin-to-ASF-Ignite-supplementary-git-repo-tp32745p32764.html
> > because
> > we need someone to sign a software grant agreement, but there were several
> > people who contributed to the plugin.
> >
> > Some of the authors are not active contributors anymore. So I've stuck with
> > finding a way how to donate.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur <[hidden email]>:
> >
> >> I've double checked, we are really able to use IDEA inspection's to
> >> inspect abbreviations by inspection's structure search and replace
> >> templates.
> >> It rather not intuitive and requires complex regex patterns.
> >>
> >> Also, at first sight, it shouldn't be difficult to work with the
> >> project's local properties from the plugin.
> >>
> >> On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur <[hidden email]>
> >> wrote:
> >> >
> >> > I like your idea about auto updates.
> >> >
> >> > In this case, abbr-plugin should be improved to check and download
> >> > updates from external URI or local repo.
> >> > Looks like it could be implemented using Intellij's SDK virtual file
> >> > [1].
> >> >
> >> > But as I can see that abbreviations list update is the very rare case,
> >> > therefore I'm not sure that we really need to do it.
> >> >
> >> > Also, I have another idea we can try to use IDEA inspections and it's
> >> > naming conventions rules.
> >> > IDEA inspections are under the project's git already.
> >> >
> >> > [1]
> >> https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html
> >> > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov <[hidden email]>
> >> wrote:
> >> > >
> >> > > No, I meant under Ignite's git so any change to resource file arrives
> >> with
> >> > > project workspace updates and gets automatically picked up by plugin.
> >> > >
> >> > > Makes sense?
> >> > >
> >> > > --Yakov
> >> >
> >> >
> >> >
> >> > --
> >> > Best Regards, Vyacheslav D.
> >>
> >>
> >>
> >> --
> >> Best Regards, Vyacheslav D.
> >>
> >
>
>
> --
> Best regards,
> Ivan Pavlukhin

--
Best Regards, Vyacheslav D.

[Ivan Pavlukhin]

Vyacheslav,

> PR looks good to me in general, but I've noticed a possible typo in
> the PR and Wiki:
> 'lable' -> 'label'

Good catch! I updated a PR [1]. Could someone fix it on wiki or give
me rights to edit wiki? (my login is "pavlukhin")

> Also, according to the wiki, the following rules should be added:
> 'topologyVersion' -> 'topVer'
> 'regularExpression' -> 'regex'

Actually, the plugin operates with tokens which are determined
assuming camel-case naming style. So, "topologyVersion" will be split
to "topology" and "Version" and converted to "topVer" by transforming
each token. But we cannot do so with "regularExpression" because there
is no rules for "regular" and "expression". And even if we had such it
would produce "regEx". Adding a rule "regularExpression=regex" to
abbreviation.properties does not lead to desired effect.

[1] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2

2018-12-15 12:13 GMT+03:00, Vyacheslav Daradur <[hidden email]>:

> Ivan, thank you!
>
> PR looks good to me in general, but I've noticed a possible typo in
> the PR and Wiki:
> 'lable' -> 'label'
>
> Also, according to the wiki, the following rules should be added:
> 'topologyVersion' -> 'topVer'
> 'regularExpression' -> 'regex'
>
> Am I miss something?
>
> On Sat, Dec 15, 2018 at 11:17 AM Павлухин Иван <[hidden email]> wrote:
>>
>> Hi Dmitriy, Vyacheslav,
>>
>> I created a ticket [1] and PR [2] for updating a list of abbreviations
>> used by the plugin. The changes in the plugin itself looks trivial.
>> But some extra build and publish steps are required (see the ticket).
>> Also if I understand it correctly plugin should be build with scala
>> support. I will need some time to ensure that I can build it properly.
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-10704
>> [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2
>>
>> 2018-11-02 21:38 GMT+03:00, Dmitriy Pavlov <[hidden email]>:
>> > Hi Vyacheslav,
>> >
>> > I'm sorry I almost gave up with this donation
>> >
>> > http://apache-ignite-developers.2346864.n4.nabble.com/Re-Place-Ignite-Abbrev-Plugin-to-ASF-Ignite-supplementary-git-repo-tp32745p32764.html
>> > because
>> > we need someone to sign a software grant agreement, but there were
>> > several
>> > people who contributed to the plugin.
>> >
>> > Some of the authors are not active contributors anymore. So I've stuck
>> > with
>> > finding a way how to donate.
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur <[hidden email]>:
>> >
>> >> I've double checked, we are really able to use IDEA inspection's to
>> >> inspect abbreviations by inspection's structure search and replace
>> >> templates.
>> >> It rather not intuitive and requires complex regex patterns.
>> >>
>> >> Also, at first sight, it shouldn't be difficult to work with the
>> >> project's local properties from the plugin.
>> >>
>> >> On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur
>> >> <[hidden email]>
>> >> wrote:
>> >> >
>> >> > I like your idea about auto updates.
>> >> >
>> >> > In this case, abbr-plugin should be improved to check and download
>> >> > updates from external URI or local repo.
>> >> > Looks like it could be implemented using Intellij's SDK virtual file
>> >> > [1].
>> >> >
>> >> > But as I can see that abbreviations list update is the very rare
>> >> > case,
>> >> > therefore I'm not sure that we really need to do it.
>> >> >
>> >> > Also, I have another idea we can try to use IDEA inspections and
>> >> > it's
>> >> > naming conventions rules.
>> >> > IDEA inspections are under the project's git already.
>> >> >
>> >> > [1]
>> >> https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html
>> >> > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov <[hidden email]>
>> >> wrote:
>> >> > >
>> >> > > No, I meant under Ignite's git so any change to resource file
>> >> > > arrives
>> >> with
>> >> > > project workspace updates and gets automatically picked up by
>> >> > > plugin.
>> >> > >
>> >> > > Makes sense?
>> >> > >
>> >> > > --Yakov
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Best Regards, Vyacheslav D.
>> >>
>> >>
>> >>
>> >> --
>> >> Best Regards, Vyacheslav D.
>> >>
>> >
>>
>>
>> --
>> Best regards,
>> Ivan Pavlukhin
>
>
>
> --
> Best Regards, Vyacheslav D.
>

--
Best regards,
Ivan Pavlukhin

[Ivan Pavlukhin]

Hi,

I did some investigation regarding scala support and it seems that
version used today (3.0.0) was build without scala support. If nobody
minds I suggest to build a new version without scala as well.

Also there is a thing that bothers me a little. IDEA throws exception
in log when a name is abbreviated by plugin (see at the very bottom of
this message). I build old version on my machine as well and received
the same. It seems that it was there before my changes. Or it might be
somehow related to version of IDEA which I used to build the plugin.

2018-12-17 13:35:10,849 [  21351]  ERROR -
oring.BaseRefactoringProcessor - Refactorings should not be started
inside write action
 because they start progress inside and any read action from the
progress task would cause the deadlock
java.lang.Exception
    at com.intellij.refactoring.BaseRefactoringProcessor.run(BaseRefactoringProcessor.java:560)
    at com.intellij.refactoring.RefactoringImpl.run(RefactoringImpl.java:73)
    at org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.rename(IgniteAbbreviationInspection.java:163)
    at org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:148)
    at org.apache.ignite.idea.inspection.abbrev.IgniteAbbreviationInspection$RenameToFix.applyFix(IgniteAbbreviationInspection.java:121)
    at com.intellij.codeInspection.ex.QuickFixWrapper.invoke(QuickFixWrapper.java:75)
    at com.intellij.codeInsight.intention.impl.IntentionActionWithTextCaching$MyIntentionAction.invoke(IntentionActionWithTextCaching.java:173)
    at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$invokeIntention$3(ShowIntentionActionsHandler.java:202)
    at com.intellij.openapi.application.WriteAction.run(WriteAction.java:105)
    at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.invokeIntention(ShowIntentionActionsHandler.java:204)
    at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$null$1(ShowIntentionActionsHandler.java:179)
    at com.intellij.openapi.application.TransactionGuardImpl.runSyncTransaction(TransactionGuardImpl.java:88)
    at com.intellij.openapi.application.TransactionGuardImpl.submitTransactionAndWait(TransactionGuardImpl.java:153)
    at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.lambda$chooseActionAndInvoke$2(ShowIntentionActionsHandler.java:178)
    at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:139)
    at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:97)
    at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:87)
    at com.intellij.openapi.command.impl.CoreCommandProcessor.executeCommand(CoreCommandProcessor.java:73)
    at com.intellij.codeInsight.intention.impl.ShowIntentionActionsHandler.chooseActionAndInvoke(ShowIntentionActionsHandler.java:177)
    at com.intellij.codeInsight.intention.impl.IntentionListStep.lambda$applyAction$0(IntentionListStep.java:118)
    at com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:195)
    at com.intellij.ui.popup.AbstractPopup.lambda$dispose$8(AbstractPopup.java:1417)
    at com.intellij.util.ui.UIUtil.invokeLaterIfNeeded(UIUtil.java:3097)
    at com.intellij.ide.IdeEventQueue.ifFocusEventsInTheQueue(IdeEventQueue.java:183)
    at com.intellij.ide.IdeEventQueue.executeWhenAllFocusEventsLeftTheQueue(IdeEventQueue.java:132)
    at com.intellij.openapi.wm.impl.FocusManagerImpl.doWhenFocusSettlesDown(FocusManagerImpl.java:190)
    at com.intellij.openapi.wm.impl.IdeFocusManagerImpl.doWhenFocusSettlesDown(IdeFocusManagerImpl.java:58)
    at com.intellij.ui.popup.AbstractPopup.dispose(AbstractPopup.java:1411)
    at com.intellij.ui.popup.WizardPopup.dispose(WizardPopup.java:160)
    at com.intellij.ui.popup.list.ListPopupImpl.dispose(ListPopupImpl.java:307)
    at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:48)
    at com.intellij.openapi.util.Disposer$1.execute(Disposer.java:44)
    at com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:138)
    at com.intellij.openapi.util.objectTree.ObjectNode$1.execute(ObjectNode.java:107)
    at com.intellij.openapi.util.objectTree.ObjectTree.executeActionWithRecursiveGuard(ObjectTree.java:182)
    at com.intellij.openapi.util.objectTree.ObjectNode.execute(ObjectNode.java:107)
    at com.intellij.openapi.util.objectTree.ObjectTree.executeAll(ObjectTree.java:151)
    at com.intellij.openapi.util.Disposer.dispose(Disposer.java:129)
    at com.intellij.openapi.util.Disposer.dispose(Disposer.java:125)
    at com.intellij.ui.popup.WizardPopup.disposeAllParents(WizardPopup.java:263)
    at com.intellij.ui.popup.list.ListPopupImpl.handleNextStep(ListPopupImpl.java:442)
    at com.intellij.ui.popup.list.ListPopupImpl._handleSelect(ListPopupImpl.java:396)
    at com.intellij.ui.popup.list.ListPopupImpl.handleSelect(ListPopupImpl.java:337)
    at com.intellij.ui.popup.list.ListPopupImpl$1.actionPerformed(ListPopupImpl.java:250)
    at com.intellij.ui.popup.WizardPopup.proceedKeyEvent(WizardPopup.java:378)
    at com.intellij.ui.popup.WizardPopup.dispatch(WizardPopup.java:358)
    at com.intellij.ui.popup.PopupDispatcher.dispatchKeyEvent(PopupDispatcher.java:126)
    at com.intellij.ui.popup.PopupDispatcher.dispatch(PopupDispatcher.java:160)
    at com.intellij.ide.IdePopupManager.dispatch(IdePopupManager.java:86)
    at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:673)
    at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:382)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
сб, 15 дек. 2018 г. в 17:37, Павлухин Иван <[hidden email]>:

>
> Vyacheslav,
>
> > PR looks good to me in general, but I've noticed a possible typo in
> > the PR and Wiki:
> > 'lable' -> 'label'
>
> Good catch! I updated a PR [1]. Could someone fix it on wiki or give
> me rights to edit wiki? (my login is "pavlukhin")
>
> > Also, according to the wiki, the following rules should be added:
> > 'topologyVersion' -> 'topVer'
> > 'regularExpression' -> 'regex'
>
> Actually, the plugin operates with tokens which are determined
> assuming camel-case naming style. So, "topologyVersion" will be split
> to "topology" and "Version" and converted to "topVer" by transforming
> each token. But we cannot do so with "regularExpression" because there
> is no rules for "regular" and "expression". And even if we had such it
> would produce "regEx". Adding a rule "regularExpression=regex" to
> abbreviation.properties does not lead to desired effect.
>
> [1] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2
>
> 2018-12-15 12:13 GMT+03:00, Vyacheslav Daradur <[hidden email]>:
> > Ivan, thank you!
> >
> > PR looks good to me in general, but I've noticed a possible typo in
> > the PR and Wiki:
> > 'lable' -> 'label'
> >
> > Also, according to the wiki, the following rules should be added:
> > 'topologyVersion' -> 'topVer'
> > 'regularExpression' -> 'regex'
> >
> > Am I miss something?
> >
> > On Sat, Dec 15, 2018 at 11:17 AM Павлухин Иван <[hidden email]> wrote:
> >>
> >> Hi Dmitriy, Vyacheslav,
> >>
> >> I created a ticket [1] and PR [2] for updating a list of abbreviations
> >> used by the plugin. The changes in the plugin itself looks trivial.
> >> But some extra build and publish steps are required (see the ticket).
> >> Also if I understand it correctly plugin should be build with scala
> >> support. I will need some time to ensure that I can build it properly.
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-10704
> >> [2] https://github.com/dspavlov/ignite-abbrev-plugin/pull/2
> >>
> >> 2018-11-02 21:38 GMT+03:00, Dmitriy Pavlov <[hidden email]>:
> >> > Hi Vyacheslav,
> >> >
> >> > I'm sorry I almost gave up with this donation
> >> >
> >> > http://apache-ignite-developers.2346864.n4.nabble.com/Re-Place-Ignite-Abbrev-Plugin-to-ASF-Ignite-supplementary-git-repo-tp32745p32764.html
> >> > because
> >> > we need someone to sign a software grant agreement, but there were
> >> > several
> >> > people who contributed to the plugin.
> >> >
> >> > Some of the authors are not active contributors anymore. So I've stuck
> >> > with
> >> > finding a way how to donate.
> >> >
> >> > Sincerely,
> >> > Dmitriy Pavlov
> >> >
> >> > пт, 2 нояб. 2018 г. в 21:24, Vyacheslav Daradur <[hidden email]>:
> >> >
> >> >> I've double checked, we are really able to use IDEA inspection's to
> >> >> inspect abbreviations by inspection's structure search and replace
> >> >> templates.
> >> >> It rather not intuitive and requires complex regex patterns.
> >> >>
> >> >> Also, at first sight, it shouldn't be difficult to work with the
> >> >> project's local properties from the plugin.
> >> >>
> >> >> On Fri, Nov 2, 2018 at 2:32 PM Vyacheslav Daradur
> >> >> <[hidden email]>
> >> >> wrote:
> >> >> >
> >> >> > I like your idea about auto updates.
> >> >> >
> >> >> > In this case, abbr-plugin should be improved to check and download
> >> >> > updates from external URI or local repo.
> >> >> > Looks like it could be implemented using Intellij's SDK virtual file
> >> >> > [1].
> >> >> >
> >> >> > But as I can see that abbreviations list update is the very rare
> >> >> > case,
> >> >> > therefore I'm not sure that we really need to do it.
> >> >> >
> >> >> > Also, I have another idea we can try to use IDEA inspections and
> >> >> > it's
> >> >> > naming conventions rules.
> >> >> > IDEA inspections are under the project's git already.
> >> >> >
> >> >> > [1]
> >> >> https://www.jetbrains.org/intellij/sdk/docs/basics/architectural_overview/virtual_file.html
> >> >> > On Fri, Nov 2, 2018 at 1:47 PM Yakov Zhdanov <[hidden email]>
> >> >> wrote:
> >> >> > >
> >> >> > > No, I meant under Ignite's git so any change to resource file
> >> >> > > arrives
> >> >> with
> >> >> > > project workspace updates and gets automatically picked up by
> >> >> > > plugin.
> >> >> > >
> >> >> > > Makes sense?
> >> >> > >
> >> >> > > --Yakov
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Best Regards, Vyacheslav D.
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Best Regards, Vyacheslav D.
> >> >>
> >> >
> >>
> >>
> >> --
> >> Best regards,
> >> Ivan Pavlukhin
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>
>
> --
> Best regards,
> Ivan Pavlukhin

--
Best regards,
Ivan Pavlukhin