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
emantic
> > (open braces, or things like close brace + else + open brace on 3 lines).
> > This makes me scroll a lot even on quite small methods to be able to read
> > the full code, and that's a pain imho.
> > So I'd like to propose the following changes t
hat's a pain imho.
> So I'd like to propose the following changes that would make maven code
> more readable imho (and also closer to the usual java coding style) :
> * move open braces to the end of the previous line on all places
> * allow the else keyword to be directly f
ble to
> > read
> > the full code, and that's a pain imho.
> > So I'd like to propose the following changes that would make maven code
> > more readable imho (and also closer to the usual java coding style) :
> > * move open braces to the end of the previou
on quite small methods to be able to
read
the full code, and that's a pain imho.
So I'd like to propose the following changes that would make maven code
more readable imho (and also closer to the usual java coding style) :
* move open braces to the end of the previous line on
s more wide than height, which means I can usually only see 30-40
> > > lines of code, where sometime half of them do not really carry any
> > semantic
> > > (open braces, or things like close brace + else + open brace on 3 lines).
> > > This makes me scroll a lot even
(open braces, or things like close brace + else + open brace on 3 lines).
> > This makes me scroll a lot even on quite small methods to be able to read
> > the full code, and that's a pain imho.
> > So I'd like to propose the following changes that would make maven code
>
This makes me scroll a lot even on quite small methods to be able to read
> the full code, and that's a pain imho.
> So I'd like to propose the following changes that would make maven code
> more readable imho (and also closer to the usual java coding style) :
> * move o
pain imho.
> So I'd like to propose the following changes that would make maven code
> more readable imho (and also closer to the usual java coding style) :
> * move open braces to the end of the previous line on all places
> * allow the else keyword to be directly followin
ime half of them do not really carry any
> semantic
> > (open braces, or things like close brace + else + open brace on 3 lines).
> > This makes me scroll a lot even on quite small methods to be able to read
> > the full code, and that's a pain imho.
> > So I'd like to pr
ngs like close brace + else + open brace on 3 lines).
> This makes me scroll a lot even on quite small methods to be able to read
> the full code, and that's a pain imho.
> So I'd like to propose the following changes that would make maven code
> more readable imho (and also
ans I can usually only see
> > 30-40
> > >> lines of code, where sometime half of them do not really carry any
> > semantic
> > >> (open braces, or things like close brace + else + open brace on 3
> > lines).
> > >> This makes me scroll a lot even on qui
, where sometime half of them do not really carry any
> semantic
> >> (open braces, or things like close brace + else + open brace on 3
> lines).
> >> This makes me scroll a lot even on quite small methods to be able to
> read
> >> the full code, and that's
mantic
> >> (open braces, or things like close brace + else + open brace on 3 lines).
> >> This makes me scroll a lot even on quite small methods to be able to read
> >> the full code, and that's a pain imho.
> >> So I'd like to propose the following c
(open braces, or things like close brace + else + open brace on 3 lines).
This makes me scroll a lot even on quite small methods to be able to read
the full code, and that's a pain imho.
So I'd like to propose the following changes that would make maven code
more readable imho (and als
e sometime half of them do not really carry any semantic
> (open braces, or things like close brace + else + open brace on 3 lines).
> This makes me scroll a lot even on quite small methods to be able to read
> the full code, and that's a pain imho.
> So I'd like to propose the
else + open brace on 3 lines).
> This makes me scroll a lot even on quite small methods to be able to read
> the full code, and that's a pain imho.
> So I'd like to propose the following changes that would make maven code
> more readable imho (and also closer to the usual jav
n quite small methods to be able to read
> > the full code, and that's a pain imho.
> > So I'd like to propose the following changes that would make maven code
> > more readable imho (and also closer to the usual java coding style) :
> > * move open braces to the end
e brace + else + open brace on 3 lines).
> This makes me scroll a lot even on quite small methods to be able to read
> the full code, and that's a pain imho.
> So I'd like to propose the following changes that would make maven code
> more readable imho (and also closer to the usual
, and that's a pain imho.
So I'd like to propose the following changes that would make maven code
more readable imho (and also closer to the usual java coding style) :
* move open braces to the end of the previous line on all places
* allow the else keyword to be directly following
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
I have solved this problem ,thanks .
the main class is Laucher
-- --
??: "Tibor Digana";
: 2019??8??21??(??) 4:59
??: "Maven Developers List";
: Re: I debug the latest maven code ,find this error,anyone
You are providing us with really minimum information.
So what are you debugging, what version or snapshot?
How you debug it and what's your command or test you run and what platform,
etc.
It happens only while debugging?
Ideal issues would report a bug in Jira.
On Wed, Aug 21, 2019 at 4:45 AM 星光 <
Caused by: java.lang.IllegalArgumentException: Can not set
org.apache.maven.repository.RepositorySystem field
org.apache.maven.project.DefaultProjectBuildingHelper.repositorySystem to
org.apache.maven.bridge.MavenRepositorySystem
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArg
[main] ERROR org.apache.maven.cli.MavenCli - java.util.NoSuchElementException
role: org.apache.maven.eventspy.internal.EventSpyDispatcher
roleHint:
what me
> baffled are the comments about bootstrap ?
>
>
>>
>>> On Oct 7, 2015, at 9:29 AM, Karl Heinz Marbaise wrote:
>>>
>>> Hi,
>>>
>>> i'm currently looking into the Maven code and stumbled over one thing which
>>>
in a pom which is packaging pom), but what
me baffled are the comments about bootstrap ?
On Oct 7, 2015, at 9:29 AM, Karl Heinz Marbaise wrote:
Hi,
i'm currently looking into the Maven code and stumbled over one thing which i
don't understand at the moment is:
The root pom
That it’s used in all projects not just selective ones so it’s directly
inherited by all. As to not have to declare in each POM.
> On Oct 7, 2015, at 9:29 AM, Karl Heinz Marbaise wrote:
>
> Hi,
>
> i'm currently looking into the Maven code and stumbled over one th
Hi,
i'm currently looking into the Maven code and stumbled over one thing
which i don't understand at the moment is:
The root pom contains directly dependencies to junit
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob_plain;f=pom.xml;hb=HEAD
But it does not contai
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
My opinion :
- We have to follow what we promote (conventions more particularly).
- Our conventions can evolve, and we have to ensure that above all, they are
improving teams productivity (it's a too important problem in java before
others like consistency, readability and maintainability).
My 2 c
Hi,
2008/12/26 Vincent Siveton :
> Hi Oleg,
>
> 2008/12/25, Oleg Gusakov :
>> Vincent Siveton wrote:
>>
>> > Hi,
>> >
>> > 2008/12/24, Oleg Gusakov :
>> >
>> > [SNIP]
>> >
>> >
>> >
>> > > Can you name one single reason why moving this file away and creating 6
>> > > additional folders on the way
Hi Oleg,
2008/12/25, Oleg Gusakov :
> Vincent Siveton wrote:
>
> > Hi,
> >
> > 2008/12/24, Oleg Gusakov :
> >
> > [SNIP]
> >
> >
> >
> > > Can you name one single reason why moving this file away and creating 6
> > > additional folders on the way that would not exist otherwise is
> beneficial?
>
I use hierarchical mode in Eclipse and it's a blast. I sympathize
towards anyone who feels conventions may slow them down, but Java
Resources shouldn't go into src/main/java because of a tooling
deficiency.
-
To unsubscribe, e-mai
Vincent Siveton wrote:
Hi,
2008/12/24, Oleg Gusakov :
[SNIP]
Can you name one single reason why moving this file away and creating 6
additional folders on the way that would not exist otherwise is beneficial?
Without using the argument "it's a convention"? :)
As said, that is truly
Benjamin,
Benjamin Bentmann wrote:
Oleg Gusakov wrote:
If this file sits in the src/main/java/... package - it's one mouse
click in Eclipse to open it. If I move it to src/main/resources/.. -
it becomes a multi-click - one has to click as many times as there
are members in the package name,
2008/12/25, Benjamin Bentmann :
> Hm, using either the hierarchical mode in combination with the "Fold empty
> packages" preference or the flat mode in the package explorer works for me
> with Eclipse 3.4.1.
>
> From my experience for flattening to work properly, Eclipse needs to ignore
> the ".s
Hi,
2008/12/24, Oleg Gusakov :
[SNIP]
> Can you name one single reason why moving this file away and creating 6
> additional folders on the way that would not exist otherwise is beneficial?
> Without using the argument "it's a convention"? :)
As said, that is truly what we (Maven and devs) are
Hi Oleg,
2008/12/24, Oleg Gusakov :
[SNIP]
> I also respect the conventions, but in this particular case the convention
> became counter-productive: I externalized all the messages into
> Messages.properties file per package and have to modify this file all the
> time.
Since we are a community
Oleg Gusakov wrote:
If this file sits in the src/main/java/... package - it's one mouse
click in Eclipse to open it. If I move it to src/main/resources/.. - it
becomes a multi-click - one has to click as many times as there are
members in the package name, because Eclipse does not respect "fla
I'm working on open-sourcing an annotation-based solution for
externalizing messages. I hope this is an opportunity to get some
quick feedback. Please let me know if I'm out-of-line.
Example Workflow:
Create an interface to hold messages. Annotate the methods with the
text of the default trans
Brian E. Fox wrote:
Let me respectfully disagree: I used to work for a company where I was
responsible for productivity of hundreds of developers. If I would've
introduced a change where they have to do 5 mouse clicks instead of 1 -
I would be out of job the next day.
Btw, eclipse has
On Thu, Dec 25, 2008 at 5:24 AM, Brian E. Fox wrote:
>
>>Can you name one single reason why moving this file away and creating 6
>>additional folders on the way that would not exist otherwise is
>>beneficial? Without using the argument "it's a convention"? :)
>
> Sure. What if you want to filter i
On Dec 24, 2008, at 10:58 AM, Brian E. Fox wrote:
Let me respectfully disagree: I used to work for a company where I
was
responsible for productivity of hundreds of developers. If I would've
introduced a change where they have to do 5 mouse clicks instead of
1 -
I would be out of job the n
On Dec 24, 2008, at 10:43 AM, Oleg Gusakov wrote:
Brian E. Fox wrote:
I also respect the conventions, but in this particular case the
convention became counter-productive: I externalized all the
messages into Messages.properties file per package and have to
modify this file all the time
>Let me respectfully disagree: I used to work for a company where I was
>responsible for productivity of hundreds of developers. If I would've
>introduced a change where they have to do 5 mouse clicks instead of 1 -
>I would be out of job the next day.
Btw, eclipse has tabs, last time I checked
>Can you name one single reason why moving this file away and creating 6
>additional folders on the way that would not exist otherwise is
>beneficial? Without using the argument "it's a convention"? :)
Sure. What if you want to filter it? This is trivial if you have it in
resources where it be
Brian E. Fox wrote:
I also respect the conventions, but in this particular case the
convention became counter-productive: I externalized all the messages
into Messages.properties file per package and have to modify this file
all the time.
If this file sits in the src/main/java/... p
>I also respect the conventions, but in this particular case the
>convention became counter-productive: I externalized all the messages
>into Messages.properties file per package and have to modify this file
>all the time.
>If this file sits in the src/main/java/... package - it's one mouse
>c
Vincent,
Vincent Siveton wrote:
Hi,
All Maven subprojects respect (AFAIK) the common directory structure
[1] of Maven. IMHO Maven sell speech is about convention, and Maven
should be the first place where it would be applied. There is nothing
about properties files in our convention [2], but I
Hi,
All Maven subprojects respect (AFAIK) the common directory structure
[1] of Maven. IMHO Maven sell speech is about convention, and Maven
should be the first place where it would be applied. There is nothing
about properties files in our convention [2], but I suggest to revert
these changes to
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
69 matches
Mail list logo
