2011/7/12 Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":1rm">From a rabbit user perspective, I reckon by far the most convenient way to get hold of rabbit plug-ins is not having to get hold of them at all :) I.e. we could bundle plug-ins with the server, and add a mechanism (in, e.g. rabbitmqctl) to select which plug-ins should be enabled.<br>
<br>
…<br>
<br>
But there are downsides too. The main one is that bundling only works for plug-ins blessed by Rabbit HQ, with all other plug-ins having to go the existing .ez route. And there are some challenges in the packaging, e.g. what should the source distribution (i.e. the source downloads on the rabbit web site, the debian source package, etc) contain?<br>
<br>
<br>
Suggestions are welcome on how we should go about this.</div></blockquote></div><br>Matthias,<br><br>bundling "RabbitMQ HQ" plugins and having a way to activate them sounds like a good idea. 3rd party plugins can work the way they work today, and the source distribution should then include plugins, structured similarly to the way RabbitMQ public umbrella repository is structured. I don't think it will make building packages significantly more complicated.<br clear="all">
<br>Some package managers, for example, Homebrew, push back on adding ways to install plugins for projects like RabbitMQ and Nginx (the idea is that it is too much work for everyone to maintain packages that in turn manage "subpackages"). But if plugins are part of the core RabbitMQ package and only need activation, this issue will likely to be considered resolved for Rabbit once and for all.<br>
-- <br>MK<br><br><a href="http://github.com/michaelklishin" target="_blank">http://github.com/michaelklishin</a><br><a href="http://twitter.com/michaelklishin" target="_blank">http://twitter.com/michaelklishin</a><br><br>