Re: How to enable a publisher by default?

Eric Crahen wrote:
> I think what I want is a Publisher because I actually want to generate
> reports and put them in the UI. Although maybe a build listener could do
> that too.

OK, so in its core functionality it's really not that different from, 
say, Emma plugin or JUnit reporter.

> I can explain my use case a little more,
>
> The scenario I have that might make my use case different is that I have a
> Hudson installation that I want shared by a team. Sometimes a policy is made
> that all artifacts should have certain reports generated. If the maintainer
> of the Hudson instance could configure this once, through a global setting,
> then all the N projects different users add to Hudson would automatically
> get these reports with little effort. They wouldn't have to do extra
> clicking to enable this sort of thing. My current thinking is that for any
> archived artifacts, I'd automatically generate code coverage and findbugs
> reports. Publishing javadocs automatically by running javadoc over any
> jar/class artifacts could be another I'd explore shortly after that.

I see. To me this sounds like somewhat orthogonal to the plugin itself.

That is, I think your plugins would be more reusable to other people if 
they don't have built-in knowledge about the policy of your development 
team. For example, some of the jobs that I run on my Hudson would very 
much like to use FindBugs plugin, but we don't have the policy like yours.

What you are describing makes sense too --- when you have a large number 
of "similar" projects, it should be easy to configure them in a similar 
way, without going through each project separately. But my point is that 
such thing shouldn't really be baked into your plugin, because it should 
be applicable to any setting, like log rotation, fingerprinting, IRC, etc.

This "maintaining a large number of projects with similar settings" 
support is one of the obvious things that Hudson should do better, but I 
haven't found a good answer that brings simplicity.

Perhaps one approach could be for you to extend Project and override the 
configuration portion. It's still a Project, so it will behave like it, 
but you can take over the configuration screen completely and let users 
configure just small portion of parameters.

For example, your team might be using a standard directory layout 
convention, and perhaps you won't have to make the javadoc directory 
configurable. Or you might want to automatically enable IRC notification 
to the channel name that can be automatically derived from the job name, 
etc. All the jobs might use the same CVS server, and if so you can 
eliminate the SCM configuration completely except perhaps the module 
name and the branch name.

In this way, you should be able to eliminate a considerable number of 
options from the configuration screen. Less form fields = simpler!

The user would then have to just choose "our team's project" (or 
something) when they create a new job, and they'll see a much simpler 
config screen and Hudson will behave as if it understands your team's style.

We'll probably need to refactor Project object a bit so that you can 
take over the configuration more easily, but I believe this is a 
feasible approach.


> Users can configure this each time for each project, but people might select
> different settings - and probably more importantly, the user just perceives
> extra work.  Introducing new tools can be challenging, so whenever I can
> look for ways to make it as simple as possible.  This seemed like a good
> place to do something like because the alternative is to write a wiki note
> somewhere that explains what to check and what to put in different text
> fields. (Its not hard, I agree - but for me its all about making things
> simple)

I wholeheartedly agree that we engineers should be lazy and shouldn't be 
forced to read documentation :-)


> The approach of letting Publishers fill in their own fields is interesting.
> I think this might be a good approach. Would it be possible to somehow to
> auto-check that check box as well?

I hope I provided a better alternative above, but if you still want to 
just enable a publisher by default, we can talk about getting the 
addPublisher/save work.

--
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@xxxxxxx

smime.p7s
Description: S/MIME Cryptographic Signature