[NEW PLUGIN] publish sonar-devon-plugin to marketplace?

java

(Jörg Hohwiller) #1

Dear SonarQube community,

I am from devonfw. We love open-source, we love to share code, documentation, best-practices, etc. Also we love quality and we recommend SonarQube as a quality tool.
We have implemented our own plugin for SonarQube and have released it to maven central.

Can someone give guidance how it would be possible to make this plugin be published to the SonarQube marketplace (so users can directly install it and further updates via SonarQube web UI)?

Thank you so much.
Jörg


(G Ann Campbell) #2

Hi,

First, thanks for your contribution to the community!

The requirements for entering the Marketplace are laid out here: https://docs.sonarqube.org/display/DEV/Deploying+to+the+Marketplace.

After a quick bureaucratic review, it seems that you tick most of the boxes, but I don’t see any sort of change log for the one release listed on GitHub. Beyond that, the convention is to attach the release’s binaries to the release in GitHub. Your binaries are available in Maven Central, so that’s not required, but it would be nice.

Note that testing, which I haven’t done, is also required for entry into the Marketplace.

 
Ann


(G Ann Campbell) #3

Hi again,

Could you provide or point me to a project for testing?

 
Thx,
Ann


(Jörg Hohwiller) #4

Hi Ann,

awesome. Thanks for your feedback. We will check the requirements and try to improve and resolve issues that would prevent us from entering the marketplace. As this was our first release and we are properly assigning issues to milestones so far our plan was to use the milestones on github as pragmatic release notes / change log. However, it is easy to add a change log and from there we can still link to each of the milestones on github as well. Also this is our first relase. It might be a little confusing that it is not 1.0.0 but 3.0.0 but we are in the process of releasing the entire devonfw where this sonar plugin is just a tiny little piece of the whole thing and that release has a long historic backtrack that now reached 3.0.0.

If you want to test the plugin with a project you can use our sample app.
The Java Backend to test via maven can be found here:

I just added the architecture.json config file to it so the plugin will find a config. Please note that the plugin will also find several issues showing our homework. That is of course the reason of such plugin :wink: However, in the beginning of 2019 we will heavily rework our sample app (MTS) to get all issues resolved.

If there is anything else we need to improve let us know.

Thanks
Jörg


(G Ann Campbell) #5

Hi Joerg,

Thanks for the sample project. It’s quite useful to me that you haven’t cleaned it up yet. :slight_smile:

I have some feedback on your rules/issues, but none of this is mandatory, so once you sort out the change log question, you should be good to go.

Rule C1
The location of this issue seems arbitrary to me if not random:

If I pull up the architecture.json file, I can see where the cycle is created. It’s not clear to me whether the file is purely descriptive, or actually has some impact on the code, but it took me a while to connect the package name to the string “bookingmanagement” from the issue message.

It seems to me that this issue should probably be raised in architecture.json with the primary location on the first part of the cycle and secondary locations on the other parts of the cycle. If you’re about to object that you’re participating in an analysis of Java code and that’s a JSON file, well… you’re clearly already reading the file. You just have to figure out how to raise issues on it. SonarJava raises issues on pom files, so you can probably take a page from its book.

General
There’s currently an arbitrary limit on the message length passed from the back end to the UI. You should reconsider the structure of your messages:
Selection_233
I’d suggest something like

Code from this dataaccess layer cannot depend on the dataaccess layer of a different component (component here)

Also, it would be really helpful if the description for this rule gave a “why” on this. Currently all your rule descriptions basically just say (implicitly) “Because I said so.” and that’s one of the quickest ways I know to start an argument. :smile:

Rule L12
Are you missing a “not” here?

Rule P1
I think maybe some punctuation is missing here(?). Maybe after "or common… (which BTW would be better as “and common”). As-is, the message doesn’t make a lot of sense to me:
Selection_235

And again this is a rule that could really benefit from a (fuller) description. I guess you’re telling me that something’s missing in the file, but I don’t have a lot to work with here in terms of knowing what to do to fix the problem.

Rule C2
This message seems to tell me that general dependencies are allowed, which means… that I can use any dependency? But then why do I have an issue:
Selection_236

 
Ann


(Jörg Hohwiller) #6

Hi Ann,

thank you so much for your valuable feedback.
I have meanwhile added a CHANGELOG:

Further for the whole thread I have created this issue:
https://github.com/devonfw/sonar-devon-plugin/issues/5

Also for your individual feedback on particular rules and issue message, I created separate issues for each aspect:

All are assigned to our next milestone (release 3.1.0) and if all goes right, we will then meet all the criteria to enter the official marketplace.

Cheers
Jörg