sonarlint cli documentation returns 404

[ludaya...@mitrai.com]

Hi,

I was checking the documentation for sonarlint commandline[1]. But it seems like page has been removed. Is this has been moved or where I can find the documentation for this?

[1] https://www.sonarlint.org/commandline/

Thanks,

Lakshman.

[G. Ann Campbell]

Hi Lakshman,

That documentation has been removed; we're no longer supporting the feature.

Ann

[Lakshman Udayakantha]

Hi Ann,

Reporting feature that come from sonarlint CLI is an awesome feature. We have used it recently and very impressed. Anyway is there any reason to remove this feature? Is there any other way to get an issue report since this features has been removed.

Thanks,

Lakshman.

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/WlALjVzp-OE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/d1ac75ee-29af-45c1-a8f8-1ac517d4be99%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Lakshman Udayakantha.

Senior Software Engineer | +94 717429601 | Mitra Innovation

    

The content of this email is confidential and/or copyright and is solely for the intended recipient. If you have received this email in error: (i) you must not copy or distribute any part of it or otherwise disclose its contents to anyone; (ii) please let Mitra Innovation know by reply email to the sender and delete all copies from your system. No representation is made that this email is free of viruses or other defects. Virus scanning is recommended and is the responsibility of the recipient.

[G. Ann Campbell]

Hi Lakshman,

To be perfectly honest, the docs got lost in the shuffle of the SonarLint site redesign. Our intent was to drop them with the release of the 6.7 LTS (which will happen very quickly). Along with the release of the LTS, we'll also be releasing robust branch support (as a commercial feature). 

Already SonarLint no longer fit into our model: in-IDE SonarLint + full analysis, but the addition of robust branch support was (will be) the final nail in the coffin.

Ann

[Lakshman Udayakantha]

Thanks for the information Ann.

Thanks,

Lakshman.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/9f43ae94-3005-4790-b2e7-81d72e4bbff1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Lakshman Udayakantha.

Senior Software Engineer | +94 717429601 | Mitra Innovation

    

[damon...@gmail.com]

Would it be possible to have the decision to deprecate the 'preview' reporting mode on the Sonar Scanner reversed?  I believe that it has been reporting itself as deprecated for around 2 years and the message says 'use SonarLint command line instead'. 

As I explain on a stack exchange question here I consider the lack of a viable command line implementation of preview functionality to be a barrier to adoption of basic build best practice; a developer should be able to run a build that will indicate any issues that could be found in a CI build before making a commit.  I do not consider the existence of the SonarLint IDE plugins to meet this requirement, the IDE is not a local build.

My primary motivator for wanting the ability to run sonar analysis from the command line (or more accurately as part of a Maven build from the command line) is that this would allow me to stop running multiple other static analysis plugins and eliminate the (almost impossible) task of attempting to keep the rules used by these tools in sync with those used by the Sonar server.  The use of standard open source tools like PMD, findbugs, etc. would, perhaps, be ideal, but SonarSource has chosen to deprecate many of the rules that do align with these tools in favour of the Squid rules engine, which makes rules matching much more difficult. 

Using the preview mode, or SonarLint command line, makes matching rules used during a local or CI build with those seen when looking at the server side analysis trivial, so I do believe that SonarSource is making a mistake in apparently dropping all support for the concept of a command line analysis of the source code that does not write data to the Sonar server.

Damon

[G. Ann Campbell]

Hi Damon,

On Fri, Nov 3, 2017 at 12:53 PM, <damon...@gmail.com> wrote:

Would it be possible to have the decision to deprecate the 'preview' reporting mode on the Sonar Scanner reversed?  I believe that it has been reporting itself as deprecated for around 2 years and the message says 'use SonarLint command line instead'. 

Anything's possible, but it's not very likely.

 

As I explain on a stack exchange question here I consider the lack of a viable command line implementation of preview functionality to be a barrier to adoption of basic build best practice; a developer should be able to run a build that will indicate any issues that could be found in a CI build before making a commit.  I do not consider the existence of the SonarLint IDE plugins to meet this requirement, the IDE is not a local build.

I think there's a fundamental misalignment of philosophy here. We do believe that in-IDE checking is enough. Or should be enough - meaning that if it's not we'd really like to hear how/where it's failing you. I.E. what specific issues are missed in SonarLint that are found in full (or even preview) analysis?

 

My primary motivator for wanting the ability to run sonar analysis from the command line (or more accurately as part of a Maven build from the command line) is that this would allow me to stop running multiple other static analysis plugins and eliminate the (almost impossible) task of attempting to keep the rules used by these tools in sync with those used by the Sonar server.  The use of standard open source tools like PMD, findbugs, etc. would, perhaps, be ideal, but SonarSource has chosen to deprecate many of the rules that do align with these tools in favour of the Squid rules engine, which makes rules matching much more difficult. 

I don't fully understand this paragraph. We believe we've replaced most of the valuable rules from the tools you cite. It seems to me that you should be able to include the replacement rules into your profile and have them run in both SonarLint and SonarQube. These reports might help with that: Checkstyle, PMD, FindBugs. 

If there are rules from those 3rd party tools you don't feel are adequately replaced, we'd love to hear about it.

 

Using the preview mode, or SonarLint command line, makes matching rules used during a local or CI build with those seen when looking at the server side analysis trivial, so I do believe that SonarSource is making a mistake in apparently dropping all support for the concept of a command line analysis of the source code that does not write data to the Sonar server.

With SonarLint, you have the ability to run all our rules pre-commit. And with PR analysis and the coming-soon Branch analysis, comes the ability to run them all pre-merge. So I suspect what you're actually upset about is a lack of support for 3rd-party analyzers in SonarLint.

To that, I can only say: nope, we don't support them and no, we don't plan to. But again, if you'd like to tell us what rules you feel are vital that we haven't provided adequate replacements for, we'd be happy to hear it.

Ann

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

 

[Scott B.]

Just to add my $0,02:

Ann, you should know that in-IDE checking doesn't work for some languages. Take PL/SQL as and example: many companies use Oracle SQL Developer or PL/SQL Developer (from Allround Automations). They can be extended with plugins, but there is no definition of "project" in PL/SQL (as in Maven, Ant, MSBuild...). Many times it's just a bunch of scripts that can be organized and executed together. Even if someone develop a SonarLint plugin for these IDEs, I can't see how one would implement the SonarLint connected mode. And don't tell me "you can use SonarPLSQL in SonarLint for Eclipse", because Eclipse is not a good IDE to write PL/SQL code.

Sometimes the IDE is not extensible at all, see Oracle Forms Builder. To to a pre-commit check, the only option is to use the preview mode of sonar-scanner.

[G. Ann Campbell]

Hi Scott,

I think all of those points could be answered by Branch Analysis, which will be released($) later this week. I don't want to upstage the soon-to-come announcements and documentation. But take a look when it's out & see what you think.

Ann

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

--

You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/WlALjVzp-OE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/a2ca8c76-dc4d-4bd9-80ff-ed5b4460d122%40googlegroups.com.

[Damon Jebb]

On 3 November 2017 at 19:02, G. Ann Campbell <ann.ca...@sonarsource.com> wrote:

Hi Damon,

On Fri, Nov 3, 2017 at 12:53 PM, <damon...@gmail.com> wrote:

Would it be possible to have the decision to deprecate the 'preview' reporting mode on the Sonar Scanner reversed?  I believe that it has been reporting itself as deprecated for around 2 years and the message says 'use SonarLint command line instead'. 

Anything's possible, but it's not very likely.

 

As I explain on a stack exchange question here I consider the lack of a viable command line implementation of preview functionality to be a barrier to adoption of basic build best practice; a developer should be able to run a build that will indicate any issues that could be found in a CI build before making a commit.  I do not consider the existence of the SonarLint IDE plugins to meet this requirement, the IDE is not a local build.

I think there's a fundamental misalignment of philosophy here. We do believe that in-IDE checking is enough. Or should be enough - meaning that if it's not we'd really like to hear how/where it's failing you. I.E. what specific issues are missed in SonarLint that are found in full (or even preview) analysis?

Indeed there does appear to be a misalignment; my view is that it is best practice for a developer to run a build that will identify any reason that a CI build will fail before they commit to source control.  For static code analysis this requirement has typically been supported by the findbug, PMD, checkstyle type build plugins.  I believe though that, if we are using the Sonar server to define the quality of our code then it would be much better to use it, and its rules during the local build rather than trying to maintain both the sonar rules and others from those build plugins.  It appears that in the past SonarSource also took this view because preview mode existed and sonarlint command line version was initially created and supported.

The decision to drop support for command line activities puts SonarSource into a group of tools that I do not believe support development best practice and I will have to look at whether there are alternatives to Sonar.  In the short term it may be possible to use findbugs, PMD, etc. to run local and CI build analysis, but the overhead and duplication involved in maintaining both methods and keeping them in sync makes it an unacceptable long term solution.

 

 

My primary motivator for wanting the ability to run sonar analysis from the command line (or more accurately as part of a Maven build from the command line) is that this would allow me to stop running multiple other static analysis plugins and eliminate the (almost impossible) task of attempting to keep the rules used by these tools in sync with those used by the Sonar server.  The use of standard open source tools like PMD, findbugs, etc. would, perhaps, be ideal, but SonarSource has chosen to deprecate many of the rules that do align with these tools in favour of the Squid rules engine, which makes rules matching much more difficult. 

I don't fully understand this paragraph. We believe we've replaced most of the valuable rules from the tools you cite. It seems to me that you should be able to include the replacement rules into your profile and have them run in both SonarLint and SonarQube. These reports might help with that: Checkstyle, PMD, FindBugs. 

If there are rules from those 3rd party tools you don't feel are adequately replaced, we'd love to hear about it.

As discussed above, this is less about the missing rules, etc. than the duplication, and effort required to maintain the duplication.  This would never be acceptable in a code base, why would it be acceptable in build configurations?  Although it was a while ago, I have spent a considerable amount of time trying to align the OS tool rules against the Sonar rules and found it difficult to properly match some.  I don't have the detail any more because when I found sonarlint command line I believed that I had found a much better solution; it's a shame that SonarSource policy no longer supports that approach.

 

Using the preview mode, or SonarLint command line, makes matching rules used during a local or CI build with those seen when looking at the server side analysis trivial, so I do believe that SonarSource is making a mistake in apparently dropping all support for the concept of a command line analysis of the source code that does not write data to the Sonar server.

With SonarLint, you have the ability to run all our rules pre-commit. And with PR analysis and the coming-soon Branch analysis, comes the ability to run them all pre-merge. So I suspect what you're actually upset about is a lack of support for 3rd-party analyzers in SonarLint.

Not at all, I have a fundamental belief that IDE is not acceptable as the only method of achieving a build or development task.  It's also important to realise that the Sonar build that uploads data to the server is not usable by a developer because a developer cannot run it locally; we do not want developers to upload the data to the server every build that they run and we do not want to provide server instances for developers.  What I want is a build that replicates the information that we see on the sonar server locally without uploading data to the server.

I'm somewhat puzzled by the change of approach that dropping sonarlint signals from SonarSource.  Is it considered to be too costly to support what is just a wrapper around the core functionality?

[duncan....@gmail.com]

Hello Damon,

I was using klocwork quite happily but have been forced to move to sonarqube.

I had jenkins perform server klocwork analyses.

I also had a local developer pre-commit process which used the command-line to analyse single classes or whole builds all inside our IDE - IBM Rational Rhapsody.

We build our code with Rhapsody which uses nmake and a makefile.  We don't use Visual Studio.

Now, with sonarqube it seems impossible to achieve the same level of pre-commit static analysis that we previously achieved with klocwork.

I agree that sonarqube should really offer the preview mode (?) or reinstate a command-line flavour.

It definitely seems like a backward step for my Agile Scrum Team.

[rio.sh...@gmail.com]

I agree with you.

Command Line Tools is useful in local-check pre commit. And Atom and Vscode's sonarlint extension not support connected mode, so CLI is important.

在 2018年1月11日星期四 UTC+8上午12:34:12，duncan....@gmail.com写道：