You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Yasser Zamani <ya...@live.com> on 2017/11/07 18:16:25 UTC
Re: Would we need to achieve better place in trends ranking?
On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
> less static util classes and coupled code
I started playing with JDepend [1] to see if I can have a graphical
anatomy of Struts :) and see if any wrong connection has been
established during development.
However, it is not updated for several years but I try it; if you @dev
know a better tool please let me know.
Then, I also will try if I can add CheckStyle [2] tool to unit tests
which I spotted during my research. Generally, I love to work on if I
can do something nice to also test and verify design, code, security and
etc qualities beside our unit tests during our continuous developments.
e.g. using tools like JDpend, CheckStyle, XRadar, etc.
Also I love to see if I can run our tests in parallel to speed up things
at all :)
[1] https://github.com/clarkware/jdepend
[2] https://github.com/checkstyle/checkstyle
[3] http://xradar.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: @PMC, a few INFRA request?
Posted by Yasser Zamani <ya...@apache.org>.
On 12/4/2017 10:31 PM, Lukasz Lenart wrote:
> I'm not sure if JDepend would be the same
You're right that it's not same and as popular as. However it's listed
in `External Analysers` of official documentation [1] so I hope it
should work.
I mentioned it because it seems with GitHub plugin can comment on PRs
nice warnings.
For example it seems we can set "Maximum distance of a package allowed"
and it may can comment a warning on a PR which exceeds this maximum ("A
package squarely on the main sequence is optimally balanced with respect
to its abstractness and stability. Ideal packages are either completely
abstract and stable (x=0, y=1) or completely concrete and instable (x=1,
y=0)").
Or for example "Maximum instability of a package allowed" [3] could be
set ("This metric is an indicator of the package's resilience to change").
There are other nice metrics present [4] e.g. "Maximum number of other
packages allowed to depend upon classes within the package" or "Maximum
number of other packages that the classes in the package are allowed to
depend upon".
The only bad thing (maybe, I'm not sure) that I found is every package
has to have `package-info.java` elsewhere Sonar is not able to assign
issues. In other side maybe it's nice to have these and tune each
package to keep them healthy during our daily development via several
pull requests. I think it will make reviewing easier also.
Anyway we can also do these without Sonar and `package-info.java` but
needs time to script.
I don't know if we don't or do like `package-info.java` for each
package. But if we don't have issue (I don't have), and if JDepend
plugin can work with GitHub plugin to comment issues on PR (I think it
can) then I really down with it :)
Thank you so much for your attention,
Yasser.
[1] https://docs.sonarqube.org/display/PLUG/Plugin+Library
[2]
https://github.com/willemsrb/sonar-jdepend-plugin/blob/master/src/main/java/nl/futureedge/sonar/plugin/jdepend/rules/DistanceFromMainSequenceRule.java#L50
[3]
https://github.com/willemsrb/sonar-jdepend-plugin/blob/master/src/main/java/nl/futureedge/sonar/plugin/jdepend/rules/InstabilityRule.java#L50
[4]
https://github.com/willemsrb/sonar-jdepend-plugin/blob/master/src/main/java/nl/futureedge/sonar/plugin/jdepend/rules
Re: @PMC, a few INFRA request?
Posted by Lukasz Lenart <lu...@apache.org>.
At some point com.opensymphony.xwork package should be gone -
basically you can treat this package as equal to org.apache.struts2
I think, the Sonar GitHub plugin would be a nice addition but I'm not
sure if JDepend would be the same.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2017-12-01 15:06 GMT+01:00 Yasser Zamani <ya...@apache.org>:
>
>
> On 11/11/2017 12:18 PM, Lukasz Lenart wrote:
>> Good idea, working on that:) Started with coveralls but other
>> improvements are welcome:)
>>
>
> Thanks! I see it's interesting :)
>
> I looked for coupling reports. As a simple example if a PR added
> `org.apache.struts2` dependency to `com.opensymphony.xwork2` I like a
> comment on PR as a warning. I found JDepend which has an interesting
> metric `Distance from the Main Sequence (D)` [1] so I also thought if I
> can comment on PR if it increases D for any package. Or if it adds a new
> dependency to a package which has high Instability [2].
>
> I could not find what I exactly want, still. Maybe we will have to write
> some script.
>
> But during my work I saw Sonar has two interesting plugin, `GitHub
> Plugin` [3] and `Sonar plugin for jDepend` [4]. I myself like them a lot
> but did not discuss them with INFRA [5] ("needs to come from your
> Project Management Committee. That ensures that the requests are
> official, and not just an individual user's desire").
>
> Please consider if you like and found some time.
>
> Sincerely Yours,
> Yasser
>
> [1] https://github.com/clarkware/jdepend/blob/master/docs/JDepend.html#L221
> [2] https://github.com/clarkware/jdepend/blob/master/docs/JDepend.html#L209
> [3] https://docs.sonarqube.org/display/PLUG/GitHub+Plugin
> [4] https://github.com/willemsrb/sonar-jdepend-plugin
> [5] https://www.apache.org/dev/committers.html#infrastructure-change-request
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
@PMC, a few INFRA request?
Posted by Yasser Zamani <ya...@apache.org>.
On 11/11/2017 12:18 PM, Lukasz Lenart wrote:
> Good idea, working on that:) Started with coveralls but other
> improvements are welcome:)
>
Thanks! I see it's interesting :)
I looked for coupling reports. As a simple example if a PR added
`org.apache.struts2` dependency to `com.opensymphony.xwork2` I like a
comment on PR as a warning. I found JDepend which has an interesting
metric `Distance from the Main Sequence (D)` [1] so I also thought if I
can comment on PR if it increases D for any package. Or if it adds a new
dependency to a package which has high Instability [2].
I could not find what I exactly want, still. Maybe we will have to write
some script.
But during my work I saw Sonar has two interesting plugin, `GitHub
Plugin` [3] and `Sonar plugin for jDepend` [4]. I myself like them a lot
but did not discuss them with INFRA [5] ("needs to come from your
Project Management Committee. That ensures that the requests are
official, and not just an individual user's desire").
Please consider if you like and found some time.
Sincerely Yours,
Yasser
[1] https://github.com/clarkware/jdepend/blob/master/docs/JDepend.html#L221
[2] https://github.com/clarkware/jdepend/blob/master/docs/JDepend.html#L209
[3] https://docs.sonarqube.org/display/PLUG/GitHub+Plugin
[4] https://github.com/willemsrb/sonar-jdepend-plugin
[5] https://www.apache.org/dev/committers.html#infrastructure-change-request
Re: Would we need to achieve better place in trends ranking?
Posted by Lukasz Lenart <lu...@apache.org>.
2017-11-10 11:35 GMT+01:00 Yasser Zamani <ya...@live.com>:
> However, I thought about bring these to our maven build and github
> system. I saw this approach a few month ago with Apache commons-lang.
> When I requested a pull, I saw it fails because I don't add a @since tag
> or because I don't use {} for a one line if statement! (they have
> apache-rat:check clirr:check checkstyle:check in their maven build).
> They also comment if the PR increase or decrease the current test
> coverage [1].
>
> I am thinking about if we can add nice checkers to our maven build and
> git system little by little. The positive point is, at first place i.e.
> the PR or the commit, we block making things worse by failing the build
> if our quality metrics exceed some thresholds.
>
> I know already there are a lot of Sonar issues but maybe we can ignore
> current old ones and fail the build if new ones added at first place
> i.e. a PR or commit :)
>
> Isn't it better to resolve such issues at first place they occur? i.e.
> forcing committer or pull requester to resolve them at place. Or maybe
> you prefer to resolve newly added ones just before release in separate
> commit(s)?
>
> [1] https://github.com/apache/commons-lang/pull/261#issuecomment-289265370
Good idea, working on that :) Started with coveralls but other
improvements are welcome :)
https://github.com/apache/struts/pull/183
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Would we need to achieve better place in trends ranking?
Posted by Yasser Zamani <ya...@live.com>.
On 11/10/2017 12:58 PM, Lukasz Lenart wrote:
> I have added a Jenkins build to perform a Sonar analysis per push but
> I disabled spamming the dev@ list for now;-)
>
> https://builds.apache.org/analysis/overview?id=org.apache.struts%3Astruts2-parent
>
> 2017-11-08 11:18 GMT+01:00 Lukasz Lenart<lu...@apache.org>:
>> There is a Sonar instance running
>> https://builds.apache.org/analysis/
Thanks! the Sonar instance seems has great analysis.
However, I thought about bring these to our maven build and github
system. I saw this approach a few month ago with Apache commons-lang.
When I requested a pull, I saw it fails because I don't add a @since tag
or because I don't use {} for a one line if statement! (they have
apache-rat:check clirr:check checkstyle:check in their maven build).
They also comment if the PR increase or decrease the current test
coverage [1].
I am thinking about if we can add nice checkers to our maven build and
git system little by little. The positive point is, at first place i.e.
the PR or the commit, we block making things worse by failing the build
if our quality metrics exceed some thresholds.
I know already there are a lot of Sonar issues but maybe we can ignore
current old ones and fail the build if new ones added at first place
i.e. a PR or commit :)
Isn't it better to resolve such issues at first place they occur? i.e.
forcing committer or pull requester to resolve them at place. Or maybe
you prefer to resolve newly added ones just before release in separate
commit(s)?
[1] https://github.com/apache/commons-lang/pull/261#issuecomment-289265370
Re: Would we need to achieve better place in trends ranking?
Posted by Lukasz Lenart <lu...@apache.org>.
I have added a Jenkins build to perform a Sonar analysis per push but
I disabled spamming the dev@ list for now ;-)
https://builds.apache.org/analysis/overview?id=org.apache.struts%3Astruts2-parent
2017-11-08 11:18 GMT+01:00 Lukasz Lenart <lu...@apache.org>:
> There is a Sonar instance running
> https://builds.apache.org/analysis/
>
> 2017-11-07 19:16 GMT+01:00 Yasser Zamani <ya...@live.com>:
>>
>>
>> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
>>> less static util classes and coupled code
>>
>> I started playing with JDepend [1] to see if I can have a graphical
>> anatomy of Struts :) and see if any wrong connection has been
>> established during development.
>>
>> However, it is not updated for several years but I try it; if you @dev
>> know a better tool please let me know.
>>
>> Then, I also will try if I can add CheckStyle [2] tool to unit tests
>> which I spotted during my research. Generally, I love to work on if I
>> can do something nice to also test and verify design, code, security and
>> etc qualities beside our unit tests during our continuous developments.
>> e.g. using tools like JDpend, CheckStyle, XRadar, etc.
>>
>> Also I love to see if I can run our tests in parallel to speed up things
>> at all :)
>>
>> [1] https://github.com/clarkware/jdepend
>> [2] https://github.com/checkstyle/checkstyle
>> [3] http://xradar.sourceforge.net/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Would we need to achieve better place in trends ranking?
Posted by Lukasz Lenart <lu...@apache.org>.
There is a Sonar instance running
https://builds.apache.org/analysis/
2017-11-07 19:16 GMT+01:00 Yasser Zamani <ya...@live.com>:
>
>
> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
>> less static util classes and coupled code
>
> I started playing with JDepend [1] to see if I can have a graphical
> anatomy of Struts :) and see if any wrong connection has been
> established during development.
>
> However, it is not updated for several years but I try it; if you @dev
> know a better tool please let me know.
>
> Then, I also will try if I can add CheckStyle [2] tool to unit tests
> which I spotted during my research. Generally, I love to work on if I
> can do something nice to also test and verify design, code, security and
> etc qualities beside our unit tests during our continuous developments.
> e.g. using tools like JDpend, CheckStyle, XRadar, etc.
>
> Also I love to see if I can run our tests in parallel to speed up things
> at all :)
>
> [1] https://github.com/clarkware/jdepend
> [2] https://github.com/checkstyle/checkstyle
> [3] http://xradar.sourceforge.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
AW: Would we need to achieve better place in trends ranking?
Posted by Ch...@bmw.de.
Hi,
other tools in this regard would be pmd and spotbugs (successor of findbugs)
https://pmd.github.io/
http://findbugs.sourceforge.net/
In my experience it is easy to integrate them in builds and generate nice reports but it is quite hard and a lot of work to fix all those findings. Another issue with those tools is to find/define a suitable ruleset.
Then there is SonarQube a webapplication to analyse code quality (it uses some of the other tools internally but adds it's own findings). To use that it would be necessary to ask ASF infra to run and maintain an instance.
https://www.sonarqube.org/
regards,
Christoph
>
> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
> > less static util classes and coupled code
>
> I started playing with JDepend [1] to see if I can have a graphical
> anatomy of Struts :) and see if any wrong connection has been
> established during development.
>
> However, it is not updated for several years but I try it; if you @dev
> know a better tool please let me know.
>
> Then, I also will try if I can add CheckStyle [2] tool to unit tests
> which I spotted during my research. Generally, I love to work on if I
> can do something nice to also test and verify design, code, security and
> etc qualities beside our unit tests during our continuous developments.
> e.g. using tools like JDpend, CheckStyle, XRadar, etc.
>
> Also I love to see if I can run our tests in parallel to speed up things
> at all :)
>
> [1] https://github.com/clarkware/jdepend
> [2] https://github.com/checkstyle/checkstyle
> [3] http://xradar.sourceforge.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org