Dependency between Publishers?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Dependency between Publishers?

Eric Crahen-3
I'd like to generate some reports on artifacts that the artifact archive has archived. I haven't found a way to officially configure the archiver to run before the reporter. So far, I appear to just be getting lucky when I check them both. Is there a way to express such a dependency?

--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: Dependency between Publishers?

Kohsuke Kawaguchi-2
Eric Crahen wrote:
> I'd like to generate some reports on artifacts that the artifact archive has
> archived. I haven't found a way to officially configure the archiver to run
> before the reporter. So far, I appear to just be getting lucky when I check
> them both. Is there a way to express such a dependency?

I believe Hudson invokes listeners in the order they are placed in the
BuildStep.PUBLISHERS (if not, we should fix that.) So the poorman's
approach to this problem has been to place them in the right place in
the list.

It's certainly conceivable to come up with more elaborate scheme, like
perhaps by declaring dependencies, but I suspect it won't really buy us
that much.

Also, if all you're trying to do is to record the reports as a part of
build, and don't really care if it's a part of the "artifacts" or not,
then it's better to store reports on your own directory. For example,
junit report publisher does just that. The added benefit is that the
user won't have to configure two places to get it right.

If you really need to place things under the artifacts directory, your
publisher can just copy whatever you produced into the artifacts
directory on your own. I think this is pretty easy and not much code
duplication involved.

If you can explain a bit of context, I can probably give you better
suggestions.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dependency between Publishers?

Eric Crahen-3
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 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 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.)


On 1/29/07, Kohsuke Kawaguchi <[hidden email]> wrote:
Eric Crahen wrote:
> I'd like to generate some reports on artifacts that the artifact archive has
> archived. I haven't found a way to officially configure the archiver to run
> before the reporter. So far, I appear to just be getting lucky when I check
> them both. Is there a way to express such a dependency?

I believe Hudson invokes listeners in the order they are placed in the
BuildStep.PUBLISHERS (if not, we should fix that.) So the poorman's
approach to this problem has been to place them in the right place in
the list.

It's certainly conceivable to come up with more elaborate scheme, like
perhaps by declaring dependencies, but I suspect it won't really buy us
that much.

Also, if all you're trying to do is to record the reports as a part of
build, and don't really care if it's a part of the "artifacts" or not,
then it's better to store reports on your own directory. For example,
junit report publisher does just that. The added benefit is that the
user won't have to configure two places to get it right.

If you really need to place things under the artifacts directory, your
publisher can just copy whatever you produced into the artifacts
directory on your own. I think this is pretty easy and not much code
duplication involved.

If you can explain a bit of context, I can probably give you better
suggestions.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]





--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: Dependency between Publishers?

Eric Crahen-3
I can definitely still make the plugins to run the various tools I'd like to run, I'm just also looking for ways to make it even simpler to user.


On 1/29/07, Eric Crahen <[hidden email]> 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 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 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.)



On 1/29/07, Kohsuke Kawaguchi <[hidden email]> wrote:
Eric Crahen wrote:
> I'd like to generate some reports on artifacts that the artifact archive has
> archived. I haven't found a way to officially configure the archiver to run
> before the reporter. So far, I appear to just be getting lucky when I check
> them both. Is there a way to express such a dependency?

I believe Hudson invokes listeners in the order they are placed in the
BuildStep.PUBLISHERS (if not, we should fix that.) So the poorman's
approach to this problem has been to place them in the right place in
the list.

It's certainly conceivable to come up with more elaborate scheme, like
perhaps by declaring dependencies, but I suspect it won't really buy us
that much.

Also, if all you're trying to do is to record the reports as a part of
build, and don't really care if it's a part of the "artifacts" or not,
then it's better to store reports on your own directory. For example,
junit report publisher does just that. The added benefit is that the
user won't have to configure two places to get it right.

If you really need to place things under the artifacts directory, your
publisher can just copy whatever you produced into the artifacts
directory on your own. I think this is pretty easy and not much code
duplication involved.

If you can explain a bit of context, I can probably give you better
suggestions.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]





--

- Eric



--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: Dependency between Publishers?

Kohsuke Kawaguchi-2
In reply to this post by Eric Crahen-3
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                   [hidden email]

smime.p7s (4K) Download Attachment