Version returned by PluginPrerequisite
Submitted by monochromata on Fri, 04/22/2005 - 17:10.
I'm having problems with the way PluginPrerequisite handles plugin versions. An instance of this class is created at runtime to reflect an import statement in the XML descriptor. PluginPrerequisite provides access to the id and version of the imported plugin.
The problem is, that if no version of the imported plugin is specified in the XML descriptor (of the importing plugin), the version of the importing plugin is used. This works well mostly, but gives an error when e.g. the charva plugin (with a version of 1.0.1) imports the org.jnode.driver.console.core plugin (which has a version of 0.1.11-dev, which is not specified in the import statement).
To solve this problem, a getDefaultVersion() method may be added to PluginPrequisite that returns the version of the importing plugin in case someone wants to use it if no version is given in the import statement. The getPluginVersion() would then return null or an empty string, if no version is specified for the imported plugin.
This will allow the plugin dependency checker to a) try to resolve a plugin with the given version; b) if no version is given, try to resolve a plugin with the default version; or c) try to resolve a plugin without caring about the version.
Thanks.
Sebastian
- Login to post comments
How does plugin loading work at runtime?
I'm currently wondering, if / how plugin loading works at runtime (when Jnode is run). If Jnode uses the same approach that I'm using (e.g. when loading a plugin, look at the PluginPrerequisites and load these required plugins) it should fail from time to time, because sometimes PluginPrerequisite returns a version that is not available (like in the example in the forum topic above).
So my question is: How are plugins loaded by Jnode at runtime? Are versions ignored at runtime or does it fail silently (e.g. there is an error, but no notice is printed to the console)? Does Jnode pay attention to the PluginPrerequisites when loading plugins?
Sebastian
Proposal for now and for later handling of versions
Here is what I propose :
creating an interface Version (or an abstract class) with 3 methods :
- boolean isCompatibleWith(Plugin, Version)
- int compareTo(Object) from the Comparable interface, so it will implements this interface
- String toString()
So, Version implementation can use text, integer, float or whatever the plugin provider want. For now, the default implementation will act as before : on equality of a text representing the version.
Later when it will be needed, we can easily extends the version handling to have constraint like :
- any version from a.b.c
- any version until d.e.f
- any version between g.h.i and k.l.m
- ...
Sebastian, to solve the problem you mentionned, a specific implementation UnspecifiedVersion will always return true in its method isCompatibleWith(Plugin, Version).
Fabien
Proposal for Handling Versions Using Parametric Contracts
Hi Fabien,
We may attach every extension with a "versioning parametric-contract", which can compute the 'current' version of the extension based on the versions of the required extensions, e.g., c depends on A & B:
if A.version >= 1.1 && B.version >= 1.2 (provided by the rt)
then C.version = 1.3
else if A.version >= 1.0 && B.version >= 1.1
then C.version = 1.2
On the other hand:
if require C.version = 1.3
then(we can compute) A.version (must) >= 1.1 && B.version>=1.2
The key is a double-direction surjection function & annotation on each method it's supporting version window.
Comments?
Birkey
Keep it simple
Shouldn't it be a bit simpler? Maybe its just the wording that scares me, but I think it shouldn't normally be more complex than a specification of the minimum versions of all required plugins. If this constraint can't be matched, an error should be printed / an exception should be thrown.
Nonetheless that reminds me that I wanted to test if the plugins that have unmatched dependencies according to the dependency check also don't work at runtime.
Sebastian