Plugin Cooperation

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

Plugin Cooperation

Eric Crahen-3
Hi,

If I have one plugin which contains something like Ivy and sets up the configuration for Ivy, I have access to all of that inside the classes contained in the Ivy Plugin. Now I want to  add a second plugin, this one will also use Ivy - but it has a different job. Its going to do a highly specialized task which happens to involve Ivy. Is there anyway to leverage the configuration and/or classes from the first plugin? It seems like the answer is probably no since they live in sibling classloaders.

I also have a straw man of an Ant plugin that allows for some simple extras the current Ant doesn't allow - like setting the associated system properties w/ a nice UI. I wanted to make my Ivy plugin actually use the Ant plugin since what I want to do is basically run ant, and add the -lib options for the Ivy antlibs. There again I want to share references to objects.

I can overcome the classloader isolation with reflection to actually have one plugin use a class from another, but is there some way to get the object reference of one plugin into another? For instance, take the Ant and Ivy-Ant plugins. Both are Builders and the later wants to see the former - and they want to see the configured Builder instance, not the Descriptor.

--

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

Re: Plugin Cooperation

Kohsuke Kawaguchi
Administrator
I believe we discussed this some time ago between us.

I think the proper thing to do is to allow plugins to declare
dependencies to each other, and have Hudson set up classloaders
accordingly. Could you open an issue for this so that we can keep
track?

2007/2/24, Eric Crahen <[hidden email]>:

> Hi,
>
> If I have one plugin which contains something like Ivy and sets up the
> configuration for Ivy, I have access to all of that inside the classes
> contained in the Ivy Plugin. Now I want to  add a second plugin, this one
> will also use Ivy - but it has a different job. Its going to do a highly
> specialized task which happens to involve Ivy. Is there anyway to leverage
> the configuration and/or classes from the first plugin? It seems like the
> answer is probably no since they live in sibling classloaders.
>
> I also have a straw man of an Ant plugin that allows for some simple extras
> the current Ant doesn't allow - like setting the associated system
> properties w/ a nice UI. I wanted to make my Ivy plugin actually use the Ant
> plugin since what I want to do is basically run ant, and add the -lib
> options for the Ivy antlibs. There again I want to share references to
> objects.
>
> I can overcome the classloader isolation with reflection to actually have
> one plugin use a class from another, but is there some way to get the object
> reference of one plugin into another? For instance, take the Ant and Ivy-Ant
> plugins. Both are Builders and the later wants to see the former - and they
> want to see the configured Builder instance, not the Descriptor.
>
> --
>
> - Eric


--
--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Plugin Cooperation

Jesse Glick
Kohsuke Kawaguchi wrote:
> I think the proper thing to do is to allow plugins to declare
> dependencies to each other, and have Hudson set up classloaders
> accordingly.

Or use a real module system, such as OSGi.

-J.

--
[hidden email]  x22801  netbeans.org  ant.apache.org
       http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Plugin Cooperation

Kohsuke Kawaguchi-2
Jesse Glick wrote:
> Kohsuke Kawaguchi wrote:
>> I think the proper thing to do is to allow plugins to declare
>> dependencies to each other, and have Hudson set up classloaders
>> accordingly.
>
> Or use a real module system, such as OSGi.

Ah, that's right, that was also mentioned. It's just that I expect that
to be quite a non trivial work. If someone knows about OSGi (you might
have experience working with that from your NetBeans background?), and
willing to do it, I'm for it.

But otherwise I suspect a minor improving to what we already have seems
to fit our resource budget better...

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

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

Re: Plugin Cooperation

Jesse Glick
Kohsuke Kawaguchi wrote:
> It's just that I expect that to be quite a non trivial work.

Possibly. Properly implementing multiparented class loader delegation is
not trivial either.

> you might have experience working with [OSGi] from your NetBeans
> background?

NetBeans actually has its own module system, very roughly similar to the
core of OSGi. E.g.

http://dvbcentral.sourceforge.net/netbeans-runtime.html

Basic features are versioned module dependencies with class loader
partitioning; API package restriction; lifecycle support (e.g. startup
hooks); declarative registration of services (superset of JAR Services
Spec). OSGi has similar features (though I am not sure if JAR service
discovery is offered as a standard facility), as well as other services
which may or may not be of interest in something like Hudson.

-J.

--
[hidden email]  x22801  netbeans.org  ant.apache.org
       http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]