Community
Participate
Working Groups
Is it possible to access Sonar data using a project short name (e.g. "tycho") or id (e.g. "technology.tycho")? I'm specifically curious about the webservices API. e.g. https://dev.eclipse.org/sonar/api/resources?metrics=ncloc,coverage&resource=77843 answers data for the EMF Client Platform (ECP) project. A more obvious URL would be: https://dev.eclipse.org/sonar/api/resources?metrics=ncloc,coverage&resource=modeling.ecp If Sonar can't help us, maybe we can play with the Apache configuration.
The other alternative is that we can add a field in the PMI that contains the mapping. Making this automatic would be much easier and far more reslient to change (anything that depends on committers going back to update project data in the PMI is doomed to fail).
There are URL such as https://dev.eclipse.org/sonar/dashboard/index/org.eclipse.tycho:tycho , which uses the groupId:artifactId of the main pom, but I don't think there is a robust way to derive project id from it. So it seems like an entry in the PMI is more possible.
(In reply to Mickael Istria from comment #2) > There are URL such as > https://dev.eclipse.org/sonar/dashboard/index/org.eclipse.tycho:tycho , > which uses the groupId:artifactId of the main pom, but I don't think there > is a robust way to derive project id from it. Can we assume org.eclipse.<short-name>:<short-name> as the groupId:artifactId ? Or, perhaps, can we encourage it? e.g. if you use this sort of naming convention, you get Sonar stats on the dashboard (Bug 428123) and project page. Is Maven the only vector for putting stuff in Sonar?
(In reply to Wayne Beaton from comment #3) > Can we assume org.eclipse.<short-name>:<short-name> as the > groupId:artifactId ? I don't think so. Some put the container project in groupId, some don't... There is no strong convention that makes it immediate > Or, perhaps, can we encourage it? e.g. if you use this sort of naming > convention, you get Sonar stats on the dashboard (Bug 428123) and project > page. Encouraging such conventions wouldn't hurt, but I have the feeling that encouraging as a low impact and doesn't change things a lot, or at least, not in a short-term > Is Maven the only vector for putting stuff in Sonar? No, they have some APIs and dedicated executables to run and push analysis. But Maven is the easiest way as it's all well packaged in Maven plugins and integrated with all CI tools.
(In reply to comment #4) > No, they have some APIs and dedicated executables to run and push analysis. But > Maven is the easiest way as it's all well packaged in Maven plugins and > integrated with all CI tools. I'm going off topic a bit here, but... for projects that don't build with Maven, is it relatively easy to--say--add a Maven task to the Hudson build to push the build to Sonar?
(In reply to Wayne Beaton from comment #5) > I'm going off topic a bit here, but... for projects that don't build with > Maven, is it relatively easy to--say--add a Maven task to the Hudson build > to push the build to Sonar? In that case, it wouldn't be a Maven task, but more the configuration and invocation of sonnar-runner executable: http://docs.codehaus.org/display/SONAR/Analyzing+with+SonarQube+Runner I guess it would be possible for projects using Buckminster to create a dedicated task to wrap this invocation.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
The Eclipse SonarQube instance has been shutdown, see 564871.
