Question about plugin dependencies

[Jay McHugh <jd...@sbcglobal.net>]

Hi all,

I was wondering - is it possible to have a plugin that needs 'at least one of' or 'either of' some other plugin?

For example, it is possible to use dojo loaded from AOL's content delivery network.  So, if we made two versions of a Dojo plugin: One that has everything in it (the full Dojo WAR file and sources) and the other that only insert whatever would be necessary to use the CDN copy of Dojo.   Would it be possible to indicate that one or the other must be installed in order to use the JNDI viewer plugin?

I am thinking again about reducing footprint (and Dojo in particular though it could be relevant elsewhere).  So if someone had a situation where they knew that they would always be connected to the internet you could install the plugin that just pointed to the CDN but if they were not sure, then they could install the full local version of the plugin.

And I am also thinking about cases where the same functionality could be provided in two (or more) distinctly different ways (Tomcat and Jetty?).  If we could indicate that you have to have one or the other installed, but we didn't care which one then we could possibly reduce the number of plugins that we provide because we wouldn't need to specifically follow both paths with a 'Tomcat' version and a 'Jetty' version.  There would just be a dependency that says you need one or the other.

Just some thoughts about how trunk's more pluggable design might make everyone's lives better and easier.

Jay

Re: Question about plugin dependencies

[David Jencks <da...@yahoo.com>]

On Oct 26, 2007, at 3:01 PM, Jay McHugh wrote:

> Hi all,
>
> I was wondering - is it possible to have a plugin that needs 'at  
> least one of' or 'either of' some other plugin?

yes, but maybe not exactly the way you are thinking about it.
>
> For example, it is possible to use dojo loaded from AOL's content  
> delivery network.  So, if we made two versions of a Dojo plugin:  
> One that has everything in it (the full Dojo WAR file and sources)  
> and the other that only insert whatever would be necessary to use  
> the CDN copy of Dojo.   Would it be possible to indicate that one  
> or the other must be installed in order to use the JNDI viewer plugin?
>
> I am thinking again about reducing footprint (and Dojo in  
> particular though it could be relevant elsewhere).  So if someone  
> had a situation where they knew that they would always be connected  
> to the internet you could install the plugin that just pointed to  
> the CDN but if they were not sure, then they could install the full  
> local version of the plugin.
>
> And I am also thinking about cases where the same functionality  
> could be provided in two (or more) distinctly different ways  
> (Tomcat and Jetty?).  If we could indicate that you have to have  
> one or the other installed, but we didn't care which one then we  
> could possibly reduce the number of plugins that we provide because  
> we wouldn't need to specifically follow both paths with a 'Tomcat'  
> version and a 'Jetty' version.  There would just be a dependency  
> that says you need one or the other.

that might be tough because apps that actually need tomcat or jetty  
when turned into plugins have completely different gbeans in them.   
If you just needed a web app that did something as a dependency this  
might work.
>
> Just some thoughts about how trunk's more pluggable design might  
> make everyone's lives better and easier.

So, the way you do this now is with the var/config/ 
artifact_aliases.properties.  You deploy your app with a dependency  
on one plugin, say the full dojo plugin.  If you want to switch to a  
minimal dojo plugin, you'd install that one and add a line in  
artifact_alieases.properties saying

full_dojo_config_id=minimal_dojo_config_id

You can actually automate this because geronimo-plugin.xml can have  
content for artifact_aliases.properties so you can include this line  
right in the plugin and when it gets installed it modifies  
artifact_aliases.properties.

One place we're using this is in some of the plugins such as the  
roller plugin and I think the jetspeed plugin Prasad is working on.   
We install with a default dependency on  a derby datasource plugin  
but if you want to swap databases you install a plugin for your  
desired db.  As noted above it maps the derby dependency to itself.

thanks
david jencks

>
> Jay