Bug 741682

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
> inside.

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.

http://support.hyperic.com/display/DOC/Plugin+XML+Descriptor

(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.

Hi.

Maybe the JBoss Shrinkwrap project [1] can be useful in this case.

[1] http://www.jboss.org/shrinkwrap

Created attachment 597612 [details]
Possible patch

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]
Proposed patch

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.

master 1656f7c935fe1b

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.