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
