Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hudson-dev] Questions and ideas for JSR330 plugins


Yes this is exactly what I want :-) And I think there should be more
of such resources such as
- DocumentStorage: Gains access to the documents stored under Maven3
configuration (which I think should be made generic:
- ToolsProvider
- PluginContext should only contain information related to this plugin
(and possibly other plugins).

Best regards

2012/1/26 Winston Prakash <winston.prakash@xxxxxxxxx>:
> 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

Back to the top