|Re: [hudson-dev] Questions and ideas for JSR330 plugins|
Henrik,I think this is a great idea. Right now most of the internal informations are obtained via the Singleton "grandfather" object "Hudson". I believe what you are suggesting is something like
@Inject PluginContext pluginContext; In the code Logger logger = pluginContext.getLogger(); logger.log(...);The pluginContext will be injected at runtime, by Hudson Platoform. This gives an opportunity to test the plugin code with Mock PluginContext.
This is would be in oppose to Hudson.getInstance().getLogger().Lets start a wiki to keep track of the discussion. Your initial list of services exposed by this context seems like a good starting point.
- Winston On 1/26/12 12:35 PM, Henrik Lynggaard Hansen wrote:
Hi As far as I have understood the benefits of JSR-330 plugins, one of them is that Hudson can inject "components?" into plugins. However I haven't found a good overview of which concreate resources hudson provides which can be injected. do we have some documentation which highlights these ? One idea for a injectable component could be a PluginContext which should help the plugin behave nicely. I see this context providing the following: * A configured Logger of our own making. This way we can control the logger name and provide a standard naming convention, so that users don't need to hunt around for class names.Secondly haivng it be a Hudson class, we would separate plugins from the underlying framework and hopefully avoid the flurry of 3. party frameworks * A File object pointing to a work directory where the plugin is free to write files. Right now most plugins just pick somewhere random inside hudson-home * Ability to query Hudson version and other metadata, plus better/cleaner way of finding other plugins. Comments ? Best regards Henrik _______________________________________________ hudson-dev mailing list hudson-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/hudson-dev
Back to the top