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

[Henrik Lynggaard Hansen <henrik@xxxxxxx>]

2012/2/7 Jason Dillon <jason@xxxxxxxxxxxx>:

>> If there is already a place for this then there is of course no need
>> to add this to a potential PluginContext. However given the state of
>> many of the current APIs, the next question then becomes. Should we
>> create a "clean" PluginManager API or is the current one in good
>> enough quality. On one hand I hate the double work of creating a
>> wrapper, but on the other hand I really like to shield new plugins
>> from the worst parts of Hudson.
>
> The strategy we were going for Hudson Pro @ Sonatype was to create new clean service apis.

I was hoping you were leaning in that direction, because so I am. Of
course it requires that we evaluate the individual APIs so we
concentrate the effort on the APIs where a cleaner version brings the
most value.

Prioritizing this work is a completely different topic that I wont
begin now as it very much depends on the other plans after the eclipse
conversion.

> IMO these are exactly the same, user would need to know some logger name to some level.  I'd solve this with documentation until there was a clear need to make a easy human friendly way to flip on/off various loggers.  At which point I'd implement a richer logging management plugin and expose some extension points to allow plugins to express their logging use in terms that can easily be shown to users w/o forcing plugin to share a single (IMO evil) injected logger.
>
>> What would your suggestion be for making sure users have easy
>> discoverable logger names?
>
> Presently, add a section to plugin documentation that covers the relevant logger names.  For a more robust solution, implement a component which expresses the details & then implement a UI to allow the user to control what is enabled.
>
> If Sonatype had continued development on Hudson Pro, we would have gone the later route.


In essence you are right, and maybe I am just venting my frustration
of the current level of such documentation and quality of the logging
content. Overall I just want the solution that makes it easy for
developers to do the right thing and hard to to the wrong thing. The
right thing naturally being the one which adds most value to the
customer.

>>> Sure, that page doesn't cover components exposed by every possible plugin... that would be a difficult list to grok.
>>
>> Agreed but we should have  page that describes exposed components from
>> the core and possibly plugins bundled with the core.
>
> Better IMO to start getting developers of plugins in the habit of documenting things which are extensible in their plugin documentation pages.

The actual location of the documentation or if it is one page or many
doesn't really matter as long as it is easy to find.

We should however set a good example and document the
service/components provided by the core and bundled plugins.

> What is the use-case?  I've not heard many folks demanding logger name details (though I've not really been paying a ton of attention either), and you can generally sort that out by just enabling a lower level until you can see the detail you want/need.

In our hudson setup we have had to switch to warning in order to get
the logging down to a reasonable amount, even INFO generated too much.
So hunting for the correct information in debug mode is near
impossible. Secondly the startup time of a hudson instance (15-20min)
rules out quickly switching levels.
>>> c) use slf4j over creating yet another logging facade

As you can see from my other mailing list post, I have already bought
into that idea :-)

> Well, not like JUL is any better here.  The lack of varargs in slf4j is annoying, which is why this guy exists:
>
> public class Varargs
> {
>    public static <T> T[] va(final T... args) {
>        return args;
>    }
>
>    public static <T> T[] $(final T... args) {
>        return args;
>    }
> }

Just curious, why a method named "$" ? or am I reading that wrong ?

Best regards
Henrik