[jopr-dev] Inverted plugin dependencies / optional dependencies

Heiko W.Rupp hwr at redhat.com
Tue May 12 08:24:41 EDT 2009


Hi,

currently we have plugin dependencies that a "child" plugin can say it  
depends on a parent plugin

E.g. in the hibernate plugin:

    <depends plugin="JMX" />
    <depends plugin="JBossAS" useClasses="true"/>

and later

       <runs-inside>
          <parent-resource-type name="JMX Server" plugin="JMX"/>
          <parent-resource-type name="JBossAS Server" plugin="JBossAS"/>
       </runs-inside>

Now if I would want to re-use the hibernate plugin in the AS5 plugin,  
I could write:

    <depends plugin="JMX" />
    <depends plugin="JBossAS" useClasses="true"/>
    <depends plugin="JBossAS5" useClasses="true"/>

But a) 2x useClasses="true" is probably not allowed and b) it would
require that both the as4  + as5 plugin need always to be present, even
in the case of Embedded Jopr within AS5.

So one way to tackle this could be that the Hibernate plugin is not  
declaring a
depencency on the AS* plugins, but that the AS* plugins "import" the  
Hibernate plugin

<import plugin="Hibernate"/>

This also has the advantage that the Hibernate plugin would not need  
to be
modified when e.g. it should be used within e.g. the Tomcat plugin.


Another option could be to mark/group optional or mutual exclusive  
dependencies

    <depends plugin="JMX" />
    <mutual-exclusive>
       <depends plugin="JBossAS" useClasses="true"/>
       <depends plugin="JBossAS5" useClasses="true"/>
   </mutual-exclusive>

Here only one of AS4 or AS5 plugins needs to be present and the JMX  
plugin is required.


One thing we need with both approaches is to meaning fully inject the  
parent resource and/or
existing EmsConnections (I have the feeling that very often the parent  
is needed because of its
connections to the remote).



-- 
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei  
München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,  
Charles Cachera





More information about the jopr-dev mailing list