After upgrading to 5.5 version and now the latest (5.6) SonarQube always shows the issues I create through my plugin as "Code Smell". I would like to know more about the categorization and how can I add them as other types ("Vulnerability" and "Bug"). The code where I create the issues is as follows:
Issuable issuable = this.resourcePerspectives.as(Issuable.class, inputFile);
if (issuable != null) {
Issue issue = issuable.newIssueBuilder()
.ruleKey(activeRule.ruleKey())
.line(vulnerability.getLine())
.message(someMessage)
.severity(severity)
.build();
issuable.addIssue(issue))
} //...
Current support for bugs and vulnerabilities is a "creative implementation" (read "hack") based on tags. So, add the "bug" tag to your rule and its issues will be raised as bugs. Add the "security" tag to a rule and its issues will be raised as vulnerabilities.
Rules with both "bug" and "security" tags will be treated as bug rules.
For future reference, this mechanism is expected to change in the "near" future, but there's currently no schedule for it.
Edit
The current (6.1) version of the API provides the ability to simply declare rule type.
Related
How to generate validator file only for message that contains validates rules ?
In the example below, actually sbt compilation generates 4 scala classes: one for protobufA, one for protobufB and one validator message for both.
int32 id = 1;
string action = 2 [(validate.rules).string = {in: ["tonic", "gin", "martini"]}];
}
message protobufB {
option (scalapb.message).annotations = "#JsonNaming(classOf[SnakeCaseStrategy])";
int32 id = 1;
string name = 2 ;
}
I would like to generate only three classes : one for protobufA, one for protobufB and the last for protobufA validator classes.
I have version 0.1.3 of scalapb-validate-codegen.
There is currently (as of version 0.2.1 of scalapb-validate) no way to suppress the generation of validation classes once you add the validation plugin. The only way, right now to do that would be to separate the messages you don't want to have validators for to separate SBT subprojects which doesn't have the validator plugin turned on.
Feel free to start a github issue on scalapb-validate github to discuss this as a feature request, and include also the motivation for a change like this. This would require some thought since messages that have validators require all the message that they transitively reference to have validators as well, so the plugin would have to detect this situation when disabling generation.
I have an extension which adds text decorations at the end of some of the lines. I'd like to write a test which verifies that the text decorations are added and also to assert in the test that their value is correct.
suite('Extension Tests', () => {
test('Should work', async() => {
const fixturePath = path.join(__dirname, '..', '..', 'test', 'fixtures');
const uri = vscode.Uri.file(path.join(fixturePath, 'a.js'));
const document = await vscode.workspace.openTextDocument(uri);
await vscode.window.showTextDocument(document);
window.activeTextEditor.getDecorations(); //???
});
});
It seems that the getDecorations API is missing from editor. What can I do to resolve this?
As of VSCode 1.37.1 (2019-08-30), the answer is no, there is no way to write an automated test for decorations using the decorations extensions API.
There are automated tests of decorations in the vscode sources, particularly modelDecorations.test.ts, but they use private APIs.
Microsoft has an example extension that uses decorators, decorator-sample, but it has no tests.
There are a few open issues related to this, although none directly addresses the inability to enumerate existing decorations:
50346: Lacking decorations-related APIs (mainly about incremental update for better performance); closed as duplicate of:
585: Provide an API for advanced/semantic source highlighting
50415: Missing API for knowing when an extension's decorations get trashed
54938: Make decoration provider API public
Therefore I recommend filing a new issue.
2022-04-27: As noted in a comment, issue 136164: Provide Access to a TextEditors Decorations for Testing Purposes was filed on 2021-10-30. It was then closed as unnecessary because you can test that your extension calls the extension API as intended. I find this response inadequate because there's no way to test that the effect is as intended (for example, TextEditor.setDecorations removes existing decorations that have the same type, and that's a subtle interaction that would only be revealed by examining the effects), but the issue is locked so yet another issue would have to be filed to raise an objection.
Using grails mail plugin 1.0.7.
https://jira.grails.org/browse/GPMAIL-36 states that it's possible to change plguin configuration since 1.0.1 at runtime. Sadly it does not explains how to achieve it.
I want to be able to change the username at runtime to be able to use different mail accounts.
Thanks.
Based on this code, you should be able to change the configuration at runtime and the mail plugin will automagically re-deploy and update mail sender based on your changes.
Example:
Holders.config.grails.mail.username = 'foo'
Holders.config.grails.mail.password = 'bar'
sendMail {
to "foo#bar.com"
from "bar#foo.com"
subject "Hi"
body "This is an email"
}
Update:
It would appear that changing the configuration in this manner does not, in fact, fire the onConfigChange event. Per this, you can fire the event manually. Something like this:
Holders.pluginManager.getGrailsPlugin('mail').notifyOfEvent(GrailsPlugin.EVENT_ON_CONFIG_CHANGE, Holders.config)
I've realized this can be done accessing the mailSender bean from the context and updating it like is explained here
Changing mail configuration in runtime
However if #rmlan solution finally works it may be a much cleaner solution.
Actually thr rmlan solution works with the following fix. Since the onConfigChange compares hashCode of existing config map and new one, so if you set new configs in original configuration (Holders.config.grails.mail), then both configs are same and it never pass the condition to apply new changes, so a new structure should be created and pass it to notifyOfEvent method to mark the change as different hashCodes.
def mailConfig = [ grails: [ mail: [:] ] ]
mailConfig.grails.mail.host = newHost
mailConfig.grails.mail.port = newPort
Holders.pluginManager.getGrailsPlugin('mail').
notifyOfEvent(GrailsPlugin.EVENT_ON_CONFIG_CHANGE, mailConfig)
Still using async-mail and this one make the below exception
No qualifying bean of type [grails.plugin.mail.MailService] is defined: expected single matching bean but found 2: nonAsynchronousMailService,mailService
that is thrown because of the following part of onConfigChange
event.ctx.getBean(MailService.class).setPoolSize(mailConfig.poolSize?:null)
Commenting it let it works as a workaround, but making sendMail of mail plugin is called, not async-mail, so exception may raise if async-mail features is used on constructing mail. Hence to use async-mail in this workaround should use sendAsynchronousMail method.
import org.sonar.api.component.ResourcePerspectives;
public class MySensor extends Sensor {
private final ResourcePerspectives perspectives;
public MySensor(ResourcePerspectives p) {
this.perspectives = p;
}
public void analyse(Project project, SensorContext context) {
Resource myResource; // to be set
Issuable issuable = perspectives.as(Issuable.class, myResource);
if (issuable != null) {
// can be used
Issue issue = issuable.newIssueBuilder()
//repository : pmd, key : AvoidArrayLoops
.setRuleKey(RuleKey.of("pmd", "AvoidArrayLoops"))
.setLine(10)
.build();
//works
issuable.addIssue(issue);
Issue issue2 = issuable.newIssueBuilder()
//repository : manual, key : performance
.setRuleKey(RuleKey.of("manual", "performance"))
.setLine(10)
.build();
// doesn't work
issuable.addIssue(issue2);
}
}
}
When I try to add the issue "issue" referring to the pmd rule AvoidArrayLoops it works. More generally, when I try to add issues referring to pmd or checkstyle rules it works.
However, when I try to add issues referring to manual rules such as the issue "issue2", it doesn't work. I have created manually the rule "performance" so the rule performance exists in the list of manual rules in sonar.
I would like to know if it is impossible to add issues referring to manual rules or if I am not using the right parameters for the method RuleKey.of.
Thanks
One reason why your custom issue is not shown in Sonar may be that you haven't enabled it the rule.
Select settings - Quality Profiles, click on your quality profile, select the tab "Coding rules", set Activation to "any", click search and check whether your rule is being displayed here.
If so, check the checkbox next to it and select the severity. Now, the rule violations will be displayed in Sonar.
When you register a plug-in in Microsoft CRM all kinds of things can go wrong. Most commonly, the error I get is "An error occurred."
When you look for more detail you just get: "Server was unable to process request" and under detail you see "An unexpected error occurred."
Not very helpful. However, there are some good answers out there if you really dig. Anybody out there encountered this and how do you fix it?
The most common issue is that the meta parameter names must match.
For example:
public static DependencyProperty householdProperty = DependencyProperty.Register("household", typeof(Microsoft.Crm.Sdk.Lookup), typeof(AssignHouseholds));
[CrmInput("AccountId")]
[CrmReferenceTarget("account")]
public Microsoft.Crm.Sdk.Lookup household
{
get
{
return (Microsoft.Crm.Sdk.Lookup)base.GetValue(accountidProperty);
}
set
{
base.SetValue(accountidProperty, value);
}
}
Note the name after DependencyProperty (housedProperty) must exactly match the string after DependencyProperty.Register (in this case ("household") with the word "Property" appended.
Also, that value must match the value of public variabletype (in this case "household"). If any one of them don't match, it will error.
This is by design and is how MSCRM ties the values together.
A common cause is that your CRM SDK references must use the 64 bit version if you are on a 64 bit machine.
These will be located at
C:\sdk\bin\64bit\microsoft.crm.sdk.dll
and
C:\sdk\bin\64bit\microsoft.crm.sdktypeproxy.dll
if you installed the sdk to C:\sdk.
Also your build settings should be set to "Any CPU" under Project properties->Build.
You may also need to move the two dlls to your debug or release folder before you build.