Re: Introduce spotless-maven-plugin
Thanks Konrad! Regards Julian On Fri, Dec 8, 2023 at 4:43 PM Konrad Windszus wrote: > > I created https://issues.apache.org/jira/browse/SLING-12186 to track this and > linked two feature branches where this has been tried out. > Please have a look there. > > @Julian: checking happens in phase “process-sources” > (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference) > which is pretty early. > > Konrad > > > On 7. Dec 2023, at 12:40, Stefan Seifert > > wrote: > > > > > >> Sure, any candidate(s) you have in mind? Then I can prepare a PR with the > >> proposed changes. > >> Konrad > > > > e.g. models-api and models-impl > > > > we have to keep in mind that once we apply one-time reformatting of the > > code base, all open PRs might be in conflict and will only be mergeable > > with manual work. > > > > stefan > > >
Re: Introduce spotless-maven-plugin
I created https://issues.apache.org/jira/browse/SLING-12186 to track this and linked two feature branches where this has been tried out. Please have a look there. @Julian: checking happens in phase “process-sources” (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference) which is pretty early. Konrad > On 7. Dec 2023, at 12:40, Stefan Seifert > wrote: > > >> Sure, any candidate(s) you have in mind? Then I can prepare a PR with the >> proposed changes. >> Konrad > > e.g. models-api and models-impl > > we have to keep in mind that once we apply one-time reformatting of the code > base, all open PRs might be in conflict and will only be mergeable with > manual work. > > stefan >
RE: Introduce spotless-maven-plugin
> Sure, any candidate(s) you have in mind? Then I can prepare a PR with the > proposed changes. > Konrad e.g. models-api and models-impl we have to keep in mind that once we apply one-time reformatting of the code base, all open PRs might be in conflict and will only be mergeable with manual work. stefan
Re: Introduce spotless-maven-plugin
+1 - for automatic code checking and optional formatting If it's fast enough, I like having these kind of checks in an early build-phase. If it only fails late, i.e. on verify or install, that somehow feels more disruptive to me. Regards Julian On Wed, Dec 6, 2023 at 1:44 PM Konrad Windszus wrote: > > Sure, any candidate(s) you have in mind? Then I can prepare a PR with the > proposed changes. > Konrad > > > On 6. Dec 2023, at 11:00, Stefan Seifert > > wrote: > > > > ok, sounds good. > > > > maybe we can give it a try on one or two modules before forcing it down to > > everyone via the parent pom? > > > > stefan > > > >> -Original Message- > >> From: Konrad Windszus > >> Sent: Wednesday, December 6, 2023 10:56 AM > >> To: dev@sling.apache.org > >> Subject: Re: Introduce spotless-maven-plugin > >> > >> The basic idea is to introduce that with a new parent pom. Once a module > >> adopts this new parent version, it needs to manually reformat everything > >> once to not fail the build. This is a one time effort together with > >> updating to the new pom. > >> Therefore it requires some opt-in per module anyways. > >> Konrad > >> > >>> On 6. Dec 2023, at 10:53, Stefan Seifert >> e.com.INVALID> wrote: > >>> > >>> i like it to have tooling like this around (but if have no experience > >> with this tool). > >>> > >>> one important point is that e.g. for PRs it only validates newly added > >> lines. if all PRs fail due to inconsistent formatting in the existing > >> codebase this would be quite disruptive. > >>> > >>> stefan > >>> > >>>> -Original Message- > >>>> From: Konrad Windszus > >>>> Sent: Tuesday, December 5, 2023 9:18 PM > >>>> To: dev@sling.apache.org > >>>> Subject: Introduce spotless-maven-plugin > >>>> > >>>> Hi, > >>>> We never had any formalised code formatting rules nor ever provided any > >>>> formatters for different IDEs (at least not that I am aware of). > >>>> That often leads to undesired formatting changes in PRs. > >>>> I propose to introduce > >>>> https://github.com/diffplug/spotless/tree/main/plugin-maven to > >>>> automatically enforce certain formatting rules during build (as well as > >> to > >>>> optionally apply those). > >>>> > >>>> There are quite some built-in rule sets. > >>>> Apache Maven uses > >> https://github.com/diffplug/spotless/tree/main/plugin- > >>>> maven#palantir-java-format and > >>>> https://github.com/diffplug/spotless/tree/main/plugin-maven#maven-pom > >>>> quite successfully for a while now. > >>>> > >>>> I am open to using another rule set, but the important bit is that we > >> can > >>>> enforce that across different IDEs easily during the build and fixing > >> is > >>>> easy for contributors/committers as well. > >>>> > >>>> WDYT? > >>>> > >>>> Konrad > > >
Re: Introduce spotless-maven-plugin
Sure, any candidate(s) you have in mind? Then I can prepare a PR with the proposed changes. Konrad > On 6. Dec 2023, at 11:00, Stefan Seifert > wrote: > > ok, sounds good. > > maybe we can give it a try on one or two modules before forcing it down to > everyone via the parent pom? > > stefan > >> -Original Message- >> From: Konrad Windszus >> Sent: Wednesday, December 6, 2023 10:56 AM >> To: dev@sling.apache.org >> Subject: Re: Introduce spotless-maven-plugin >> >> The basic idea is to introduce that with a new parent pom. Once a module >> adopts this new parent version, it needs to manually reformat everything >> once to not fail the build. This is a one time effort together with >> updating to the new pom. >> Therefore it requires some opt-in per module anyways. >> Konrad >> >>> On 6. Dec 2023, at 10:53, Stefan Seifert > e.com.INVALID> wrote: >>> >>> i like it to have tooling like this around (but if have no experience >> with this tool). >>> >>> one important point is that e.g. for PRs it only validates newly added >> lines. if all PRs fail due to inconsistent formatting in the existing >> codebase this would be quite disruptive. >>> >>> stefan >>> >>>> -Original Message- >>>> From: Konrad Windszus >>>> Sent: Tuesday, December 5, 2023 9:18 PM >>>> To: dev@sling.apache.org >>>> Subject: Introduce spotless-maven-plugin >>>> >>>> Hi, >>>> We never had any formalised code formatting rules nor ever provided any >>>> formatters for different IDEs (at least not that I am aware of). >>>> That often leads to undesired formatting changes in PRs. >>>> I propose to introduce >>>> https://github.com/diffplug/spotless/tree/main/plugin-maven to >>>> automatically enforce certain formatting rules during build (as well as >> to >>>> optionally apply those). >>>> >>>> There are quite some built-in rule sets. >>>> Apache Maven uses >> https://github.com/diffplug/spotless/tree/main/plugin- >>>> maven#palantir-java-format and >>>> https://github.com/diffplug/spotless/tree/main/plugin-maven#maven-pom >>>> quite successfully for a while now. >>>> >>>> I am open to using another rule set, but the important bit is that we >> can >>>> enforce that across different IDEs easily during the build and fixing >> is >>>> easy for contributors/committers as well. >>>> >>>> WDYT? >>>> >>>> Konrad >
RE: Introduce spotless-maven-plugin
ok, sounds good. maybe we can give it a try on one or two modules before forcing it down to everyone via the parent pom? stefan > -Original Message- > From: Konrad Windszus > Sent: Wednesday, December 6, 2023 10:56 AM > To: dev@sling.apache.org > Subject: Re: Introduce spotless-maven-plugin > > The basic idea is to introduce that with a new parent pom. Once a module > adopts this new parent version, it needs to manually reformat everything > once to not fail the build. This is a one time effort together with > updating to the new pom. > Therefore it requires some opt-in per module anyways. > Konrad > > > On 6. Dec 2023, at 10:53, Stefan Seifert e.com.INVALID> wrote: > > > > i like it to have tooling like this around (but if have no experience > with this tool). > > > > one important point is that e.g. for PRs it only validates newly added > lines. if all PRs fail due to inconsistent formatting in the existing > codebase this would be quite disruptive. > > > > stefan > > > >> -Original Message- > >> From: Konrad Windszus > >> Sent: Tuesday, December 5, 2023 9:18 PM > >> To: dev@sling.apache.org > >> Subject: Introduce spotless-maven-plugin > >> > >> Hi, > >> We never had any formalised code formatting rules nor ever provided any > >> formatters for different IDEs (at least not that I am aware of). > >> That often leads to undesired formatting changes in PRs. > >> I propose to introduce > >> https://github.com/diffplug/spotless/tree/main/plugin-maven to > >> automatically enforce certain formatting rules during build (as well as > to > >> optionally apply those). > >> > >> There are quite some built-in rule sets. > >> Apache Maven uses > https://github.com/diffplug/spotless/tree/main/plugin- > >> maven#palantir-java-format and > >> https://github.com/diffplug/spotless/tree/main/plugin-maven#maven-pom > >> quite successfully for a while now. > >> > >> I am open to using another rule set, but the important bit is that we > can > >> enforce that across different IDEs easily during the build and fixing > is > >> easy for contributors/committers as well. > >> > >> WDYT? > >> > >> Konrad
Re: Introduce spotless-maven-plugin
The basic idea is to introduce that with a new parent pom. Once a module adopts this new parent version, it needs to manually reformat everything once to not fail the build. This is a one time effort together with updating to the new pom. Therefore it requires some opt-in per module anyways. Konrad > On 6. Dec 2023, at 10:53, Stefan Seifert > wrote: > > i like it to have tooling like this around (but if have no experience with > this tool). > > one important point is that e.g. for PRs it only validates newly added lines. > if all PRs fail due to inconsistent formatting in the existing codebase this > would be quite disruptive. > > stefan > >> -Original Message- >> From: Konrad Windszus >> Sent: Tuesday, December 5, 2023 9:18 PM >> To: dev@sling.apache.org >> Subject: Introduce spotless-maven-plugin >> >> Hi, >> We never had any formalised code formatting rules nor ever provided any >> formatters for different IDEs (at least not that I am aware of). >> That often leads to undesired formatting changes in PRs. >> I propose to introduce >> https://github.com/diffplug/spotless/tree/main/plugin-maven to >> automatically enforce certain formatting rules during build (as well as to >> optionally apply those). >> >> There are quite some built-in rule sets. >> Apache Maven uses https://github.com/diffplug/spotless/tree/main/plugin- >> maven#palantir-java-format and >> https://github.com/diffplug/spotless/tree/main/plugin-maven#maven-pom >> quite successfully for a while now. >> >> I am open to using another rule set, but the important bit is that we can >> enforce that across different IDEs easily during the build and fixing is >> easy for contributors/committers as well. >> >> WDYT? >> >> Konrad
RE: Introduce spotless-maven-plugin
i like it to have tooling like this around (but if have no experience with this tool). one important point is that e.g. for PRs it only validates newly added lines. if all PRs fail due to inconsistent formatting in the existing codebase this would be quite disruptive. stefan > -Original Message- > From: Konrad Windszus > Sent: Tuesday, December 5, 2023 9:18 PM > To: dev@sling.apache.org > Subject: Introduce spotless-maven-plugin > > Hi, > We never had any formalised code formatting rules nor ever provided any > formatters for different IDEs (at least not that I am aware of). > That often leads to undesired formatting changes in PRs. > I propose to introduce > https://github.com/diffplug/spotless/tree/main/plugin-maven to > automatically enforce certain formatting rules during build (as well as to > optionally apply those). > > There are quite some built-in rule sets. > Apache Maven uses https://github.com/diffplug/spotless/tree/main/plugin- > maven#palantir-java-format and > https://github.com/diffplug/spotless/tree/main/plugin-maven#maven-pom > quite successfully for a while now. > > I am open to using another rule set, but the important bit is that we can > enforce that across different IDEs easily during the build and fixing is > easy for contributors/committers as well. > > WDYT? > > Konrad
