Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)

[Ross Gardler <rg...@apache.org>]

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

Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)

[Ross Gardler <rg...@apache.org>]

Ferdinand Soethe wrote:
> Ross Gardler wrote:
> 
> 
>>Just to be clear. The reason we decided (in the past) not to allow
>>plugins to have dependencies in this way is because it requires the user
>>to have a deep understanding of what plugins work with what other 
>>plugins. Even worse, they need to know which versions of plugins will 
>>play happily.
> 
> 
>>By requiring the user to know this we will end up with user support 
>>questions, which in turn will result in us having to maintain 
>>documentation, which in turn will get out of synch with the reality of
>>development, which will result in more user confusion.
> 
> 
>>So, my proposal is to document what plays with what in a feature 
>>definition file as described in the previous email. We can generate 
>>documentation from this file and it removes the need for the user to 
>>worry about version numbers of plugins.
> 
> 
> This was really helpful because if made me go back and re-read you
> previous posting and really understand features.
> 
> +1 for the concept
> 
> How about naming them in a way that explains better what they are.
> Something like compound-plugin for example?

I really have no problem with any name. Features can be a little 
misleading and did confuse me for a while in the Eclipse environment.

Ross

Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)

[Ferdinand Soethe <fe...@apache.org>]

Ross Gardler wrote:

> Just to be clear. The reason we decided (in the past) not to allow
> plugins to have dependencies in this way is because it requires the user
> to have a deep understanding of what plugins work with what other 
> plugins. Even worse, they need to know which versions of plugins will 
> play happily.

> By requiring the user to know this we will end up with user support 
> questions, which in turn will result in us having to maintain 
> documentation, which in turn will get out of synch with the reality of
> development, which will result in more user confusion.

> So, my proposal is to document what plays with what in a feature 
> definition file as described in the previous email. We can generate 
> documentation from this file and it removes the need for the user to 
> worry about version numbers of plugins.

This was really helpful because if made me go back and re-read you
previous posting and really understand features.

+1 for the concept

How about naming them in a way that explains better what they are.
Something like compound-plugin for example?


--
Ferdinand Soethe

Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)

[Cyriaque Dupoirieux <Cy...@pcotech.fr>]

le 04/05/2006 16:24 Ross Gardler a écrit :
> Ross Gardler wrote:
>> Cyriaque Dupoirieux wrote:
>
> ...
>
>>> 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.
>
> Just to be clear. The reason we decided (in the past) not to allow 
> plugins to have dependencies in this way is because it requires the 
> user to have a deep understanding of what plugins work with what other 
> plugins. Even worse, they need to know which versions of plugins will 
> play happily.
>
> By requiring the user to know this we will end up with user support 
> questions, which in turn will result in us having to maintain 
> documentation, which in turn will get out of synch with the reality of 
> development, which will result in more user confusion.
>
> So, my proposal is to document what plays with what in a feature 
> definition file as described in the previous email. We can generate 
> documentation from this file and it removes the need for the user to 
> worry about version numbers of plugins.
Ok, I fully agree.
It's a very nice solution :-) .

Cyriaque,

PS : I wanted to see how rpm packages manage dependencies, but I have 
not the time... I think it must be close to your solution...


>
> Ross
>
>

Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)

[Ross Gardler <rg...@apache.org>]

Ross Gardler wrote:
> Cyriaque Dupoirieux wrote:

...

>> 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.

Just to be clear. The reason we decided (in the past) not to allow 
plugins to have dependencies in this way is because it requires the user 
to have a deep understanding of what plugins work with what other 
plugins. Even worse, they need to know which versions of plugins will 
play happily.

By requiring the user to know this we will end up with user support 
questions, which in turn will result in us having to maintain 
documentation, which in turn will get out of synch with the reality of 
development, which will result in more user confusion.

So, my proposal is to document what plays with what in a feature 
definition file as described in the previous email. We can generate 
documentation from this file and it removes the need for the user to 
worry about version numbers of plugins.

Ross