The custom jmx plugin is a plugin that basically only consists of the plugin descriptor and which uses all the methods from the jmx-plugin to do its work.
Unfortunately this descriptor still needs to be packaged with in the plugin jar - even if no classes are deployed alongside, which is a hassle for quick plugin deployment.
It should be possible to deploy files that match the pattern "*-rhq-plugin.xml" as plugins, where the file is just a plugin descriptor which refers to exsiting plugins like the jmx one (or perhaps in the future to the script one or jruby-script or such.
Within the code on the server side, the plugin scanner would need to be modified to recognize those files, as well as the plugin deploy code to skip the unzip step and directly go the descriptor parsing (which would probably need to be changed slightly to understand *-rhq-plugin.xml names).
Changes on the plugin container side should be very similar.
easiest thing we could do right now is to package the .xml ourselves at runtime and deploy it as a jar. So if you copy a rhq-plugin.xml file to the /plugins directory, we grab it and before we put it in the real rhq.ear/plugins directory, we first zip it up and then copy it over. That's all we'd need to do - because from there on its just a normal plugin jar and no additional/extra processing or code changes are needed. This would be a localized enhancement solely in the plugin detector code - the thing that looks for files in the dropbox /plugins directory and the code that copies it over. Probably less than a day's worth of work to do this.
So you mean foo-rhq-plugin.xml becomes foo.jar with the .xml file pushed inside.
I agree that sounds very viable.
Would that also work via the UI plugins page? I think if a user has written such a *-rhq-plugin.xm file based plugin, he would want to deploy that thing later to production via the more official means.
(In reply to comment #2)
> So you mean foo-rhq-plugin.xml becomes foo.jar with the .xml file pushed
If you want to restrict the name of the file to requiring "-rhq-plugin.xml", yes you could do that. I was envisioning just taking whatever file name they give it and replace .xml to .jar. For example, "foo.xml" would be my descriptor which would result in "foo.jar", inside of that jar would be a rhq-plugin.xml file that has the same content as the original foo.xml.
> Would that also work via the UI plugins page? I think if a user has written
> such a *-rhq-plugin.xm file based plugin, he would want to deploy that thing
> later to production via the more official means.
I'm not sure if we restrict the file upload to only accept .jar files or not - its possible this will "just work" if we don't care what file extension we accept during the file upload. Taht would be simple to test and probably simple to workaround if we do only accept .jar files.
Note, Hyperic HQ supports this.
(In reply to comment #3)
> If you want to restrict the name of the file to requiring "-rhq-plugin.xml",
> yes you could do that. I was envisioning just taking whatever file name they
Yes I would require that, as this way it
a) is more clear what can be deployed
b) prevents users to deploy 2* rhq-plugin.xml for different plugins and be astonished that one of those get overwritten by the other. Here it is a bit clearer that the user needs to give it a proper name.
Maybe the JBoss Shrinkwrap project  can be useful in this case.
Created attachment 597612 [details]
This patch allows to deploy *-rhq-plugin.xml files as plugin descriptor.
Such a plugin will register fine on the server and will need discovery and component classes from other plugins (e.g. abstract base ones).
Created attachment 597664 [details]
Updated patch after having discussed this with Mazz.
We will now just wrap such a plugin descriptor into a jar and put this back into the plugins directory from which the plugin scanner will pick it up and do the normal processing.
Such jar-less plugins need to be named *-rhq-plugin.xml
See also http://pilhuhn.blogspot.de/2012/07/jar-less-plugins-for-rhq.html
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.