forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)
Date Thu, 04 May 2006 13:49:02 GMT
Cyriaque Dupoirieux wrote:
> le 04/05/2006 09:06 Ross Gardler a écrit :
> 
>> David Crossley wrote:
>>
>>> Thorsten Scherler wrote:
>>>
> 
>> [SNIP]
> 
> 
>> Nice overlap with Ferdinands proposal for a clear development 
>> proposal. Lets use this as a test case. I'll be proposing the Daisy 
>> plugin too once I have enough time to document it a little better. We 
>> can use both the Daisy and the Dispatcher/themer plugins as test cases.
>>
>> One thing that will have to happen before the Dispatcher comes out of 
>> core is to resolve the plugin dependency issues.
>>
>> Some time ago we agreed that plugins should not have any dependencies 
>> on one another. We also acknowledged that here may come a time in 
>> which such a dependency is required. This may be it, but the plugin 
>> architecture does not currently support dependencies. We need to 
>> create the concept of "features" which are collections of plugins that 
>> work together to achieve a specific goal.
> 
> I think we need to specify the concept of "feature" for plugins and the 
> notion of plugin dependency of "features".

Sorry, I'm using Eclipse terminology here. It is a little counter 
intuitive. A feature is a collection of plugins that work together well.

So for example, a feature may be "convert ODT files to PDF". This would 
require the ODT input plugin and the PDF output plugin. Or a feature may 
be "provide a theming ability based that allows individual pages to be 
given a different structure", this would be the Dispatcher internal 
plugin and the themer plugin.

> Try to explain :
> 
>    * Plugin A implement the Feature 1
>    * Plugin B also implement the feature 1
> 
>    * Plugin C depends on the feature 1

So, given the above definitions of feature a plugin does not implement a 
feature. A feature is a set of plugins. Instead a plugin adds a unit of 
functionality to the core of forrest, which can be used to create a 
specific feature.

By doing this a plugin is not directly dependant on another plugin. 
Instead a feature defines a collection of plugins that will work happily 
together. This means that we can then have a feature that uses, for 
example, the dispatcher plugin, but does not use the themer plugin, 
instead it uses, for example, a hypothetical JXTemplates plugin for 
themeing.

> For instance, Plugin C is the dispatcher and Plugins A and B two 
> implementations of the core.theme
> So what ?
> 
> Projects can select their implementations :
>    If a project specifies project.required.plugins=C, A, it's OK,
>    If a project specifies project.required.plugins=C, B, it's OK too - 
> but with a different behaviour or rendering,

There you go, you just wound up at the Eclipse definition of a Feature.

In other words, I agree. We just need to define the terminology and 
implement the ability to define a feature in forrest.properties. This is 
really easy to do. It can be something like:

feature-def.xml:

<feature id="org.apache.forrest.feature.ODT2PDF">
   <description>Enables the rendering of ODT documents as PDF 
documents</description>
   <version>0.1</version>
   <minForrestVersion>0.8</minForrestVersion>
   <plugins>
     <plugin id="org.apache.forrest.plugin.input.ODT">
       <version>0.1</version>
     </plugin>
     <plugin id="org.apache.forrest.plugin.output.PDF">
       <version>0.2</version>
     </plugin>
   </plugins>
</feature>

forrest.properties:

requried.features=org.apache.forrest.feature.ODT2PDF

Version management just utilises the existing plugin version management. 
However, we could have incompatabilities between plugin versions. For 
example, two features may demand incompatible plugin versions. We will 
need to check this at startup:

1. collect list of all requied plugins
2. look for clashing versions of plugins
3. warn user of potential probelems (if any exist)
4. install latest version of each requirted plugin

Thus if, for example, feature A requires plugin P-0.1 (version 0.1) and 
feature B requires plugin P-0.2 (version 0.2). The user is warned as 
follows:

"Feature A requires plugin P-0.1 whilst feature B requires P-0.2. 
Forrest has installed the latest version (P-0.2). This may couse 
unexpected results in Feature A."

If this looks OK then we should get this into an issue before we forget it.

Ross


Mime
View raw message