Re: [hudson-dev] Questions and ideas for JSR330 plugins

[Henrik Lynggaard Hansen <henrik@xxxxxxx>]

Hi

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:
http://wiki.eclipse.org/Hudson-ci/Planning/Document_Provider)
- ToolsProvider
- PluginContext should only contain information related to this plugin
(and possibly other plugins).

Best regards
Henrik

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
>> http://dev.eclipse.org/mailman/listinfo/hudson-dev