willemsrb
commented
7 years ago Hi Filipe ( @fmorgad0 ),
first my apologies for the very late response to your issue. I haven't had the time i wanted to spend on my projects.
Second, thank you very much for your good observations and to reply to your last suggestion first: i would be very happy if you would be willing to participate in improving the plugin. Please create a pull request with suggested changes.
Now on to the real suggestions....
Remediaton times: we don't actively use those in our project. So if you have a good suggestion for values i would gladely use those. In the definition of the rule i understand a DebtRemediationFunction can be added that can use a 'gap'-multiplier and that 'gap' can be set on the issue when it is registered. Maybe that can be used to make them dynamic enough.
The huge project will probably always be a problem when looking at the time it takes to be analyzed. I could try to make the file analysis multi-threaded but i dont know if the sonarqube code supports that.
When reporting issues you could always use the 'class mode': 'first'. The plugin then should only report the issue on the first class and not on 'all' (which is the default setting).
Regards, Robert
fmorgad0
Hello there. I’ve been testing for a while your plugin now and so far so good, it has lots of important information regarding the cycles themselves. I’d like to discuss a couple of concerns with you, if it’s alright. First, in order for the plugin to translate into the overall analysis and affect technical debt ratio, remediation times need to be associated with each rule. I’ve tried to make the remediation time dynamic and dependable on the number of classes in each interface, but it seems that sonar forces the remediation times to be defined within the rule’s definition(which makes sense, since the rules must be contained inside the plugin repository by the time the server is launched), making them static. Besides that, I’ve been using an old project with +/-100k loc that has a huge amount of package cycles, to the point that the analysis could not be done in real time, which led me to think that there might be similar problems with other projects. Furthermore, even by limiting the amount of issues reported by this rule it showed lots of redundant information (a cycle is reported x times, where x is the number of packages it affects). I’d be happy to contribute with these issues to further improve the plugin if you’re interested, both remediation times and scalabilty. Thanks in advance.