intra-plugin communication?

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

intra-plugin communication?

Eric Crahen-3
I've a question for you about plugins.

What's a decent way for plugins to cooperate? They live in different ClassLoaders, which is a good thing - but here is my scenario

I have two different plugins that generate two reports. One tells me information about code coverage, another tells me information about some other static analysis methods (FindBugs, PMD, etc). In addition to the pretty reports that managers enjoy, they also have raw information available, like 85% code coverage or 11% of the code was questionable via some static analysis.

Those work fine.

I'd like to actually make a third plugin. This plugin's job is to look at three pieces of info. Did the build pass? Did the code coverage exceed a minimum threshold? Did the static analysis report find "questionable" code below a certain threshold? If so, I'd consider the build OK and I'd like to publish (Ivy), archive it, javadoc it, etc...

I'll stick with just the Ivy publish (which is another plugin I'd make). Archive and javadoc aren't good examples because those actually turn up in the parent classloader since they don't actually get loaded through the real plugin mechanism.

What is a good way for my Ivy publishing plugin that lives in one classloader, to find out information about something from another classloader?

--

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

Re: intra-plugin communication?

Eric Crahen-3
I guess one way would be for Properties to be exposed on a Job that a plugin might just put such information into...

On 2/3/07, Eric Crahen <[hidden email]> wrote:
I've a question for you about plugins.

What's a decent way for plugins to cooperate? They live in different ClassLoaders, which is a good thing - but here is my scenario

I have two different plugins that generate two reports. One tells me information about code coverage, another tells me information about some other static analysis methods (FindBugs, PMD, etc). In addition to the pretty reports that managers enjoy, they also have raw information available, like 85% code coverage or 11% of the code was questionable via some static analysis.

Those work fine.

I'd like to actually make a third plugin. This plugin's job is to look at three pieces of info. Did the build pass? Did the code coverage exceed a minimum threshold? Did the static analysis report find "questionable" code below a certain threshold? If so, I'd consider the build OK and I'd like to publish (Ivy), archive it, javadoc it, etc...

I'll stick with just the Ivy publish (which is another plugin I'd make). Archive and javadoc aren't good examples because those actually turn up in the parent classloader since they don't actually get loaded through the real plugin mechanism.

What is a good way for my Ivy publishing plugin that lives in one classloader, to find out information about something from another classloader?

--

- Eric



--

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

Re: intra-plugin communication?

Kohsuke Kawaguchi-2
In reply to this post by Eric Crahen-3
Eric Crahen wrote:

> I've a question for you about plugins.
>
> What's a decent way for plugins to cooperate? They live in different
> ClassLoaders, which is a good thing - but here is my scenario
>
> I have two different plugins that generate two reports. One tells me
> information about code coverage, another tells me information about some
> other static analysis methods (FindBugs, PMD, etc). In addition to the
> pretty reports that managers enjoy, they also have raw information
> available, like 85% code coverage or 11% of the code was questionable via
> some static analysis.
>
> Those work fine.
Cool. I'm really looking forward to seeing them in hudson.dev.java.net.

> I'd like to actually make a third plugin. This plugin's job is to look at
> three pieces of info. Did the build pass? Did the code coverage exceed a
> minimum threshold? Did the static analysis report find "questionable" code
> below a certain threshold? If so, I'd consider the build OK and I'd like to
> publish (Ivy), archive it, javadoc it, etc...
>
> I'll stick with just the Ivy publish (which is another plugin I'd make).
> Archive and javadoc aren't good examples because those actually turn up in
> the parent classloader since they don't actually get loaded through the real
> plugin mechanism.
>
> What is a good way for my Ivy publishing plugin that lives in one
> classloader, to find out information about something from another
> classloader?
Part of the problem is to get to the object that has the information.
Presumably your code coverage and FindBugs plugin contributed Actions to
the Build, and all publishers get access to all the actions in the
build, so that's how you can access objects that has the information.

Then the second issue is how to access that information nicely.
Obviously you can do reflection, but you'd want more statically typed
access.

I think maybe this is really the time to implement dependencies among
plugins. That would allow your Ivy plugin to see all the classes you
defined in other plugins.

Another issue is how you declare such dependency in your POM. The
packaging form of a plugin is .hpi, and that by itself cannot be used as
a dependency jar of another plugin. Maybe the hpi packaging would need
to produce an ordinary jar on the side.

Other workarounds include using Groovy to acess the data, or passing
values via a generic interfaces in JDK like Map or Properties.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment