forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Plugins as sub projects(Re: Duplicate code)
Date Tue, 16 Nov 2004 13:33:58 GMT
Ferdinand Soethe wrote:
> 
> Ross Gardler wrote:
> 
> RG> It is intended that plugins will have separate release cycles, yes. In
> RG> fact, it is intended that other projects will develop plugins, in this
> RG> case We would have no influence over their release cycle.
> 
> RG> See the work starting with Lenya with respect to this. It is my hope
> RG> that, eventually, Lenya will be pluggable into Forrest through our
> RG> plugins framework.
> 
> Then it seems sensible to have a separate section of a site
> for every plugin.

We do (kind of). Each plugin has its own src directory and therefore its 
own content. The IMSManifest plugin has the capability of including 
whole sites within other sites. We discussed moving this functionality 
so that it worked with site.xml. This would mean that the plugin 
documentation (or a portion of it) can be included in a sensible 
location inside the Forrest site 
(http://forrest.apache.org/plugins/PLUGIN_NAME), whilst still allowing 
individual plugins to maintain their own svn tree etc.

> How about setting up a separate Forrest where group is Forrest and
> Project is plugins with a separate tab for every plugin.

This (and the stuff I snipped here) is essentially how the inclusion 
stuff works. I just need to find the time to extract the relevant code 
from the IMSManifest plugin.

> = BTW: Does forrests plugin-interface have the ability to not allow
>        untested plugins to be installed. I found that in Firefox an
>        annoying yet very valuable feature since it keeps support from
>        drowning in plugin related question.

Not right now, but I have added a version attribute to the plugins 
manifest to allow this to happen in the future. I also added a minimim 
forrest version attribute so that we don't try and install plugins into 
a version of Forrest that can't support it (functionlaity not in place, 
just the version attribute).

> So always referring to the latest stable version doesn't seem to make
> a lot of sense, instead the link from say Forrest to a plugin should
> only be (manuelly) updated when the new version was tested with
> Forrest and found to be working.

Right now there is no automated updating, so this is not an issue. But 
it will be, see http://issues.cocoondev.org/browse/FOR-343

Ross

Mime
View raw message