On 20/10/2022 at 10:52:41 AM, Olivier Lamy wrote:
> definitely +1 for palantir.
>
Having been trusted with clang-format on a few things - tried out
spotless/pantir on a small project.
+1 on that - it’s nice, tho - I wish it could be 2 space indents, going
back to 4 spaces I suspect will be dis
On Wed, 19 Oct 2022 at 17:05, Guillaume Nodet wrote:
>
> After having given that more thought, I think it would make sense to simply
> reuse an existing formatter. It seems people are keen to align with a more
> traditional code style, so I see two possibilities:
> * palantir java format [1], a
After having given that more thought, I think it would make sense to simply
reuse an existing formatter. It seems people are keen to align with a more
traditional code style, so I see two possibilities:
* palantir java format [1], a 120 column, 4 spaces indent formatter, well
supported in Intell
For my own 2c, all the extra spacing drives me bananas.
Gary
On Mon, Oct 17, 2022, 09:26 Björn Raupach wrote:
> As someone who has just started opening some PRs for Maven, I would
> appreciate a more common Java Code Style.
>
> Not saying the style is bad, it is just confusing. Especially the C
As someone who has just started opening some PRs for Maven, I would
appreciate a more common Java Code Style.
Not saying the style is bad, it is just confusing. Especially the C++
like braces on a new line and the additional space between brackets.
Not sure this will help gaining more committ
Great job!
while we are here and changing format to something more compact.
I wonder if we could remove those extra (useless?) spaces such:
providers.add( requireNonNull( service, "service instance cannot be null" ) );
On Sat, 15 Oct 2022 at 17:50, Guillaume Nodet wrote:
>
> Le ven. 14 oct. 20
Le dim. 16 oct. 2022 à 10:11, Hervé Boutemy a
écrit :
> key prerequisite is to make sure we don't screw history with the big
> reformat
> commits: I absolutely need to keep git blame provide useful feedback.
>
Right, good point.
> it seems git blame --ignore-revs in Git 2.23 does what we need:
key prerequisite is to make sure we don't screw history with the big reformat
commits: I absolutely need to keep git blame provide useful feedback.
it seems git blame --ignore-revs in Git 2.23 does what we need:
https://michaelheap.com/git-ignore-rev/
Does anybody have experience with this and i
The only way this makes sense if it's fully automatic: all code is
formatted on merge, period, without extra commits or human thought.
Anything less is a big -1 from me.
On Wed, Oct 12, 2022 at 4:24 PM Guillaume Nodet wrote:
>
> Related to the discussion about automatically formatting and sorting
Le ven. 14 oct. 2022 à 22:14, Jochen Wiedmann a
écrit :
> Hi, Guillaume,
>
> rather than suggesting (and, what's worse: discussing) code change
> details: Is there, by any change, an existing code style, that we
> might adopt? In particular.could we reuse tools, like an Eclipse
> fornatter, and t
Hi, Guillaume,
rather than suggesting (and, what's worse: discussing) code change
details: Is there, by any change, an existing code style, that we
might adopt? In particular.could we reuse tools, like an Eclipse
fornatter, and the like?
Apart from that, I'd be more than happy about the changes,
+1
thanks for bringing up this topic
Enrico
Il giorno gio 13 ott 2022 alle ore 06:42 Guillaume Nodet
ha scritto:
>
> Le mer. 12 oct. 2022 à 22:02, Łukasz Dywicki a écrit :
>
> > Maybe its time to think of getting something like spotless [1] applied
> > to all maven sources?
> >
>
> I think I st
Le mer. 12 oct. 2022 à 22:02, Łukasz Dywicki a écrit :
> Maybe its time to think of getting something like spotless [1] applied
> to all maven sources?
>
I think I started the other discussion exactly for that purpose. It's not
specifically about spotless, but that one is just one tool, i was u
Agree on changing.
+1 for spotless. I already used it and it's very convenient!
And this will help to fix PRs which will be screwed.
I didn't check in detail the format changes.
But can we remove those extra useless spaces as well
such:
if ( !Files.exists( mojoConfigFile.toPath( ) ) )
On Thu,
Maybe its time to think of getting something like spotless [1] applied
to all maven sources?
I've seen it used in openhab [2] to rule multiple things and it works
well with large codebases with multiple contributors.
While it looks like there might be a middle ground between all IDEs,
such g
+1.
If useful we can also add an editorconfig file to automatically configure
IDEs but it’s a bit redundant with checkstyle
Le mer. 12 oct. 2022 à 18:24, Guillaume Nodet a écrit :
> Related to the discussion about automatically formatting and sorting
> imports, I think it would be nice, given
Non-binding +1 from me.
Gary
On Wed, Oct 12, 2022, 12:23 Guillaume Nodet wrote:
> Related to the discussion about automatically formatting and sorting
> imports, I think it would be nice, given the big reformat commits if those
> PRs are to be merged, to eventually discuss some changes to those
+1 for moving braces to the end line, it is difficult especially with
lambda expression
śr., 12 paź 2022 o 18:52 Tamás Cservenák napisał(a):
> +1 for this formatting change.
>
> T
>
> On Wed, Oct 12, 2022, 18:23 Guillaume Nodet wrote:
>
> > Related to the discussion about automatically format
+1 for this formatting change.
T
On Wed, Oct 12, 2022, 18:23 Guillaume Nodet wrote:
> Related to the discussion about automatically formatting and sorting
> imports, I think it would be nice, given the big reformat commits if those
> PRs are to be merged, to eventually discuss some changes to
Related to the discussion about automatically formatting and sorting
imports, I think it would be nice, given the big reformat commits if those
PRs are to be merged, to eventually discuss some changes to those code
style. In particular, I found out that the code is very sparse and my
screen is mor
ards,
> >
> > Hervé
> >
> > Le vendredi 17 septembre 2021, 23:19:25 CET Slawomir Jaranowski a écrit :
> > > Hi,
> > >
> > > We have described many rules about code style on Maven Code Style And
> >
> > Code
> >
> > > C
bjects, I'll merge in 1 week
>
> Regards,
>
> Hervé
>
> Le vendredi 17 septembre 2021, 23:19:25 CET Slawomir Jaranowski a écrit :
> > Hi,
> >
> > We have described many rules about code style on Maven Code Style And
> Code
> > Conventions [1].
> &g
; Hi,
>
> We have described many rules about code style on Maven Code Style And Code
> Conventions [1].
>
> One item missing for me is how java imports should be ordered and groped.
> I can setup it in IDE and it is very useful to use code formatting with
> tools.
> I thi
iles, or only looks in changed files.
> > > In the first step, preparing documentation is most important - may be
> > > enough.
> > >
> > > I've created issue for it [1]
> > >
> > > Please vote for a proposition or give another one.
> >
may be
> > > enough.
> > >
> > > I've created issue for it [1]
> > >
> > > Please vote for a proposition or give another one.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/MNGSITE-465
> > >
>
ttps://issues.apache.org/jira/browse/MNGSITE-465
> >
> >
> >
> > sob., 18 wrz 2021 o 20:38 Elliotte Rusty Harold
> > napisał(a):
> >
> >> simpler is better, though perhaps the fundamental rule should be don't
> >> reporter what's alread
; reporter what's already there. That is, avoid needless churn.
>>
>> My preferred style is:
>>
>> static imports
>> blank line
>> all other imports alphabetically
>>
>>
>> On Fri, Sep 17, 2021 at 9:19 PM Slawomir Jaranowski
>> wrote:
>>
gt; reporter what's already there. That is, avoid needless churn.
>
> My preferred style is:
>
> static imports
> blank line
> all other imports alphabetically
>
>
> On Fri, Sep 17, 2021 at 9:19 PM Slawomir Jaranowski
> wrote:
> >
> > Hi,
>
Hi,
>
> We have described many rules about code style on Maven Code Style And Code
> Conventions [1].
>
> One item missing for me is how java imports should be ordered and groped.
> I can setup it in IDE and it is very useful to use code formatting with
> tools.
> I think th
Hi,
We have described many rules about code style on Maven Code Style And Code
Conventions [1].
One item missing for me is how java imports should be ordered and groped.
I can setup it in IDE and it is very useful to use code formatting with
tools.
I think that all propositions in this case will
one,
> I have answered to you @commons-dev ml.
> Sorry for late response, I was on a usually long French lunch :-)
>
> 2011/5/14 Simone Tripodi :
>> Salut Hervé,
>> thanks for your kind reply!!! What we need is just a maven_checks.xml
>> sample for Maven code style, we
Hello Simone,
I have answered to you @commons-dev ml.
Sorry for late response, I was on a usually long French lunch :-)
2011/5/14 Simone Tripodi :
> Salut Hervé,
> thanks for your kind reply!!! What we need is just a maven_checks.xml
> sample for Maven code style, we already set up IDEs
Salut Hervé,
thanks for your kind reply!!! What we need is just a maven_checks.xml
sample for Maven code style, we already set up IDEs, pom and
reformatted code, now we need to setup the proper config!
Can you point me please to a checkstyle config? Many thanks in advance!
Bonne fin de semaine
Hi Simone,
IDE configurations are available at [1].
Checkstyle as a pom configuration is config/maven_checks.xml: see plugin
documentation [2] or Maven parent pom content [3].
Regards,
Hervé
[1] http://maven.apache.org/developers/conventions/code.html
[2] http://maven.apache.org/plugins/maven-
Hi all Maven devs,
in Apache Commons OGNL (incubation) we're planning to adopt Maven
conventions for code, can you point me please to a checkstyle
configuration for code style convention described on [1]?
Many thanks in advance, have a nice weekend!
Simo
[1] http://maven.apache.org/developers/conv
Dan Tran wrote:
What do you mean by "check it with checkstyle first"??
I mean that checkstyle should be the ultimate source of our code formats,
and I want code formatted with the eclipse codestyle to be checked
by checkstyle to see if it's perfect.
Any how, I would rather getting it from o
What do you mean by "check it with checkstyle first"??
Any how, I would rather getting it from official place (
http://maven.apache.org/developers/maven-eclipse-codestyle.xml )
in the long term.
I will checkout the one at the eclipse plugin's svn
-D
On 3/13/07, Kenney Westerhof <[EMAIL PROTEC
Dan Tran wrote:
http://maven.apache.org/developers/maven-eclipse-codestyle.xml
seems to be out of date ( the throws, extend, etc do not split )
Do we have another official one?
I use
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/optional/eclipse-config/maven-
http://maven.apache.org/developers/maven-eclipse-codestyle.xml
seems to be out of date ( the throws, extend, etc do not split )
Do we have another official one?
Thanks
-D
Hi,
I've prepared an intelliJ configuration for the code style that seems to
match the majority of the Maven codebase, and one most developers seem
happy to use going forward.
Drop it into ~/.IntelliJIDEA/config/codestyles and restart, then select
it from settings.
Does anyone have any comments
40 matches
Mail list logo
