You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Michael Vorburger <mi...@vorburger.ch> on 2020/01/11 01:20:50 UTC
Checkstyle for Fineract source code
Hello,
I've started with https://issues.apache.org/jira/browse/FINERACT-821 re.
adopting Checkstyle for Fineract source code.
Would anyone be interested in helping with this effort?
Best,
M.
_______________________
Michael Vorburger
http://www.vorburger.ch
Re: Checkstyle for Fineract source code
Posted by Michael Vorburger <mi...@vorburger.ch>.
With Manthan now well under way re. Checkstyle, see his recently merged and
ongoing PRs, I'd like him to just focus on fully completing that ASAP.
The reality is that we have never heard back on this thread in the 4 months
since January, and there was not a single PR (from other parties, other
than Manthan's work)... so... yeah. "Hope is not a strategy" ? ;-)
IMHO there is no need for more fine grained sub-tasks in JIRA. Suddenly
assigning multiple developers now may cause more overhead than gain at this
stage IMHO. Manthan will get this done.
On Thu, May 21, 2020 at 12:36 AM Ed Cable <ed...@mifos.org> wrote:
> Thank you for clarifying Manthan. I see that ConstantName is one of the
> modules you had included in your GSOC proposal at #50. I didn't realize
> that you were going through entire codebase and removing all violations for
> each convention.
>
> Is it best to have a sub-task under Fineract-821 (
> https://issues.apache.org/jira/browse/FINERACT-821) to more easily track
> progress of each module and/or be able to assign specific modules out to
> multiple developers if necessary?
>
> Ed
>
> On Wed, May 20, 2020 at 2:57 PM Manthan Surkar <ma...@gmail.com>
> wrote:
>
>> Hello Ed,
>> I am already working on adding all checkstyles to fineract as a part of
>> my GSoC intern, currently, I am working on logging checkstyles (
>> https://issues.apache.org/jira/browse/FINERACT-942 ) and I am halfway
>> through it. I will pick this right after that if it is not very urgent :)
>>
>> -Thanks
>> Manthan
>>
>> On Thu, May 21, 2020 at 2:18 AM Ed Cable <ed...@mifos.org> wrote:
>>
>>> Michael,
>>>
>>> There's been some transition on Richard's team so I'm trying to work
>>> with the tech lead who would now be able to allocate a developer from theri
>>> side to work on sharing some of their contributions. In the meantime, do we
>>> have a ticket created for the work that you had prescribed to RIchard.
>>> Could we possibly have one of our interns working on Fineract through
>>> GSOC/Outreachy pick that up as one of their tasks. The work would be to
>>> uncomment ConstantName in checkstyle.xml and then go through the
>>> entire codebase and remove all existing violations of this convention.
>>>
>>> Checkstyle will enforce this for new code coming but is there a scanning
>>> tool we can use to surface all violations of this condition?
>>>
>>>
>>>> - we'd love to see *public static final *fields following standard
>>>> java conventions (e.g. *THE_FIELD* instead of *theField*)
>>>>
>>>> Richard, Checkstyle's ConstantName rule (see
>>> https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
>>> exactly what you want. What you need to do now to help the project stick
>>> to this is fix all existing violation of this convention, and then
>>> uncomment ConstantName in line 194 of
>>> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
>>> (just move it up before line 51, before the commented out block of all the
>>> rules which are still to be done).
>>>
>>>
>>>
>>>
>>>
>>>> On Tue, Jan 14, 2020 at 5:12 PM Richard Billeci <ri...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Hello Michael,
>>>>>
>>>>> I'd like to offer support from my development team, starting in
>>>>> February. I could assign 1 person full-time to supporting this topic.
>>>>>
>>>>> Besides checkstyle conformance:
>>>>>
>>>>> - we'd love to see a standard code-style applied across the
>>>>> code-base (e.g. IntelliJ or similar standards), with a mechanism to ensure
>>>>> enforcement
>>>>>
>>>>> Richard, in my experience the only way that enforcing standard
>>>> code-style Java conventions works is to enable Checkstyle and make it fails
>>>> builds both locally and of Pull Requests. I've gone around the block on
>>>> such matters over the years, and learnt that everything else, such as
>>>> running tool like Sonar on the main develop branch after merge (that's too
>>>> late.. people never fix things, once they are in), or "requiring" certain
>>>> conventions via documentation and/or by IDE Configuration files for auto
>>>> formatting etc. just never really works. (IDE configs are nice, and we
>>>> could have them to complement Checkstyle, but alone they are never
>>>> sufficient; in a distributed community like this one, where it's simply
>>>> impossible to "control" local set ups, there really is no way to enforce
>>>> such conventions, other than using a tool like Checkstyle, during every
>>>> build).
>>>>
>>>>>
>>>>> - we'd love to see *public static final *fields following standard
>>>>> java conventions (e.g. *THE_FIELD* instead of *theField*)
>>>>>
>>>>> Richard, Checkstyle's ConstantName rule (see
>>>> https://checkstyle.sourceforge.io/config_naming.html#ConstantName)
>>>> does exactly what you want. What you need to do now to help the project
>>>> stick to this is fix all existing violation of this convention, and then
>>>> uncomment ConstantName in line 194 of
>>>> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
>>>> (just move it up before line 51, before the commented out block of all the
>>>> rules which are still to be done).
>>>>
>>>> It's best to go about such things gradually and incrementally, please
>>>> send us a first PR *only* making this change.
>>>>
>>>>
>>>>> We have a significant number of enhancements based off of 1.2, and
>>>>> getting the above completed would help us contribute back.
>>>>>
>>>>
>>>> Great! Looking forward.
>>>>
>>>>
>>>>> I've not followed 1.3/1.4, so if these changes were already made,
>>>>> that's great.
>>>>>
>>>>> Please let us know how my team can best help.
>>>>>
>>>>
>>>> We eagerly await your first Pull Request re. ConstantName! And then
>>>> more after that? ;-)
>>>>
>>>>
>>>>> Best Regards,
>>>>>
>>>>> Richard
>>>>>
>>>>>
>>>>> On Sat, Jan 11, 2020 at 2:28 AM Michael Vorburger <mi...@vorburger.ch>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I've started with https://issues.apache.org/jira/browse/FINERACT-821
>>>>>> re. adopting Checkstyle for Fineract source code.
>>>>>>
>>>>>> Would anyone be interested in helping with this effort?
>>>>>>
>>>>>> Best,
>>>>>> M.
>>>>>> _______________________
>>>>>> Michael Vorburger
>>>>>> http://www.vorburger.ch
>>>>>>
>>>>>
>>>
>>> --
>>> *Ed Cable*
>>> President/CEO, Mifos Initiative
>>> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>>>
>>> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>>> <http://facebook.com/mifos> <http://www.twitter.com/mifos>
>>>
>>>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> <http://facebook.com/mifos> <http://www.twitter.com/mifos>
>
>
Re: Checkstyle for Fineract source code
Posted by Ed Cable <ed...@mifos.org>.
Thank you for clarifying Manthan. I see that ConstantName is one of the
modules you had included in your GSOC proposal at #50. I didn't realize
that you were going through entire codebase and removing all violations for
each convention.
Is it best to have a sub-task under Fineract-821 (
https://issues.apache.org/jira/browse/FINERACT-821) to more easily track
progress of each module and/or be able to assign specific modules out to
multiple developers if necessary?
Ed
On Wed, May 20, 2020 at 2:57 PM Manthan Surkar <ma...@gmail.com>
wrote:
> Hello Ed,
> I am already working on adding all checkstyles to fineract as a part of my
> GSoC intern, currently, I am working on logging checkstyles (
> https://issues.apache.org/jira/browse/FINERACT-942 ) and I am halfway
> through it. I will pick this right after that if it is not very urgent :)
>
> -Thanks
> Manthan
>
> On Thu, May 21, 2020 at 2:18 AM Ed Cable <ed...@mifos.org> wrote:
>
>> Michael,
>>
>> There's been some transition on Richard's team so I'm trying to work with
>> the tech lead who would now be able to allocate a developer from theri side
>> to work on sharing some of their contributions. In the meantime, do we have
>> a ticket created for the work that you had prescribed to RIchard. Could we
>> possibly have one of our interns working on Fineract through GSOC/Outreachy
>> pick that up as one of their tasks. The work would be to uncomment
>> ConstantName in checkstyle.xml and then go through the entire codebase and
>> remove all existing violations of this convention.
>>
>> Checkstyle will enforce this for new code coming but is there a scanning
>> tool we can use to surface all violations of this condition?
>>
>>
>>> - we'd love to see *public static final *fields following standard
>>> java conventions (e.g. *THE_FIELD* instead of *theField*)
>>>
>>> Richard, Checkstyle's ConstantName rule (see
>> https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
>> exactly what you want. What you need to do now to help the project stick
>> to this is fix all existing violation of this convention, and then
>> uncomment ConstantName in line 194 of
>> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
>> (just move it up before line 51, before the commented out block of all the
>> rules which are still to be done).
>>
>>
>>
>>
>>
>>> On Tue, Jan 14, 2020 at 5:12 PM Richard Billeci <ri...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Hello Michael,
>>>>
>>>> I'd like to offer support from my development team, starting in
>>>> February. I could assign 1 person full-time to supporting this topic.
>>>>
>>>> Besides checkstyle conformance:
>>>>
>>>> - we'd love to see a standard code-style applied across the
>>>> code-base (e.g. IntelliJ or similar standards), with a mechanism to ensure
>>>> enforcement
>>>>
>>>> Richard, in my experience the only way that enforcing standard
>>> code-style Java conventions works is to enable Checkstyle and make it fails
>>> builds both locally and of Pull Requests. I've gone around the block on
>>> such matters over the years, and learnt that everything else, such as
>>> running tool like Sonar on the main develop branch after merge (that's too
>>> late.. people never fix things, once they are in), or "requiring" certain
>>> conventions via documentation and/or by IDE Configuration files for auto
>>> formatting etc. just never really works. (IDE configs are nice, and we
>>> could have them to complement Checkstyle, but alone they are never
>>> sufficient; in a distributed community like this one, where it's simply
>>> impossible to "control" local set ups, there really is no way to enforce
>>> such conventions, other than using a tool like Checkstyle, during every
>>> build).
>>>
>>>>
>>>> - we'd love to see *public static final *fields following standard
>>>> java conventions (e.g. *THE_FIELD* instead of *theField*)
>>>>
>>>> Richard, Checkstyle's ConstantName rule (see
>>> https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
>>> exactly what you want. What you need to do now to help the project stick
>>> to this is fix all existing violation of this convention, and then
>>> uncomment ConstantName in line 194 of
>>> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
>>> (just move it up before line 51, before the commented out block of all the
>>> rules which are still to be done).
>>>
>>> It's best to go about such things gradually and incrementally, please
>>> send us a first PR *only* making this change.
>>>
>>>
>>>> We have a significant number of enhancements based off of 1.2, and
>>>> getting the above completed would help us contribute back.
>>>>
>>>
>>> Great! Looking forward.
>>>
>>>
>>>> I've not followed 1.3/1.4, so if these changes were already made,
>>>> that's great.
>>>>
>>>> Please let us know how my team can best help.
>>>>
>>>
>>> We eagerly await your first Pull Request re. ConstantName! And then
>>> more after that? ;-)
>>>
>>>
>>>> Best Regards,
>>>>
>>>> Richard
>>>>
>>>>
>>>> On Sat, Jan 11, 2020 at 2:28 AM Michael Vorburger <mi...@vorburger.ch>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I've started with https://issues.apache.org/jira/browse/FINERACT-821
>>>>> re. adopting Checkstyle for Fineract source code.
>>>>>
>>>>> Would anyone be interested in helping with this effort?
>>>>>
>>>>> Best,
>>>>> M.
>>>>> _______________________
>>>>> Michael Vorburger
>>>>> http://www.vorburger.ch
>>>>>
>>>>
>>
>> --
>> *Ed Cable*
>> President/CEO, Mifos Initiative
>> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>>
>> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>> <http://facebook.com/mifos> <http://www.twitter.com/mifos>
>>
>>
--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
<http://facebook.com/mifos> <http://www.twitter.com/mifos>
Re: Checkstyle for Fineract source code
Posted by Manthan Surkar <ma...@gmail.com>.
Hello Ed,
I am already working on adding all checkstyles to fineract as a part of my
GSoC intern, currently, I am working on logging checkstyles (
https://issues.apache.org/jira/browse/FINERACT-942 ) and I am halfway
through it. I will pick this right after that if it is not very urgent :)
-Thanks
Manthan
On Thu, May 21, 2020 at 2:18 AM Ed Cable <ed...@mifos.org> wrote:
> Michael,
>
> There's been some transition on Richard's team so I'm trying to work with
> the tech lead who would now be able to allocate a developer from theri side
> to work on sharing some of their contributions. In the meantime, do we have
> a ticket created for the work that you had prescribed to RIchard. Could we
> possibly have one of our interns working on Fineract through GSOC/Outreachy
> pick that up as one of their tasks. The work would be to uncomment
> ConstantName in checkstyle.xml and then go through the entire codebase and
> remove all existing violations of this convention.
>
> Checkstyle will enforce this for new code coming but is there a scanning
> tool we can use to surface all violations of this condition?
>
>
>> - we'd love to see *public static final *fields following standard
>> java conventions (e.g. *THE_FIELD* instead of *theField*)
>>
>> Richard, Checkstyle's ConstantName rule (see
> https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
> exactly what you want. What you need to do now to help the project stick
> to this is fix all existing violation of this convention, and then
> uncomment ConstantName in line 194 of
> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
> (just move it up before line 51, before the commented out block of all the
> rules which are still to be done).
>
>
>
>
>
>> On Tue, Jan 14, 2020 at 5:12 PM Richard Billeci <ri...@gmail.com>
>> wrote:
>>
>>>
>>> Hello Michael,
>>>
>>> I'd like to offer support from my development team, starting in
>>> February. I could assign 1 person full-time to supporting this topic.
>>>
>>> Besides checkstyle conformance:
>>>
>>> - we'd love to see a standard code-style applied across the
>>> code-base (e.g. IntelliJ or similar standards), with a mechanism to ensure
>>> enforcement
>>>
>>> Richard, in my experience the only way that enforcing standard
>> code-style Java conventions works is to enable Checkstyle and make it fails
>> builds both locally and of Pull Requests. I've gone around the block on
>> such matters over the years, and learnt that everything else, such as
>> running tool like Sonar on the main develop branch after merge (that's too
>> late.. people never fix things, once they are in), or "requiring" certain
>> conventions via documentation and/or by IDE Configuration files for auto
>> formatting etc. just never really works. (IDE configs are nice, and we
>> could have them to complement Checkstyle, but alone they are never
>> sufficient; in a distributed community like this one, where it's simply
>> impossible to "control" local set ups, there really is no way to enforce
>> such conventions, other than using a tool like Checkstyle, during every
>> build).
>>
>>>
>>> - we'd love to see *public static final *fields following standard
>>> java conventions (e.g. *THE_FIELD* instead of *theField*)
>>>
>>> Richard, Checkstyle's ConstantName rule (see
>> https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
>> exactly what you want. What you need to do now to help the project stick
>> to this is fix all existing violation of this convention, and then
>> uncomment ConstantName in line 194 of
>> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
>> (just move it up before line 51, before the commented out block of all the
>> rules which are still to be done).
>>
>> It's best to go about such things gradually and incrementally, please
>> send us a first PR *only* making this change.
>>
>>
>>> We have a significant number of enhancements based off of 1.2, and
>>> getting the above completed would help us contribute back.
>>>
>>
>> Great! Looking forward.
>>
>>
>>> I've not followed 1.3/1.4, so if these changes were already made, that's
>>> great.
>>>
>>> Please let us know how my team can best help.
>>>
>>
>> We eagerly await your first Pull Request re. ConstantName! And then more
>> after that? ;-)
>>
>>
>>> Best Regards,
>>>
>>> Richard
>>>
>>>
>>> On Sat, Jan 11, 2020 at 2:28 AM Michael Vorburger <mi...@vorburger.ch>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I've started with https://issues.apache.org/jira/browse/FINERACT-821
>>>> re. adopting Checkstyle for Fineract source code.
>>>>
>>>> Would anyone be interested in helping with this effort?
>>>>
>>>> Best,
>>>> M.
>>>> _______________________
>>>> Michael Vorburger
>>>> http://www.vorburger.ch
>>>>
>>>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> <http://facebook.com/mifos> <http://www.twitter.com/mifos>
>
>
Re: Checkstyle for Fineract source code
Posted by Ed Cable <ed...@mifos.org>.
Michael,
There's been some transition on Richard's team so I'm trying to work with
the tech lead who would now be able to allocate a developer from theri side
to work on sharing some of their contributions. In the meantime, do we have
a ticket created for the work that you had prescribed to RIchard. Could we
possibly have one of our interns working on Fineract through GSOC/Outreachy
pick that up as one of their tasks. The work would be to uncomment
ConstantName in checkstyle.xml and then go through the entire codebase and
remove all existing violations of this convention.
Checkstyle will enforce this for new code coming but is there a scanning
tool we can use to surface all violations of this condition?
> - we'd love to see *public static final *fields following standard
> java conventions (e.g. *THE_FIELD* instead of *theField*)
>
> Richard, Checkstyle's ConstantName rule (see
https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
exactly what you want. What you need to do now to help the project stick
to this is fix all existing violation of this convention, and then
uncomment ConstantName in line 194 of
https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
(just move it up before line 51, before the commented out block of all the
rules which are still to be done).
> On Tue, Jan 14, 2020 at 5:12 PM Richard Billeci <ri...@gmail.com>
> wrote:
>
>>
>> Hello Michael,
>>
>> I'd like to offer support from my development team, starting in February.
>> I could assign 1 person full-time to supporting this topic.
>>
>> Besides checkstyle conformance:
>>
>> - we'd love to see a standard code-style applied across the code-base
>> (e.g. IntelliJ or similar standards), with a mechanism to ensure enforcement
>>
>> Richard, in my experience the only way that enforcing standard code-style
> Java conventions works is to enable Checkstyle and make it fails builds
> both locally and of Pull Requests. I've gone around the block on such
> matters over the years, and learnt that everything else, such as running
> tool like Sonar on the main develop branch after merge (that's too late..
> people never fix things, once they are in), or "requiring" certain
> conventions via documentation and/or by IDE Configuration files for auto
> formatting etc. just never really works. (IDE configs are nice, and we
> could have them to complement Checkstyle, but alone they are never
> sufficient; in a distributed community like this one, where it's simply
> impossible to "control" local set ups, there really is no way to enforce
> such conventions, other than using a tool like Checkstyle, during every
> build).
>
>>
>> - we'd love to see *public static final *fields following standard
>> java conventions (e.g. *THE_FIELD* instead of *theField*)
>>
>> Richard, Checkstyle's ConstantName rule (see
> https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
> exactly what you want. What you need to do now to help the project stick
> to this is fix all existing violation of this convention, and then
> uncomment ConstantName in line 194 of
> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
> (just move it up before line 51, before the commented out block of all the
> rules which are still to be done).
>
> It's best to go about such things gradually and incrementally, please send
> us a first PR *only* making this change.
>
>
>> We have a significant number of enhancements based off of 1.2, and
>> getting the above completed would help us contribute back.
>>
>
> Great! Looking forward.
>
>
>> I've not followed 1.3/1.4, so if these changes were already made, that's
>> great.
>>
>> Please let us know how my team can best help.
>>
>
> We eagerly await your first Pull Request re. ConstantName! And then more
> after that? ;-)
>
>
>> Best Regards,
>>
>> Richard
>>
>>
>> On Sat, Jan 11, 2020 at 2:28 AM Michael Vorburger <mi...@vorburger.ch>
>> wrote:
>>
>>> Hello,
>>>
>>> I've started with https://issues.apache.org/jira/browse/FINERACT-821
>>> re. adopting Checkstyle for Fineract source code.
>>>
>>> Would anyone be interested in helping with this effort?
>>>
>>> Best,
>>> M.
>>> _______________________
>>> Michael Vorburger
>>> http://www.vorburger.ch
>>>
>>
--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
<http://facebook.com/mifos> <http://www.twitter.com/mifos>
Re: Checkstyle for Fineract source code
Posted by Michael Vorburger <mi...@vorburger.ch>.
Hello again everyone re. this thread,
Following the merge of https://github.com/apache/fineract/pull/704 (thanks
Awasum), we are now enforcing Java import statements to be alphabetically
ordered with Checkstyle.
This uniformity reduces diff noise in PR review.
We have also updated the old original Preferences file for Eclipse.
Importing that makes complying with this new convention trivial; see new
the section of the README at
https://github.com/apache/fineract/blob/develop/README.md#checkstyle
We would welcome a contribution from others with a similar ready-to-use
Preferences configuration for other IDEs.
M.
On Thu, 23 Jan 2020, 08:56 Michael Vorburger, <mi...@vorburger.ch> wrote:
> Hello everyone,
>
> Re. adopting Checkstyle for Fineract (non-CN) source code, with the merge
> of https://github.com/apache/fineract/pull/689 (thanks Awasum!), the
> groundwork is now available.
>
> On Sun, Jan 12, 2020 at 8:25 PM Yemdjih Kaze Nasser <ka...@gmail.com>
> wrote:
>
>> I've added myself to watch list. It's a pleasure to work with you
>>
>> On Sun, 12 Jan 2020 at 20:19, Michael Vorburger <mi...@vorburger.ch>
>> wrote:
>>
>>> On Sun, Jan 12, 2020 at 7:58 PM Yemdjih Kaze Nasser <
>>> kazenasser@gmail.com> wrote:
>>>
>>>> I'm interested in this, I will make some investigations and push some
>>>> changes
>>>>
>>>
>>> Yemdjih: Cool, great to hear. Please read the latest comment I just made
>>> in FINERACT-821 (and click Watch on that issue to get notifications about
>>> future updates). I've just raised 2 PRs which will make a start for this -
>>> but there's lots more to be done! As soon as those 2 PRs are merged, I'd
>>> love to see you jump on and extend upon them (by, gradually, uncommenting
>>> more rules in that checkstyle.xml you'll find when you have a closer look).
>>>
>>
> Yemdjih, which Checkstyle rules will you work on enabling?
>
> On Tue, Jan 14, 2020 at 5:12 PM Richard Billeci <ri...@gmail.com>
> wrote:
>
>>
>> Hello Michael,
>>
>> I'd like to offer support from my development team, starting in February.
>> I could assign 1 person full-time to supporting this topic.
>>
>> Besides checkstyle conformance:
>>
>> - we'd love to see a standard code-style applied across the code-base
>> (e.g. IntelliJ or similar standards), with a mechanism to ensure enforcement
>>
>> Richard, in my experience the only way that enforcing standard code-style
> Java conventions works is to enable Checkstyle and make it fails builds
> both locally and of Pull Requests. I've gone around the block on such
> matters over the years, and learnt that everything else, such as running
> tool like Sonar on the main develop branch after merge (that's too late..
> people never fix things, once they are in), or "requiring" certain
> conventions via documentation and/or by IDE Configuration files for auto
> formatting etc. just never really works. (IDE configs are nice, and we
> could have them to complement Checkstyle, but alone they are never
> sufficient; in a distributed community like this one, where it's simply
> impossible to "control" local set ups, there really is no way to enforce
> such conventions, other than using a tool like Checkstyle, during every
> build).
>
>>
>> - we'd love to see *public static final *fields following standard
>> java conventions (e.g. *THE_FIELD* instead of *theField*)
>>
>> Richard, Checkstyle's ConstantName rule (see
> https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
> exactly what you want. What you need to do now to help the project stick
> to this is fix all existing violation of this convention, and then
> uncomment ConstantName in line 194 of
> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
> (just move it up before line 51, before the commented out block of all the
> rules which are still to be done).
>
> It's best to go about such things gradually and incrementally, please send
> us a first PR *only* making this change.
>
>
>> We have a significant number of enhancements based off of 1.2, and
>> getting the above completed would help us contribute back.
>>
>
> Great! Looking forward.
>
>
>> I've not followed 1.3/1.4, so if these changes were already made, that's
>> great.
>>
>> Please let us know how my team can best help.
>>
>
> We eagerly await your first Pull Request re. ConstantName! And then more
> after that? ;-)
>
>
>> Best Regards,
>>
>> Richard
>>
>>
>> On Sat, Jan 11, 2020 at 2:28 AM Michael Vorburger <mi...@vorburger.ch>
>> wrote:
>>
>>> Hello,
>>>
>>> I've started with https://issues.apache.org/jira/browse/FINERACT-821
>>> re. adopting Checkstyle for Fineract source code.
>>>
>>> Would anyone be interested in helping with this effort?
>>>
>>> Best,
>>> M.
>>> _______________________
>>> Michael Vorburger
>>> http://www.vorburger.ch
>>>
>>
Re: Checkstyle for Fineract source code
Posted by Michael Vorburger <mi...@vorburger.ch>.
Hello everyone,
Re. adopting Checkstyle for Fineract (non-CN) source code, with the merge
of https://github.com/apache/fineract/pull/689 (thanks Awasum!), the
groundwork is now available.
On Sun, Jan 12, 2020 at 8:25 PM Yemdjih Kaze Nasser <ka...@gmail.com>
wrote:
> I've added myself to watch list. It's a pleasure to work with you
>
> On Sun, 12 Jan 2020 at 20:19, Michael Vorburger <mi...@vorburger.ch> wrote:
>
>> On Sun, Jan 12, 2020 at 7:58 PM Yemdjih Kaze Nasser <ka...@gmail.com>
>> wrote:
>>
>>> I'm interested in this, I will make some investigations and push some
>>> changes
>>>
>>
>> Yemdjih: Cool, great to hear. Please read the latest comment I just made
>> in FINERACT-821 (and click Watch on that issue to get notifications about
>> future updates). I've just raised 2 PRs which will make a start for this -
>> but there's lots more to be done! As soon as those 2 PRs are merged, I'd
>> love to see you jump on and extend upon them (by, gradually, uncommenting
>> more rules in that checkstyle.xml you'll find when you have a closer look).
>>
>
Yemdjih, which Checkstyle rules will you work on enabling?
On Tue, Jan 14, 2020 at 5:12 PM Richard Billeci <ri...@gmail.com>
wrote:
>
> Hello Michael,
>
> I'd like to offer support from my development team, starting in February.
> I could assign 1 person full-time to supporting this topic.
>
> Besides checkstyle conformance:
>
> - we'd love to see a standard code-style applied across the code-base
> (e.g. IntelliJ or similar standards), with a mechanism to ensure enforcement
>
> Richard, in my experience the only way that enforcing standard code-style
Java conventions works is to enable Checkstyle and make it fails builds
both locally and of Pull Requests. I've gone around the block on such
matters over the years, and learnt that everything else, such as running
tool like Sonar on the main develop branch after merge (that's too late..
people never fix things, once they are in), or "requiring" certain
conventions via documentation and/or by IDE Configuration files for auto
formatting etc. just never really works. (IDE configs are nice, and we
could have them to complement Checkstyle, but alone they are never
sufficient; in a distributed community like this one, where it's simply
impossible to "control" local set ups, there really is no way to enforce
such conventions, other than using a tool like Checkstyle, during every
build).
>
> - we'd love to see *public static final *fields following standard
> java conventions (e.g. *THE_FIELD* instead of *theField*)
>
> Richard, Checkstyle's ConstantName rule (see
https://checkstyle.sourceforge.io/config_naming.html#ConstantName) does
exactly what you want. What you need to do now to help the project stick
to this is fix all existing violation of this convention, and then
uncomment ConstantName in line 194 of
https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
(just move it up before line 51, before the commented out block of all the
rules which are still to be done).
It's best to go about such things gradually and incrementally, please send
us a first PR *only* making this change.
> We have a significant number of enhancements based off of 1.2, and getting
> the above completed would help us contribute back.
>
Great! Looking forward.
> I've not followed 1.3/1.4, so if these changes were already made, that's
> great.
>
> Please let us know how my team can best help.
>
We eagerly await your first Pull Request re. ConstantName! And then more
after that? ;-)
> Best Regards,
>
> Richard
>
>
> On Sat, Jan 11, 2020 at 2:28 AM Michael Vorburger <mi...@vorburger.ch>
> wrote:
>
>> Hello,
>>
>> I've started with https://issues.apache.org/jira/browse/FINERACT-821 re.
>> adopting Checkstyle for Fineract source code.
>>
>> Would anyone be interested in helping with this effort?
>>
>> Best,
>> M.
>> _______________________
>> Michael Vorburger
>> http://www.vorburger.ch
>>
>
Re: Checkstyle for Fineract source code
Posted by Awasum Yannick <aw...@apache.org>.
Hi Richard,
On Tue, Jan 14, 2020 at 5:12 PM Richard Billeci <ri...@gmail.com>
wrote:
>
> Hello Michael,
>
> I'd like to offer support from my development team, starting in February.
> I could assign 1 person full-time to supporting this topic.
>
Please do. Let them introduce themselves on the mailing list and start
sending PRs. Thanks for the offer.
>
> Besides checkstyle conformance:
>
> - we'd love to see a standard code-style applied across the code-base
> (e.g. IntelliJ or similar standards), with a mechanism to ensure enforcement
> - we'd love to see *public static final *fields following standard
> java conventions (e.g. *THE_FIELD* instead of *theField*)
>
> We have a significant number of enhancements based off of 1.2, and getting
> the above completed would help us contribute back. I've not followed
> 1.3/1.4, so if these changes were already made, that's great.
>
> Please let us know how my team can best help.
>
>
> Best Regards,
>
> Richard
>
>
> On Sat, Jan 11, 2020 at 2:28 AM Michael Vorburger <mi...@vorburger.ch>
> wrote:
>
>> Hello,
>>
>> I've started with https://issues.apache.org/jira/browse/FINERACT-821 re.
>> adopting Checkstyle for Fineract source code.
>>
>> Would anyone be interested in helping with this effort?
>>
>> Best,
>> M.
>> _______________________
>> Michael Vorburger
>> http://www.vorburger.ch
>>
>
Re: Checkstyle for Fineract source code
Posted by Richard Billeci <ri...@gmail.com>.
Hello Michael,
I'd like to offer support from my development team, starting in February. I
could assign 1 person full-time to supporting this topic.
Besides checkstyle conformance:
- we'd love to see a standard code-style applied across the code-base
(e.g. IntelliJ or similar standards), with a mechanism to ensure enforcement
- we'd love to see *public static final *fields following standard java
conventions (e.g. *THE_FIELD* instead of *theField*)
We have a significant number of enhancements based off of 1.2, and getting
the above completed would help us contribute back. I've not followed
1.3/1.4, so if these changes were already made, that's great.
Please let us know how my team can best help.
Best Regards,
Richard
On Sat, Jan 11, 2020 at 2:28 AM Michael Vorburger <mi...@vorburger.ch> wrote:
> Hello,
>
> I've started with https://issues.apache.org/jira/browse/FINERACT-821 re.
> adopting Checkstyle for Fineract source code.
>
> Would anyone be interested in helping with this effort?
>
> Best,
> M.
> _______________________
> Michael Vorburger
> http://www.vorburger.ch
>
Re: Checkstyle for Fineract source code
Posted by Yemdjih Kaze Nasser <ka...@gmail.com>.
I've added myself to watch list. It's a pleasure to work with you
On Sun, 12 Jan 2020 at 20:19, Michael Vorburger <mi...@vorburger.ch> wrote:
> On Sun, Jan 12, 2020 at 7:58 PM Yemdjih Kaze Nasser <ka...@gmail.com>
> wrote:
>
>> I'm interested in this, I will make some investigations and push some
>> changes
>>
>
> Yemdjih: Cool, great to hear. Please read the latest comment I just made
> in FINERACT-821 (and click Watch on that issue to get notifications about
> future updates). I've just raised 2 PRs which will make a start for this -
> but there's lots more to be done! As soon as those 2 PRs are merged, I'd
> love to see you jump on and extend upon them (by, gradually, uncommenting
> more rules in that checkstyle.xml you'll find when you have a closer look).
>
>
>> On Sat, 11 Jan 2020 at 02:28, Michael Vorburger <mi...@vorburger.ch>
>> wrote:
>>
>>> Hello,
>>>
>>> I've started with https://issues.apache.org/jira/browse/FINERACT-821
>>> re. adopting Checkstyle for Fineract source code.
>>>
>>> Would anyone be interested in helping with this effort?
>>>
>>> Best,
>>> M.
>>> _______________________
>>> Michael Vorburger
>>> http://www.vorburger.ch
>>>
>>
Re: Checkstyle for Fineract source code
Posted by Michael Vorburger <mi...@vorburger.ch>.
On Sun, Jan 12, 2020 at 7:58 PM Yemdjih Kaze Nasser <ka...@gmail.com>
wrote:
> I'm interested in this, I will make some investigations and push some
> changes
>
Yemdjih: Cool, great to hear. Please read the latest comment I just made in
FINERACT-821 (and click Watch on that issue to get notifications about
future updates). I've just raised 2 PRs which will make a start for this -
but there's lots more to be done! As soon as those 2 PRs are merged, I'd
love to see you jump on and extend upon them (by, gradually, uncommenting
more rules in that checkstyle.xml you'll find when you have a closer look).
> On Sat, 11 Jan 2020 at 02:28, Michael Vorburger <mi...@vorburger.ch> wrote:
>
>> Hello,
>>
>> I've started with https://issues.apache.org/jira/browse/FINERACT-821 re.
>> adopting Checkstyle for Fineract source code.
>>
>> Would anyone be interested in helping with this effort?
>>
>> Best,
>> M.
>> _______________________
>> Michael Vorburger
>> http://www.vorburger.ch
>>
>
Re: Checkstyle for Fineract source code
Posted by Yemdjih Kaze Nasser <ka...@gmail.com>.
I'm interested in this, I will make some investigations and push some
changes
On Sat, 11 Jan 2020 at 02:28, Michael Vorburger <mi...@vorburger.ch> wrote:
> Hello,
>
> I've started with https://issues.apache.org/jira/browse/FINERACT-821 re.
> adopting Checkstyle for Fineract source code.
>
> Would anyone be interested in helping with this effort?
>
> Best,
> M.
> _______________________
> Michael Vorburger
> http://www.vorburger.ch
>