This was the issue that the plugin packs brought to light. We need a way to somehow have the declarations be in the descriptor but not cause the deployment to fail if the plugin does not exist (i.e. we'd ignore the resource types for things that need a plugin that doesn't exist). I'm pretty sure we wrote a JIRA on this recently - Jay S. might have written it up. ----- Original Message ----- From: "Heiko W.Rupp" <hwr(a)redhat.com&gt; To: "jopr-dev" <jopr-dev(a)lists.jboss.org&gt; Sent: Tuesday, May 12, 2009 8:24:41 AM GMT -05:00 US/Canada Eastern Subject: [jopr-dev] Inverted plugin dependencies / optional dependencies 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 _______________________________________________ jopr-dev mailing list jopr-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jopr-dev

I might be stating the obvious or be completely wrong here, but after having spent a while staring at the hibernate plugin code, I came to this: I think it is important to distinguish the two things we're trying to describe by the <depends> and <runs-inside> tags: 1) functional dependency of a plugin on another plugin. 2) definition of nesting of the resource types provided by the individual plugins. For 1) we can use <depends plugin="Blah" useClasses="true" /> The second point is more complicated IMHO. What we are trying to say here, I think, is (apart from the resource nesting) that the parent resource is able to provide functionality that the child resource expects. I.e. this doesn't constitute a dependency of the child plugin on the parent plugin but merely requires the parent to support certain interface (this being used in a very loose terms). Currently the runs-inside element requires all the parent resource types to be known by the plugin container. I.e. we cannot have just the hibernate plugin and jmx plugins deployed on the agent even though these two would be a perfectly functional pair - we have to have the jbossas plugin present as well just because the hibernate statistics service can be nested underneath JBossAS server. Note that this doesn't create a dependency of the hibernate plugin on jbossas plugin. All it's saying is that the _jbossas plugin_ has to be compatible with what hibernate plugin expects (which is that the JBossASServerComponent (i.e. the declared parent) has to implement JMXComponent interface). So my take on this would either to use the <import resource- type="BlahResource" plugin="BlahPlugin" /> on the platform/server/service of the "parent" plugin to inject the sub-resource (this being failsafe in absence of the specified plugin) or to make the runs-inside elements failsafe - i.e. not to fall over if the parent resource type/plugin isn't available. I'm not sure if we even need the <depends> tag without the "useClasses" attribute, because all it is then, I think, is a kind of forward declaration for the runs-inside elements later in the plugin configuration. Cheers, Lukas On Tuesday 12 May 2009 14:30:06 John Mazzitelli wrote: