Quantcast

[sonar-dev] Sonar plugin dependencies and the packaged Manifest.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[sonar-dev] Sonar plugin dependencies and the packaged Manifest.

Laurent Zilber
Dear sonar developers,

Out of laziness, I tried to reuse some core sonar classes in my plugin code. Unit tests were running fine. I packaged and deployed the plugin, and ran my first analysis. Everybody was happy. And then I got the dreadful (and definitely helpless message)  
maven-plugin:2.0:sonar failed: A required class was missing while executing org.codehaus.mojo:sonar-maven-plugin:2.0:sonar: org/sonar/wsclient/services/Query

Once you finished pulling hairs, screaming and cursing my name under all known gods, asking why the heck I used the webservice client and what is my real need, please consider the following.

short: Is it really bad to reuse sonar classes (I imagine that implementation may change in future version, or get deprecated, ...) ? The doc ( http://docs.codehaus.org/display/SONAR/Coding+a+plugin#Codingaplugin-Howtouseexternallibraries) states that " Sonar libraries are automatically inherited" but this apply to anything provided by the plugin API only ? Or could I use a magic parent basePlugin to gain access to the wonderful classes ? 

long: The sonar-packaging-maven-plugin filters out the sonar groupId "org.codehaus.sonar" from the dependencies metadata as this jar are provided by sonar. When you run the 'install' goal on your plugin, it actually clearly lists the available dependencies under the "Plugin definition in update center" section.
So in my case, the plugin classloader has no access to the sonar-ws-client classes even if I defined this dependency in my pom.
The error message shown above is confusing, as it occurs during the maven sonar:sonar goal execution. I will package my own classes and external libs for the WebService call, but out of curiosity I was wondering where I made the mistake, or if there is a workaround.

No urgency in my request, we're getting into a holiday weekend in France with finally some sun and summer temperatures. Cheers,

Laurent.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[sonar-dev] Re: Sonar plugin dependencies and the packaged Manifest.

Laurent Zilber
Answering to myself in case someone search the list:

- Do not re-use core classes, stick to your API and add your dependencies if the library is not already provided.
- Always check the logs when building the plugin as it contains very useful info, among other you plugin key and the list of actual dependencies :

[INFO] -------------------------------------------------------
[INFO] Plugin definition in update center
[INFO]     Key: powderalert
[INFO]     Name: Sonar "powder alert" plugin

<snip snip>

[INFO]     Build date: 2012-06-06T15:18:17+0200
[INFO] -------------------------------------------------------
[INFO] Following dependencies are packaged in the plugin:

    org.apache.httpcomponents:httpclient:jar
    org.apache.httpcomponents:httpcore:jar
<etc...>

Cheers,
Laurent.

Le 25/05/2012 11:23, Laurent Zilber a écrit :
Dear sonar developers,

Out of laziness, I tried to reuse some core sonar classes in my plugin code. Unit tests were running fine. I packaged and deployed the plugin, and ran my first analysis. Everybody was happy. And then I got the dreadful (and definitely helpless message)  
maven-plugin:2.0:sonar failed: A required class was missing while executing org.codehaus.mojo:sonar-maven-plugin:2.0:sonar: org/sonar/wsclient/services/Query

Once you finished pulling hairs, screaming and cursing my name under all known gods, asking why the heck I used the webservice client and what is my real need, please consider the following.

short: Is it really bad to reuse sonar classes (I imagine that implementation may change in future version, or get deprecated, ...) ? The doc ( http://docs.codehaus.org/display/SONAR/Coding+a+plugin#Codingaplugin-Howtouseexternallibraries) states that " Sonar libraries are automatically inherited" but this apply to anything provided by the plugin API only ? Or could I use a magic parent basePlugin to gain access to the wonderful classes ? 

long: The sonar-packaging-maven-plugin filters out the sonar groupId "org.codehaus.sonar" from the dependencies metadata as this jar are provided by sonar. When you run the 'install' goal on your plugin, it actually clearly lists the available dependencies under the "Plugin definition in update center" section.
So in my case, the plugin classloader has no access to the sonar-ws-client classes even if I defined this dependency in my pom.
The error message shown above is confusing, as it occurs during the maven sonar:sonar goal execution. I will package my own classes and external libs for the WebService call, but out of curiosity I was wondering where I made the mistake, or if there is a workaround.

No urgency in my request, we're getting into a holiday weekend in France with finally some sun and summer temperatures. Cheers,

Laurent.

Loading...