+1, BUT in addition to Hervé's answer:
Create a file '.git-blame-ignore-revs', which seems to be a common convention:
https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame
This way, we can see CODE changes via diff/blame without those nasty
formatting changes.
---
For the fo
only one concern: clarify our convention for the initial reformat of any Git
repository so that it works with git blame --ignore-revs
(I hope current tools support for this feature is good enough nowadays)
Regards,
Hervé
Le vendredi 14 octobre 2022, 10:41:30 CEST Guillaume Nodet a écrit :
> So
Hello Tomas and Guillaume,
On 13.10.2022 20:58, Tamás Cservenák wrote:
Agree, it does overhead, just like checkstyle (already present) does, but
trust me, minimal overhead (please try some of the PRs).
I might be overreacting about making it default, cause openhab does also
static code analysis
Can I answer that? Because devs are principled, and the thought of the
build changing source is anathema.
In practice it happens with versions, release, sortpom plugins so why not
format too.
Personally I draw the line at commit time.
But crickey, in Golang you cant even save an incorrectly formatt
So here's my new proposal.
I've already merged the two first PRs which did not change anything, as
they were just about moving the existing resources (eclipse and intellij
xml config) from the website to maven-shared and updating the website.
I've updated the two interesting PRs to use spotless,
Howdy,
On Thu, Oct 13, 2022 at 12:50 PM Olivier Lamy wrote:
> Then in case of failure, the committer can just run
> foo-bar-formatted-plugin:format.
>
>
Why on earth yet another _manual_ step in all this process?
"in case of failure committer run" part would not exist in this story,
that's t
Lukasz,
Agree, it does overhead, just like checkstyle (already present) does, but
trust me, minimal overhead (please try some of the PRs).
Am unsure about your second point: the error message will point to a line
that, if the user opens it in whatever IDE/editor, will correspond to where
the error
Howdy,
On Thu, Oct 13, 2022 at 1:55 PM Jeff Jensen <
jeffjen...@upstairstechnology.com> wrote:
> I think reformatting files during every build is less desirable and adds
> risk. I prefer the build to *enforce* the desired results, failing as
> needed, and configuring the IDEs to auto-format the
On Thu, Oct 13, 2022 at 6:36 PM Slawomir Jaranowski
wrote:
> +1 for simply checking during build, formatting should be done by
> developer, nevermind if using plugin or by IDE
> It can work like checkstyle.
>
>
This is where we are today. And "done by developer" is either IDE, either
some tool, a
On Thu, Oct 13, 2022 at 6:26 PM David Jencks
wrote:
> A possible data point… For a while I worked on isomorphic-git (javascript)
> which had a pre-commit hook to format the code. It was rather surprising at
> first, but I ended up really liking it, more than projects that attempted
> to check the
So if the community prefer enforcing strict formatting using a validation
step during the build, I'll update the PRs on maven-core and
maven-resolver to leverage the added resources (xml format, header, etc...)
and create two profiles for validation / reformatting, leveraging spotless
(I've just
czw., 13 paź 2022 o 17:41 Guillaume Nodet napisał(a):
> So the plugin I'm using actually has a validate goal which won't do any
> formatting, but simply fail the build if the code is not correctly
> formatted.
> So it should be easy add that goal in PRs. Any PR will simply quickly fail
> if the
A possible data point… For a while I worked on isomorphic-git (javascript)
which had a pre-commit hook to format the code. It was rather surprising at
first, but I ended up really liking it, more than projects that attempted to
check the formatting during the build, which were susceptible to way
Le jeu. 13 oct. 2022 à 17:31, Guillaume Nodet a écrit :
>
>
> Le jeu. 13 oct. 2022 à 17:13, Łukasz Dywicki a
> écrit :
>
>> Some of findings I have:
>>
>> - Static code analysis might be slow, reformatting code will add
>> additional time to the build which might not be desired for developer
>>
Le jeu. 13 oct. 2022 à 17:13, Łukasz Dywicki a écrit :
> Some of findings I have:
>
> - Static code analysis might be slow, reformatting code will add
> additional time to the build which might not be desired for developer
> experience
>
This is usually reduced to 0 because the plugins just chec
Some of findings I have:
- Static code analysis might be slow, reformatting code will add
additional time to the build which might not be desired for developer
experience
- Error messages produced after reformatting might mistake first time
contributors who are not familiar with reformatting s
Le jeu. 13 oct. 2022 à 12:50, Olivier Lamy a écrit :
> On Thu, 13 Oct 2022 at 17:47, Tamás Cservenák wrote:
> >
> > Howdy,
> >
> > to not get lost in implementation details, it is really unimportant
> > (spotless, this or that...)
> >
> > What IS important is that we agree to implement "IDE agno
I think reformatting files during every build is less desirable and adds
risk. I prefer the build to *enforce* the desired results, failing as
needed, and configuring the IDEs to auto-format the files on save. Both
Eclipse and IntelliJ have many configurable "save actions" for file format
and cle
On Thu, 13 Oct 2022 at 17:47, Tamás Cservenák wrote:
>
> Howdy,
>
> to not get lost in implementation details, it is really unimportant
> (spotless, this or that...)
>
> What IS important is that we agree to implement "IDE agnostic source
> formatting", that happens during build
> (by maven plugin
To answer my own question:
https://maven.apache.org/scm/maven-scm-plugin/check-local-modification-mojo.html
T
On Thu, Oct 13, 2022 at 9:47 AM Tamás Cservenák wrote:
> Howdy,
>
> to not get lost in implementation details, it is really unimportant
> (spotless, this or that...)
>
> What IS import
Howdy,
to not get lost in implementation details, it is really unimportant
(spotless, this or that...)
What IS important is that we agree to implement "IDE agnostic source
formatting", that happens during build
(by maven plugin). This means _everyone_ will end up with 100% the same
result.
The o
Formatting happens during build, so once merged all we need is to merge
master into PR branches...
T
On Thu, Oct 13, 2022 at 8:40 AM Sylwester Lachiewicz
wrote:
> What about already open PR with some features or bug fixes.
> Don't we should review and merge it before reformatting code - otherwi
What about already open PR with some features or bug fixes.
Don't we should review and merge it before reformatting code - otherwise we
will have lots of merge conflicts and over time no one will have energy to
review it?
Sylwester
śr., 12 paź 2022, 18:23 użytkownik Guillaume Nodet
napisał:
> I
On Thu, 13 Oct 2022 at 14:38, Guillaume Nodet wrote:
>
> Le jeu. 13 oct. 2022 à 05:36, Olivier Lamy a écrit :
>
> > On Thu, 13 Oct 2022 at 02:23, Guillaume Nodet wrote:
> > >
> > > I'd like to propose merging the following PRs:
> > > * https://github.com/apache/maven-shared-resources/pull/1
> >
Le jeu. 13 oct. 2022 à 05:36, Olivier Lamy a écrit :
> On Thu, 13 Oct 2022 at 02:23, Guillaume Nodet wrote:
> >
> > I'd like to propose merging the following PRs:
> > * https://github.com/apache/maven-shared-resources/pull/1
> > * https://github.com/apache/maven-site/pull/329
> > * https://gi
On Thu, 13 Oct 2022 at 02:23, Guillaume Nodet wrote:
>
> I'd like to propose merging the following PRs:
> * https://github.com/apache/maven-shared-resources/pull/1
> * https://github.com/apache/maven-site/pull/329
> * https://github.com/apache/maven/pull/824
> * https://github.com/apache/maven
Hi,
Generally I'm ok for such automatic tasks - we should test if the provided
configuration for the IDE is completed and when we execute reformat code in
the IDE we will have the same result.
śr., 12 paź 2022 o 18:51 Tamás Cservenák napisał(a):
> +1 for this. Tested on resolver, that has many
+1 for this. Tested on resolver, that has many old/untouched and hence,
badly formatted sources.
T
On Wed, Oct 12, 2022, 18:23 Guillaume Nodet wrote:
> I'd like to propose merging the following PRs:
> * https://github.com/apache/maven-shared-resources/pull/1
> * https://github.com/apache/mave
I'd like to propose merging the following PRs:
* https://github.com/apache/maven-shared-resources/pull/1
* https://github.com/apache/maven-site/pull/329
* https://github.com/apache/maven/pull/824
* https://github.com/apache/maven-resolver/pull/147
... and more to come
The idea is to use plugin
29 matches
Mail list logo
