interesting thought, but I think it’s still too rudimentary for a marketplace inclusion. I will come back to you when I think it’s ready. So far we’re only listed on the “Other Plugins” page.
When you’re ready to go in that direction, you should be aware of Requirement 3e (relatively recently added) and of Requirement 7.
I haven’t tested it, so I have no opinion on whether or not it’s rudimentary, but off-hand I’d say you only need to offer basic metrics and a few rules.
thanks for the hints. 3e is kind of tricky, when the plugin is about providing the sonar integration for that language, but it basically says we should prefix “community” kind of… Regarding 7 - I forgot to collect coverage for the new code, actually the quality gate should be met.
you cannot find sonar-perl in the marketplace yet. Either download the latest release from github (1), or run sonar-perl from one of the pre-built docker images (2).
regarding rule 3e: could the plugin use “sonarperl” instead of “perl” as key? And if we change the key now, doesn’t this break all existing installations of our plugin?
Regardless of what happens with your rule key, I don’t believe your users will have a seamless Marketplace experience. Since the system will have no record of the version they’re coming from I don’t think it will recommend an upgrade to any new version released in the Marketplace. Marketplace aside, what a key change does risk is that a user could inadvertently install two different versions (one with each key) of your plugin. Normally a key clash fails startup, but lacking a key clash, the user would see failure at analysis time.
Now, coming back to your question about what you key should be, to be honest, this is the first time I’ve been asked, “If it can’t be just the name of the language, then what should it be?”. I’d rather you didn’t use sonarperl although there’s nothing in the rules (yet! ) that says you can’t. I’d like to counter-propose trosien-perl. WDYT?
is the requirement 3e only regarding the plugin key (i.e. artifactId in pom.xml) or does this also concern the language key (1st Argument of AbstractLanguage constructor)?
That language key would really break existing installations!
maybe there’s a way to migrate to a new plugin key without breaking all existing installations? (not sure but this seems to be worth making a dedicated forum thread)
Could you define “break” please? Because unless we’re talking about failure to start the server, I’m not sure I’d use that word.
As I described earlier, it should be a manual process either way for the user to upgrade from a version that was never in the Marketplace to one that is. After that, if you keep your rule id’s and repository keys the same, it should be transparent on the issues side for the users. Worse case though, all the old issues are closed and new copies created and backdated - so maybe you loose your FPs and a few comments but it doesn’t screw up your New Code Period.
@milbrandt regarding the language key, I’m not qualified to comment extensively, but I suspect that this is the difference between SonarJava’s java plugin key and its squid rule repository key. You could check SonarJava to be sure. And by the way, you can choose to separate your Maven artifact id from your plugin key; there’s a property for that.
) that says you can’t. I’d like to counter-propose 