There is no solution for that: https://github.com/CodeNarc/CodeNarc/issues/447
but to rewrite the code.
Just to mention
HTH
Jacques
Le 02/08/2023 à 19:42, Jacques Le Roux a écrit :
Hi,
We have set a Git pre-push hook in order to stop pushes with Checkstyle issues.
I propose to do the same for Codenarc
ttps://ci2.apache.org/#/builders/46/builds/575/steps/4/logs/stdio
Le 25/08/2023 à 19:58, Jacques Le Roux a écrit :
Hi,
While "./gradlew check" works in Linux (locally and Buildbot*). I have a
problem in Windows (at least Win7).
It does not show "CodeNarc complete
Hi,
A simple solution would be for Windows committers (I'm not sure there is any but me)
would be to use "|git push --no-verify"|
|Anyway Buildbot will remind us with a fail if any new Codenarc issue is pushed
|
|What do you think?|
|TIA
|
|Jacques
|
|
|
Le 25/08/2023 à 19:58,
Hi,
While "./gradlew check" works in Linux (locally and Buildbot*). I have a
problem in Windows (at least Win7).
It does not show "CodeNarc completed: (p1=0; p2=439; p3=4216)" and
codenarcGroovyScripts fails.
I'm not sure why yet...
Would be great if someone with las
Thanks Gil,
Anyone else with an opinion before I consider it lazy?
TIA
Jacques
Le 18/08/2023 à 14:06, gil.portenseigne a écrit :
Hello Jacques,
Yes it could be a good enhancement to control codenarc check when
pushing.
Thanks,
Gil
On 02/08/23 07:42, Jacques Le Roux wrote:
Hi,
We have
Hello Jacques,
Yes it could be a good enhancement to control codenarc check when
pushing.
Thanks,
Gil
On 02/08/23 07:42, Jacques Le Roux wrote:
> Hi,
>
> We have set a Git pre-push hook in order to stop pushes with Checkstyle
> issues.
>
> I propose to do the
Hi,
We have set a Git pre-push hook in order to stop pushes with Checkstyle issues.
I propose to do the same for Codenarc.
Currently Buildbot reports Codenarc issues but it's not a blocker.
What do you think ?
Jacques
Le 01/08/2023 à 17:32, Jacques Le Roux a écrit :
Le 01/08/2023 à 17:26, Jacques Le Roux a écrit :
\Rpackage (.*)\R => package $1\R
That's wrong, I'm checking special cases like when it's already OK
Because of that it's rather
\R\Rpackage (.*)\R => \Rpackage $1\R
Le 01/08/2023 à 17:26, Jacques Le Roux a écrit :
\Rpackage (.*)\R => package $1\R
That's wrong, I'm checking special cases like when it's already OK
Thanks Jacques!
Am 01.08.23 um 17:26 schrieb Jacques Le Roux:
Most of them indeed, there were though some remaining from previous
Codenarc work
It's easily fixed using respectively these regexp in both repos
\Rpackage (.*)\R => package $1\R
\R\R\R => \R\R
Result:
co
Most of them indeed, there were though some remaining from previous Codenarc
work
It's easily fixed using respectively these regexp in both repos
\Rpackage (.*)\R => package $1\R
\R\R\R => \R\R
Result:
codenarc {
setConfigFile(new File('config/codenarc/codenarc.
nventions.
codenarc {
setConfigFile(new File('config/codenarc/codenarc.groovy'))
setMaxPriority1Violations(0)
setMaxPriority2Violations(448)
setMaxPriority3Violations(4396)
}
This is not blocking and according to
https://github.com/apache/ofbiz-framework/commit/5d2301637f
MaxPriorities
Hi,
With last commit,
https://ci2.apache.org/#/builders/46/builds/567/steps/4/logs/stdio, we have
less priority 2 but more priority 3:
https://nightlies.apache.org/ofbiz/trunk/groovyScripts.html
<>
Compare with main build.gradle:
// Checks OFBiz Groovy coding conventions.
co
have reviewed as I think each comment will appear separately in the
PR's
conversation view.
However, with such a large PR where we hope to get several reviewers
involved I think we do need a mechanism to track reviewed files.
I created a page here - Codenarc integration review tracker - OFBiz
volved I think we do need a mechanism to track reviewed files.
I created a page here - Codenarc integration review tracker - OFBiz
Project
Open Wiki - Apache Software Foundation
<
https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker
-
suggesting an app
ll appear separately in the
PR's
conversation view.
However, with such a large PR where we hope to get several reviewers
involved I think we do need a mechanism to track reviewed files.
I created a page here - Codenarc integration review tracker - OFBiz
Project
Open Wiki - Apache Softwar
involved I think we do need a mechanism to track reviewed files.
I created a page here - Codenarc integration review tracker - OFBiz
Project
Open Wiki - Apache Software Foundation
<
https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker
-
suggestin
Le 28/02/2023 à 14:08, Nicolas Malin a écrit :
Progress on this review is being tracked through the above linked
Confluence document. To avoid clashes between review participants, I
suggest you choose a file to review at random from the table in the
document, review the file and then update the
groovy code to satisfy the guidance from the Codenarc
static analysis tool.It is not intended to change OFBiz behaviour in any
way.
All committers, please could you help review this PR by following the
process outlined here:
https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration
Hello Committers,
We need your help!
We have a very large, but hopefully simple, PR that we need to review -
https://github.com/apache/ofbiz-framework/pull/517
This PR alters OFBIz groovy code to satisfy the guidance from the Codenarc
static analysis tool.It is not intended to change OFBiz
No, we should be able to create multiple reviews within a single PR - or
perhaps add a comment to an existing review.
On Tue, 7 Feb 2023 at 17:44, Jacques Le Roux
wrote:
> Le 07/02/2023 à 16:53, gil.portenseigne a écrit :
> > yes ongoing review are private, you need to finish it to let other
Le 07/02/2023 à 16:53, gil.portenseigne a écrit :
yes ongoing review are private, you need to finish it to let other see
your comments and suggestions.
Does it mean that you need to review ALL before others see what you commented
?
Thanks
Jacques
gt; > > > this
> > > > > > review.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Dan.
> > > > > >
> > > > > >
> > > > > > On Fri, 27 Jan 2
On Fri, 27 Jan 2023 at 17:05, gil.portenseigne <
> > > > > gil.portensei...@nereide.fr> wrote:
> > > > >
> > > > >> I got to leave, but i generated in confluence a list of check, is
> that
> > > > >> good enough ?
>
i generated in confluence a list of check, is that
> > > >> good enough ?
> > > >>
> > > >> Gil
> > > >> On 27/01/23 05:41, gil.portenseigne wrote:
> > > >> > Hello, indeed, that will generate much spam, i did some before
> >
Le 06/02/2023 à 09:18, gil.portenseigne a écrit :
I will try to advance this week in the review process.
Hi Gil, Daniel, All,
I'll try to the apply the 10 min principle to the review. Reviewing 5
documents/day should allow to do my part (150) in roughly a month :)
Jacques
for conluence.
> > >> >
> > >> > Gil
> > >> >
> > >> >
> > >> > On 27/01/23 04:14, Daniel Watford wrote:
> > >> > > Hi Gill and Jacques,
> > >> > >
> > >> > >
> >> > > Hi Gill and Jacques,
> >> > >
> >> > > I don't think we should add comments to the PR to track the files
> >> that we
> >> > > have reviewed as I think each comment will appear separately in the
> >> PR's
> &g
Hi Michael, All,
If you are interested in CodeNarc integration you may help to review
https://github.com/apache/ofbiz-framework/pull/517
And mark your reviews at
https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker
TIA
Jacques
Le 12/12/2021 à 17:55, Jacques
gt;> we
>>>> have reviewed as I think each comment will appear separately in the
>> PR's
>>>> conversation view.
>>>>
>>>> However, with such a large PR where we hope to get several reviewers
>>>> involved I think we do need a me
h comment will appear separately in the
PR's
conversation view.
However, with such a large PR where we hope to get several reviewers
involved I think we do need a mechanism to track reviewed files.
I created a page here - Codenarc integration review tracker - OFBiz
Project
Open Wiki - Apache
n't think we should add comments to the PR to track the files
>> that we
>> > > have reviewed as I think each comment will appear separately in the
>> PR's
>> > > conversation view.
>> > >
>> > > However, with such a large PR where we hope t
eparately in the
> PR's
> > > conversation view.
> > >
> > > However, with such a large PR where we hope to get several reviewers
> > > involved I think we do need a mechanism to track reviewed files.
> > >
> > > I created a page here - Codenarc in
will appear separately in the PR's
conversation view.
However, with such a large PR where we hope to get several reviewers
involved I think we do need a mechanism to track reviewed files.
I created a page here - Codenarc integration review tracker - OFBiz Project
Open Wiki - Apache Software
> > However, with such a large PR where we hope to get several reviewers
> > involved I think we do need a mechanism to track reviewed files.
> >
> > I created a page here - Codenarc integration review tracker - OFBiz Project
> > Open Wiki - Apache Software Foundati
I think each comment will appear separately in the PR's
> conversation view.
>
> However, with such a large PR where we hope to get several reviewers
> involved I think we do need a mechanism to track reviewed files.
>
> I created a page here - Codenarc integration review track
to track reviewed files.
I created a page here - Codenarc integration review tracker - OFBiz Project
Open Wiki - Apache Software Foundation
<https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker>
-
suggesting an approach.
If the approach is acceptable th
Oops, i did a fixup commit with push force that remove all comments in
the pull request... Will not do that again.
I fixed the detected typo.
gil
On 27/01/23 02:56, Jacques Le Roux wrote:
> Ah OK, sounds better indeed
>
> Le 27/01/2023 à 14:06, gil.portenseigne a écrit :
> > The idea is not to
Ah OK, sounds better indeed
Le 27/01/2023 à 14:06, gil.portenseigne a écrit :
The idea is not to modify the files, but to add a comment into the pull
request. Those allowing each reviewer to check the viewed checkbox if a
comment is present, to collapse already reviewed files.
So no need
The idea is not to modify the files, but to add a comment into the pull
request. Those allowing each reviewer to check the viewed checkbox if a
comment is present, to collapse already reviewed files.
So no need further action, apart the real code modification request,
when commiting the code.
On
Hi Gil, Daniel,
I agree Gil, I just tried before seeing your message and came to the same
conclusion.
With a comment at top we would need to remove it later, right? Could be easy if
it's the same unique words in every file.
Jacques
Le 27/01/2023 à 10:41, gil.portenseigne a écrit :
Hi
Hi Daniel, Jacques,
I wonders the same, the "Review changes" do not seems to concern one
file but the whole pull request, there is a review checkbox, but it
seems to be personal, i checked the first one
(AcctgAdminServices.groovy) for testing purpose.
What we could do is to add a comment at the
Hi Daniel,
In "Files changed" tab*, when you select a file, the "Review changes" button
allows you to comment, approve or request changes on this file.
I guess "approve" is what you are looking for?
* https://github.com/apache/ofbiz-framework/pull/517/files
Le 26/01/2023 à 17:26, Daniel
g) work
> :)
> >>
> >> +1 from my side
> >>
> >> Jacques
> >>
> >>
> >> Le 21/01/2023 à 09:57, Gil Portenseigne a écrit :
> >>> Yes, it is considered best practice to avoid gstring usage when not
> needed.
> >>>
Portenseigne a écrit :
Yes, it is considered best practice to avoid gstring usage when not needed.
Like for others, we can decide to not apply this rule.
The detailed rule from codenarc documentation :
*UnnecessaryGString** Rule*
/Since //CodeNarc// 0.13/
String objects should be created with single
gt;
>> Like for others, we can decide to not apply this rule.
>>
>> The detailed rule from codenarc documentation :
>>
>>
>> *UnnecessaryGString** Rule*
>>
>> /Since //CodeNarc// 0.13/
>>
>> String objects should be created with single qu
, it is considered best practice to avoid gstring usage when not needed.
Like for others, we can decide to not apply this rule.
The detailed rule from codenarc documentation :
*UnnecessaryGString** Rule*
/Since //CodeNarc// 0.13/
String objects should be created with single quotes, and GString
Yes, it is considered best practice to avoid gstring usage when not needed.
Like for others, we can decide to not apply this rule.
The detailed rule from codenarc documentation :
*UnnecessaryGString** Rule*
/Since //CodeNarc// 0.13/
String objects should be created with single quotes
,
That is with pleasure, that I managed to integrate into OFBiz framework
(no plugins yet) Codenarc, and that the build is successful under java
17.
https://github.com/apache/ofbiz-framework/pull/517#issuecomment-1398487745
I tried to isolate rule fixes in separated commits, there are a lot (133
Thank you very much Gil,
+1 for a big squash... after some reviews...
Jacques
Le 20/01/2023 à 15:53, gil.portenseigne a écrit :
Hello Devs,
That is with pleasure, that I managed to integrate into OFBiz framework
(no plugins yet) Codenarc, and that the build is successful under java
17
Hello Devs,
That is with pleasure, that I managed to integrate into OFBiz framework
(no plugins yet) Codenarc, and that the build is successful under java
17.
https://github.com/apache/ofbiz-framework/pull/517#issuecomment-1398487745
I tried to isolate rule fixes in separated commits
l : Same as String Literal
> +1
> > * UnnecessarySetter : Same as UnnecessaryGetter
>
> +1
>
> Thanks
>
> Jacques
>
> >
> > Thanks,
> >
> > Gil
> >
> > On 2022/07/04 15:24:43 Gil Portenseigne wrote:
> > > Hello Devs,
> &g
like to continue Codenarc integration in OFBiz (OFBIZ-11167).
For those who are not aware, Codenarc is an analysis tools for Groovy
for defects, bad practices, inconsistencies, style issues and more.
For this purpose we need to agree about the ruleset to put in place.
I took as a basis the ruleset
as UnnecessaryGetter
Thanks,
Gil
On 2022/07/04 15:24:43 Gil Portenseigne wrote:
> Hello Devs,
>
> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>
> For those who are not aware, Codenarc is an analysis tools for Groovy
> for defects, bad practices, inconsisten
.
Thanks for the initiative,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 04.07.22 um 17:24 schrieb Gil Portenseigne:
> Hello Devs,
>
> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>
> For those who are not aware, Codenarc is an analysis tools for Groov
Forgot the ref https://github.com/CodeNarc/CodeNarc/issues/331
Le 12 juillet 2022 21:11:13 GMT+02:00, Gil Portenseigne
a écrit :
>Hello,
>
>I agree with you, i find out here [1] that it is customisable.
>
>So we can agree upon this variation of the rule !
>
>I have not
out, my preference for
>legibility has always been [someKey: someValue]. I find
>[someKey:someValue] a bit too condensed and harder to differentiate key
>from value.
>
>Regards
>Scott
>
>On Mon, 4 Jul 2022 at 16:25, Gil Portenseigne
>wrote:
>
>> Hello Devs,
>>
>
; I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>
> For those who are not aware, Codenarc is an analysis tools for Groovy
> for defects, bad practices, inconsistencies, style issues and more.
>
> For this purpose we need to agree about the ruleset to put in plac
not so sure about, my preference for
legibility has always been [someKey: someValue]. I find
[someKey:someValue] a bit too condensed and harder to differentiate key
from value.
Regards
Scott
On Mon, 4 Jul 2022 at 16:25, Gil Portenseigne
wrote:
> Hello Devs,
>
> I would like to continue
+1
Thank you Gil!
Jacopo
On Mon, Jul 4, 2022 at 5:24 PM Gil Portenseigne
wrote:
> Hello Devs,
>
> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>
> For those who are not aware, Codenarc is an analysis tools for Groovy
> for defects, bad practice
,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 04.07.22 um 17:24 schrieb Gil Portenseigne:
Hello Devs,
I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
For those who are not aware, Codenarc is an analysis tools for Groovy
for defects, bad practices, inconsistencies, style
Hi Gil,
Great initiative, so far it seems we have a lazy consensus
We (almost*) did it for Java, why not for Groovy :)
Jacques
* OFBIZ-12341
Le 04/07/2022 à 17:24, Gil Portenseigne a écrit :
Hello Devs,
I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
For those who
Hello Devs,
I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
For those who are not aware, Codenarc is an analysis tools for Groovy
for defects, bad practices, inconsistencies, style issues and more.
For this purpose we need to agree about the ruleset to put in place.
I
Hi Michael,
I tried again this afternoon. The Codenarc last version needs Gradle > 6.5. I
tried with 7.3 and 7.3.1 to no avail.
I guess you saw my comments in OFBIZ-12400 and
https://github.com/apache/ofbiz-framework/pull/354
Jacques
Le 12/10/2017 à 12:44, Michael Brohl a écrit :
Hi Jacq
searching for a way to analyze Groovy code in
OFBiz.
Can you tell us what the problem was?
Thanks,
Michael
Am 18.09.17 um 13:12 schrieb Jacques Le Roux:
Hi,
I wanted to test the CodeNarc Gradle plugin https://docs.gradle.org/current/userguide/codenarc_plugin.html to see how it would complete the
Hi Jacques,
just stumbled over this while searching for a way to analyze Groovy code
in OFBiz.
Can you tell us what the problem was?
Thanks,
Michael
Am 18.09.17 um 13:12 schrieb Jacques Le Roux:
Hi,
I wanted to test the CodeNarc Gradle plugin
https://docs.gradle.org/current/userguide
Hi,
I wanted to test the CodeNarc Gradle plugin https://docs.gradle.org/current/userguide/codenarc_plugin.html to see how it would complete the work done
with FindBugs
But, despite some efforts, I was unable to make it work with OFBiz
Has someone an experience with it? Should we care
67 matches
Mail list logo
