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
Thanks for restoring compatibility!
Saves us from having to use reflection to be compatible with 3.x and 4.x.
Cheers,
Marc
On 8. Oct 2022 at 08:57:27, Tamás Cservenák wrote:
> Howdy,
>
> just one remark: as I said, Maven so far never had a "surface" meant to be
> an API, on the other hand Ma
17 matches
Mail list logo
