C1: Location of issues regarding architecture.json

[hohwille]

Feedback from #5:

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

Selection_232
Selection_232.jpg726x332 80.7 KB

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.

[hohwille]

I agree with your observation and critics. The thing is that we did not want to raise a configuration error on every analyzed (Java) file. Therefore we currently only raise the issue of the first analyzed file on the project. In deed this results in kind of a "random" location.
It is indeed a good suggestion to instead raise the issue on the architecture.json file itself. We already thought about this but the file can be located anywhere on the way from a Java file to the root of the filesystem. Therefore it is possible that this file is above the project folder itself or at least out of the source directories that are added to SonarQube. This is absolutely intended to avoid redundancies for maintenance of larger projects with complex multi-module-structures (to have the architecture.json in the root of the git repo). So what to do in such case? Is there a way to add a file to the analysis within a SonarQube rule?
At least it might be possible to add the issue to architecture.json as long as it is part of the SonarQube scan. The tricky part would then however be to figure out during the analysis of a file if this is the case or not. I assume there is no way a plugin can influence the order of the analysis and if the architecture.json would maybe come last we have to wait till that point and if it does not come at all we would have missed to point where to raise the issue as fallback...
Any hints or best practices from other plugins how to solve such scenarios?

[ganncamp]

From looking at the SonarJava checks on pom files it looks like you simply raise an issue on the "extra" file and it gets imported as part of the analysis. The only time this wouldn't work is if your json file is located outside the analysis directory.

[hohwille]

@ganncamp thanks for the hints. We will try this. Indeed it may be possible that the file is outside the analysis directory but this is not most common. Therefore it should work in most cases and in that case we can still find some kind of fallback scenario.
However, I moved this issue to the next release as we are on our way to push out a new release and that should not be blocked by this issue.