Re: Dependency between Publishers?

Eric Crahen wrote:
> My thinking was that a user might have already entered a list of artifacts
> from the build they performed in the archiver section. I wanted to leverage
> that list of artifacts as my "stuff to examine" when it came time to run a
> tool like FindBugs, run javadoc over, or to publish those artifacts with
> Ivy. This way I wouldn't need to list out the "stuff" a project produced
> several times.

I see. Just FYI, from your Publisher you can also programmatically look 
at ArtifactArchiver's setting, if that helps.


> I guess the other way I could do this would be to allow each BuildStep to
> look for artifacts in a certain directory. If my Ant projects all put thier
> artifacts into a "build" directory, I could set the location for each plugin
> to "build" in the global settings. I have to repeat that location a couple
> times (once for each plugin) but since its done only once and each
> sub-project would inherit the setting that wouldn't be so bad. This is
> probably a better way to go since adding dependencies between publishers
> would probably be more complicated than its worth.

I've been thinking about similar things --- at some point configuring 
each plugin independently becomes too painful, and you are right that we 
should be doing something better.

My approach to this problem has been the upcoming Maven support in 
Hudson (currently a work-in-progress in the hudson.maven package.) Maven 
projects are quite uniform and declarative, so I can figure out where 
source files are, where javadoc is generated, and etc, automatically.

So the Hudson configuration screen could be a whole lot simpler. If you 
tell Maven to run javadoc, Hudson notices that and automatically 
archives its output.


Doing this with Ant is bit harder, because a program can't really grok 
build scripts. The idea that I had was to actually embed Ant in Hudson, 
then trace execution of each task. For example if <javadoc> task is 
executed, Hudson can notice that and archive it right there. I think 
this might work fairly well in practice.


> I think what is making my plugins a bit different from the ones that exist
> right now in that I'm trying to actually automate the entire process of
> doing something like create javadoc. Where as the plugin that exists right
> now will run javadoc if you tell it all the right stuff to do. Since I have
> a team of people working on different things, it would be better for me if I
> could do something like configure a plugin to say, each project puts
> artifacts here, and then a project owner just checks a box and we get
> javadoc, they check another box and we get a report about something  - but
> the logic they put in the build.xml didn't have to mention any of that, and
> they didn't have to write any special files or anything either. There will
> still be times (my) users may want to provide some sort of special input
> specific to one of these tools, so they'll have some option to provide that,
> but my 95% use case would be someone checking a box and getting something
> set up.
>
> (Its a little more complex than just run a tool and you are done, even for
> javadoc you may want the classpath of your dependencies - so I'll have to
> figure out something there, but I have some ideas.)

--
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@xxxxxxx

smime.p7s
Description: S/MIME Cryptographic Signature