Re: Proposal: Add a Code Formatter to Oak

2024-05-23 Thread Julian Reschke

Am 23.05.2024 um 09:25 schrieb Steffen Van:

Hi Robert,

Thanks for sharing that. I was thinking about doing something very similar. 
However, because my initial proposal on other channels was met with a bit of 
resistance, I would like to know what the general feeling is towards 
introducing a uniform code style guide to Oak.


FWIW, we *do* have a uniform source style (that we'd need to document),
it's just not enforced, so there are parts of the code that do not
conform to it.

Best regards, Julian


Re: Proposal: Add a Code Formatter to Oak

2024-05-23 Thread Steffen Van
Hi Robert,

Thanks for sharing that. I was thinking about doing something very similar. 
However, because my initial proposal on other channels was met with a bit of 
resistance, I would like to know what the general feeling is towards 
introducing a uniform code style guide to Oak.

Best,
Steffen

> On May 22, 2024, at 17:07, Robert Munteanu  wrote:
>
> EXTERNAL: Use caution when clicking on links or opening attachments.
>
>
> Hi Steffen,
>
> On Wed, 2024-05-22 at 13:54 +, Steffen Van wrote:
>> Hi everyone,
>>
>> I would like to suggest that we introduce a code formatter in Oak.
>> Having a formatter will make the code easier to read and keep the
>> whole codebase more maintainable. Especially for new people.
>>
>> I'm not picky about which particular formatter we use — whether it's
>> Google's java-format, spotless, or whatever. I’m not particularly
>> picky about one particular, just that there is one. Most, if not all,
>> major open-source projects enforce a strict code-style for a good
>> reason. I think we should do the same.
>
> We recently added a code formatter to Sling, here's a reference to how
> we did it
>
>  https://issues.apache.org/jira/browse/SLING-12186
>
> Of course, we have a different setup - hundreds of small repos - so
> what worked for us might not be best for Oak.
>
> Thanks,
> Robert



Re: Proposal: Add a Code Formatter to Oak

2024-05-22 Thread Robert Munteanu
Hi Steffen,

On Wed, 2024-05-22 at 13:54 +, Steffen Van wrote:
> Hi everyone,
> 
> I would like to suggest that we introduce a code formatter in Oak.
> Having a formatter will make the code easier to read and keep the
> whole codebase more maintainable. Especially for new people.
> 
> I'm not picky about which particular formatter we use — whether it's
> Google's java-format, spotless, or whatever. I’m not particularly
> picky about one particular, just that there is one. Most, if not all,
> major open-source projects enforce a strict code-style for a good
> reason. I think we should do the same.

We recently added a code formatter to Sling, here's a reference to how
we did it

  https://issues.apache.org/jira/browse/SLING-12186

Of course, we have a different setup - hundreds of small repos - so
what worked for us might not be best for Oak.

Thanks,
Robert


Proposal: Add a Code Formatter to Oak

2024-05-22 Thread Steffen Van
Hi everyone,

I would like to suggest that we introduce a code formatter in Oak. Having a 
formatter will make the code easier to read and keep the whole codebase more 
maintainable. Especially for new people.

I'm not picky about which particular formatter we use — whether it's Google's 
java-format, spotless, or whatever. I’m not particularly picky about one 
particular, just that there is one. Most, if not all, major open-source 
projects enforce a strict code-style for a good reason. I think we should do 
the same.

To address concerns about polluting the git blame history, we can use GitHub's 
feature to ignore specific commits in the blame view: 
https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view.
 This way, we can exclude the formatting commits and keep the functional 
changes clear. That also means that if you open IntelliJ (or any other IDE), 
the blame will not be polluted.

A quick discussion here: https://github.com/apache/jackrabbit-oak/pull/1476 
shows me that there are some concerns about diffing with other branches etc. 
Those are pretty easily mitigated as git offers various ways to ignore 
whitespace / end of line differences.

Let me know what you think.


Best,
Steffen