[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940803#comment-16940803 ] Claude Warren commented on JENA-1704: - My reading of https://docs.sonarqube.org/latest/architecture/architecture-integration/ is that we would have to run SonarScanner as part of the build process for the sonar service ( SonarQube Server and SonarQube Database) to report it. We could do this as part of the site processing and just add site processing to the nightly build. I think this would give us the speed we like for development, a nightly or on-demand report of the state of the code base as well as SonarQube reports. I could be wrong about all of the above. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: Adam Soroka >Assignee: Adam Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940795#comment-16940795 ] Andy Seaborne commented on JENA-1704: - Claude - INFRA run a sonar service. This means it is always available and updated. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: Adam Soroka >Assignee: Adam Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940776#comment-16940776 ] Claude Warren commented on JENA-1704: - If Sonar were added to the site build then it (along with the other reports) could be generated on demand. I have a pre latest release branch (I will update to latest head soon) that builds most of the standard reports across the entire set of packages. (https://github.com/Claudenw/jena/tree/mavenise-site) on my github jena on the mavenise-site branch. Claude > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: Adam Soroka >Assignee: Adam Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939942#comment-16939942 ] Andy Seaborne commented on JENA-1704: - See JENA-1765. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: Adam Soroka >Assignee: Adam Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832536#comment-16832536 ] A. Soroka commented on JENA-1704: - Ok, I'll take a look at our hook-points for doing this off of CI. I might take a look at Jenkins before Travis, just because Jenkins is Apache real estate and that's often a good thing. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830142#comment-16830142 ] Andy Seaborne commented on JENA-1704: - I originally thought the reports are generated separately from the build - then it works for anyone using the build whether they have access to send results to Apache or not. This makes sense because there is a magic key for the reports in SonarCloud. But the mentions of POM changes suggests otherwise. Give it a go and we can see what happens. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825232#comment-16825232 ] A. Soroka commented on JENA-1704: - What's being proposed is that a regularly-run process get data to Sonar, so that we can see how the analysis there changes over time. Manually running analysis when someone remembers doesn't accomplish that. I couldn't possibly care less where it happens (although I would be astonished if it noticeably delayed our build compared to the Elephas tests). I'm happy for it to come from CI. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825227#comment-16825227 ] Andy Seaborne commented on JENA-1704: - The details of what is being proposed are unclear to me. What does it take to enable Sonar analysis? Surely [https://builds.apache.org/analysis] does not need any POM changes (no plugin, that's for a local report?) because a key is involved. I assumed that it was an externally run report on a regular cycle, not triggered every build. Is that not the case? How do other people build jena on their systems? If it is in-maven-build, then it slows the build down. So I'm against a sonar report for -Pdev which i use all the time locally, and prefer that it was not part of the regular builds but a separate Jenkins job. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[
https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825205#comment-16825205
]
Aaron Coburn commented on JENA-1704:
What I've done with some of my own projects is to add the sonar analysis to an
\{after_success} section in the travis configuration. That way, it can't ever
fail a build; sometimes sonarcloud might be down, etc. I have also found that
it is best to run the \{sonar:sonar} analysis only for one particular
environment – for example, run the analysis on openjdk8 but not on oraclejdk8
(it doesn't matter so much which one, just pick one environment).
> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
> Issue Type: Improvement
> Components: Build
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis
> must not annoy anyone working on the codebase or make development less
> pleasant, so it must be done carefully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825193#comment-16825193 ] A. Soroka commented on JENA-1704: - I'm not sure we're talking about the same thing, here, [~andy.seaborne]. I'm talking about adding a build step to send the data to Sonar (at Apache) and that's it. I'm not talking about failing builds or giving anyone any feedback at all. If anyone is interested in Sonar's opinions, they would have to actually go to [https://builds.apache.org/analysis] themselves and look for it. Does that seem less problematic? The interest of [~acoburn]'s advice is that if a module has problems running Sonar we don't have to fix them to use it for other modules. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[
https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822726#comment-16822726
]
Andy Seaborne commented on JENA-1704:
-
Not sure {{}} helps that much because different people may want to
focus on different modules.
Does the ASF service require modifying the POMs? I hope not. sonarcloud does
not require it - you can run {{maven sonar:sonar -D...}} to send a report, no
POM change necessary.
The code smells are rather unhelpful if the code was already written.
sonar should be "opt-in" for developers and contributors.
> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
> Issue Type: Improvement
> Components: Build
>Reporter: A. Soroka
>Assignee: A. Soroka
> Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis
> must not annoy anyone working on the codebase or make development less
> pleasant, so it must be done carefully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[
https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821153#comment-16821153
]
A. Soroka commented on JENA-1704:
-
On
[dev@jena|https://lists.apache.org/thread.html/3d41d82bbe5307346059e0cb03723e3e6da3d1681b412341ac881a2a@%3Cdev.jena.apache.org%3E]
[~acoburn] remarked:
{quote}{color:#00}It is possible to exclude specific modules from Sonar's
analysis (I do this{color}
{color:#00}with some of my own projects). The documentation for this is
here:{color}
[https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven#AnalyzingwithSonarQubeScannerforMaven-ExcludingamodulefromSonarQubeanalysis]
{color:#00}Basically, you define this property in the module you want to
skip:{color}
{color:#00}true{color}
{color:#00}Aaron{color}
{quote}
> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
> Issue Type: Improvement
> Components: Build
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis
> must not annoy anyone working on the codebase or make development less
> pleasant, so it must be done carefully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1704) Enable Apache Sonar reports
A. Soroka created JENA-1704: --- Summary: Enable Apache Sonar reports Key: JENA-1704 URL: https://issues.apache.org/jira/browse/JENA-1704 Project: Apache Jena Issue Type: Improvement Components: Build Reporter: A. Soroka Assignee: A. Soroka Apache offers a Sonar service at [https://builds.apache.org/analysis.] We should take advantage of it in a non-intrusive way. Enabling Sonar analysis must not annoy anyone working on the codebase or make development less pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Sonar?
It is possible to exclude specific modules from Sonar's analysis (I do this with some of my own projects). The documentation for this is here: https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven#AnalyzingwithSonarQubeScannerforMaven-ExcludingamodulefromSonarQubeanalysis Basically, you define this property in the module you want to skip: true Aaron On Tue, Apr 16, 2019 at 8:49 AM Rob Vesse wrote: > Yep > > A lot of the bigger projects (often those with commercial backers) that > have a much higher rate of change are often very nit-picky about things > like code style e.g. Apache Spark. I've on occasion spent weeks going back > and forth on style nits in the past with PRs for Spark! > > I can see where those projects are coming from, if you have a high rate of > PRs and changes a consistent code style reduces the unnecessary noise in > code reviews but it tends to be very unwelcoming to new contributors. > > So yes I'd never want us to implement that for Jena > > Rob > > On 16/04/2019, 13:10, "ajs6f" wrote: > > Whoa, wait what?! Are there Apache projects that do that? (Require > some certain score on this kind of analysis for a contribution?) I > sincerely hope not, and I'd be the first -1 here at Jena against any such > suggestion. That would be literally thoughtless. > > > > >
Re: Sonar?
Yep A lot of the bigger projects (often those with commercial backers) that have a much higher rate of change are often very nit-picky about things like code style e.g. Apache Spark. I've on occasion spent weeks going back and forth on style nits in the past with PRs for Spark! I can see where those projects are coming from, if you have a high rate of PRs and changes a consistent code style reduces the unnecessary noise in code reviews but it tends to be very unwelcoming to new contributors. So yes I'd never want us to implement that for Jena Rob On 16/04/2019, 13:10, "ajs6f" wrote: Whoa, wait what?! Are there Apache projects that do that? (Require some certain score on this kind of analysis for a contribution?) I sincerely hope not, and I'd be the first -1 here at Jena against any such suggestion. That would be literally thoughtless.
Re: Sonar?
> On Apr 16, 2019, at 7:18 AM, Andy Seaborne wrote: > > https://sonarcloud.io/dashboard?id=jena-db-tdb2 > > which is new code for TDB2 rewritten for jena-dboe-storage. > > Some useful points, significant amount of noise to manage. > So IMO it is informative, and best used when there is active development in > the area. Diffs in numbers can be useful, the overall assessment of old > code, rather less so and risks being a burden on that old code (where tests > are important and IMO where any time is better spent). That's enough for me to want to turn it on. I agree that it is sometimes useful, sometimes just noise, but for me, having it turned on and being able to just go look at a webpage when that seems interesting is a lot easier (and more likely to be useful) than having to remember how to run it and then running it and then going to look for the report. As for the less useful reports from old code, we can simply ignore that or (depending on how much time I have) I can try to customize the settings across the codebase to minimize the junk from older styles. It should be easy enough to just turn off any notifications so that we don't get a barrage of junk every time someone makes a commit near older code. We can turn them on if or when that seems useful. Cool? > Would we insist on it for contributions? Hoep not - I'd rather see > contributions and tests. And if we don't insist, then who cleans up? Whoa, wait what?! Are there Apache projects that do that? (Require some certain score on this kind of analysis for a contribution?) I sincerely hope not, and I'd be the first -1 here at Jena against any such suggestion. That would be literally thoughtless. It sounds like there are no -1s (maybe a bit of skepticism from Andy as to how generally useful it could be :) ), so I'll see what it would take to turn it on (guessing a ticket to INFRA) and report back. ajs6f >Andy > > On 16/04/2019 11:37, Andy Seaborne wrote: >> TBH I don't think applying it overall is much help. >> There is tradeoff on old code between cleaning it and leaving it, warts and >> all, untouched so git history is not obscured (and "smells" I glanced at >> looked like "current style"). >> I actually find the Eclipse "Show revision information" quite useful. >> It can be run as Bruno has pointed to. >> --- >> Can it be focused on one part of the code base? Pointing to an active area >> where change is already happening might be more useful. >> Andy >> On 15/04/2019 22:44, Bruno P. Kinoshita wrote: >>> I feel like we had this discussion before... but could be in a different >>> project. I ran SonarQube a few times against Jena's codebase in the past, >>> but haven't done it in a while. >>> They also offer a cloud service similar to Travis, called SonarCloud.io: >>> https://sonarcloud.io/dashboard?id=org.apache.jena%3Ajena >>> +1 from me >>> Bruno >>> >>> On Tuesday, 16 April 2019, 1:54:30 am NZST, ajs6f >>> wrote: >>> I see that Apache has Sonar code analysis services at: >>> https://builds.apache.org/analysis and I wasn't able to find Jena there. It >>> would be interesting to see what Sonar says about the codebase. Of course >>> it has to be taken with a grain of salt, but it's often useful. >>> >>> Before I investigate turning Sonar on for our codebase, any >>> thoughts/objections/information? Am I missing anything (like we already >>> have it turned on and I just didn't see it, which happens all the time)? >>> >>> ajs6f >>>
Re: Sonar?
https://sonarcloud.io/dashboard?id=jena-db-tdb2 which is new code for TDB2 rewritten for jena-dboe-storage. Some useful points, significant amount of noise to manage. So IMO it is informative, and best used when there is active development in the area. Diffs in numbers can be useful, the overall assessment of old code, rather less so and risks being a burden on that old code (where tests are important and IMO where any time is better spent). Would we insist on it for contributions? Hoep not - I'd rather see contributions and tests. And if we don't insist, then who cleans up? Andy On 16/04/2019 11:37, Andy Seaborne wrote: TBH I don't think applying it overall is much help. There is tradeoff on old code between cleaning it and leaving it, warts and all, untouched so git history is not obscured (and "smells" I glanced at looked like "current style"). I actually find the Eclipse "Show revision information" quite useful. It can be run as Bruno has pointed to. --- Can it be focused on one part of the code base? Pointing to an active area where change is already happening might be more useful. Andy On 15/04/2019 22:44, Bruno P. Kinoshita wrote: I feel like we had this discussion before... but could be in a different project. I ran SonarQube a few times against Jena's codebase in the past, but haven't done it in a while. They also offer a cloud service similar to Travis, called SonarCloud.io: https://sonarcloud.io/dashboard?id=org.apache.jena%3Ajena +1 from me Bruno On Tuesday, 16 April 2019, 1:54:30 am NZST, ajs6f wrote: I see that Apache has Sonar code analysis services at: https://builds.apache.org/analysis and I wasn't able to find Jena there. It would be interesting to see what Sonar says about the codebase. Of course it has to be taken with a grain of salt, but it's often useful. Before I investigate turning Sonar on for our codebase, any thoughts/objections/information? Am I missing anything (like we already have it turned on and I just didn't see it, which happens all the time)? ajs6f
Re: Sonar?
TBH I don't think applying it overall is much help. There is tradeoff on old code between cleaning it and leaving it, warts and all, untouched so git history is not obscured (and "smells" I glanced at looked like "current style"). I actually find the Eclipse "Show revision information" quite useful. It can be run as Bruno has pointed to. --- Can it be focused on one part of the code base? Pointing to an active area where change is already happening might be more useful. Andy On 15/04/2019 22:44, Bruno P. Kinoshita wrote: I feel like we had this discussion before... but could be in a different project. I ran SonarQube a few times against Jena's codebase in the past, but haven't done it in a while. They also offer a cloud service similar to Travis, called SonarCloud.io: https://sonarcloud.io/dashboard?id=org.apache.jena%3Ajena +1 from me Bruno On Tuesday, 16 April 2019, 1:54:30 am NZST, ajs6f wrote: I see that Apache has Sonar code analysis services at: https://builds.apache.org/analysis and I wasn't able to find Jena there. It would be interesting to see what Sonar says about the codebase. Of course it has to be taken with a grain of salt, but it's often useful. Before I investigate turning Sonar on for our codebase, any thoughts/objections/information? Am I missing anything (like we already have it turned on and I just didn't see it, which happens all the time)? ajs6f
Re: Sonar?
I feel like we had this discussion before... but could be in a different project. I ran SonarQube a few times against Jena's codebase in the past, but haven't done it in a while. They also offer a cloud service similar to Travis, called SonarCloud.io: https://sonarcloud.io/dashboard?id=org.apache.jena%3Ajena +1 from me Bruno On Tuesday, 16 April 2019, 1:54:30 am NZST, ajs6f wrote: I see that Apache has Sonar code analysis services at: https://builds.apache.org/analysis and I wasn't able to find Jena there. It would be interesting to see what Sonar says about the codebase. Of course it has to be taken with a grain of salt, but it's often useful. Before I investigate turning Sonar on for our codebase, any thoughts/objections/information? Am I missing anything (like we already have it turned on and I just didn't see it, which happens all the time)? ajs6f
Sonar?
I see that Apache has Sonar code analysis services at: https://builds.apache.org/analysis and I wasn't able to find Jena there. It would be interesting to see what Sonar says about the codebase. Of course it has to be taken with a grain of salt, but it's often useful. Before I investigate turning Sonar on for our codebase, any thoughts/objections/information? Am I missing anything (like we already have it turned on and I just didn't see it, which happens all the time)? ajs6f
