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


Jason's argument for not creating another god object seems compelling. Let us think this over and create one if needed or try to use said service injection.

- Winston

On 1/28/12 3:00 AM, Henrik Lynggaard Hansen wrote:

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>:

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

PluginContext pluginContext;

In the code

Logger logger = pluginContext.getLogger();

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:

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
* 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
hudson-dev mailing list

Back to the top