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

[Winston Prakash <winston.prakash@xxxxxxxxx>]

Henrik,

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