support optional plugin dependencies #266
Under certain situations it might be very helpful to support optional dependencies between plugins. For example the following scenario is currently pretty difficult to realize with pf4j:
One plugin adds contact management and the other plugin adds calendar functionality to an application. Both plugins provide a form to modify contacts / calendar entries, that can be extended by other plugins through the
Let's assume, that the contacts plugin adds a panel to the calendar form, that shows assigned contacts for a certain calendar entry. On the other hand the calendar plugin adds a panel to the contacts form, that shows assigned calendar entries for a certain contact.
In this case, both plugins would depend on each other. I would have to define these dependencies in their
But what happens, if one of the plugins is missing, because the application user might not have installed it? - Currently pf4j wouldn't load the contacts plugin, if the calendar plugin is missing and vice versa (due to the defined dependencies in
With the current version of pf4j I only see one solution for this problem. I would have to remove the dependencies between the plugins and have to create a separate plugin, that provides the
This might be an acceptable solution for small application. But if we think a little bit bigger, this approach might lead to a huge number of plugins only to reflect those inner plugin dependencies.
I hope my math is right. ;) - But even if the formula is wrong, it should show, that this possible workaround can lead to a big mess on more complex applications with a bigger number of plugins.
But how did others solve this problem? - For example JPF solved this problem by allowing optional plugin dependencies. I think, this would also be the most elegant solution for pf4j.
According to the example above: The contacts plugin could define an optional dependency to the calendar plugin (and vice versa). If the calendar plugin is not present, the contacts plugin is still available for the application - only the
What do you think about all this? - Do you also see this as a problem or am I missing something?
From my point of view the suggested feature would be a big improvement for pf4j, that could also be helpful for others. I'm currently implementing these optional dependencies. There is still some testing and fixing to do, therefore I can't provide source code yet. But are you generally interested in a pull request for this feature?
If not, I would have to fork the project and maintain the modified source code for myself because my application heavily relies on this. I'm hoping to get a positive response, because I would rather support your project instead of forking and maintaining it for myself.
The text was updated successfully, but these errors were encountered:
The feature seems to be valuable, so we can add it.
Maybe is necessary extra work, we can discuss.
Thanks for your quick and positive response.
I was thinking the same and already did that in my local / testing implementation. But currently I put the question mark behind the plugin name instead of the version number, like
But if you prefer
I will change my implementation accordingly.
I also did that in my local / testing implementation.
The modifications are basically working quite well within my application. But there are still some class loading issues to solve.
According to my example above, there is currently a
I think that is a detail where to put
But out of curiosity I took a look into the documentation of IntelliJ, Netbeans & OSGi about how they are approaching this issue:
According to this XML configuration plugins can have optional dependencies on each other:
<idea-plugin url="http://www.jetbrains.com/idea"> <name>VssIntegration</name> <id>VssIntegration</id> <description>Vss integration plugin</description> <change-notes>Initial release of the plugin.</change-notes> <version>1.0</version> <vendor url="http://www.jetbrains.com" email="email@example.com" /> <!-- The unique identifiers of the plugins on which this plugin depends. --> <depends>MyFirstPlugin</depends> <!-- Optional dependency on another plugin. If the plugin with the "MySecondPlugin" ID is installed, the contents of mysecondplugin.xml (the format of this file conforms to the format of plugin.xml) will be loaded. --> <depends optional="true" config-file="mysecondplugin.xml">MySecondPlugin</depends> <!-- ... some more stuff ... --> </idea-plugin>
Also an extension may explicitly define, on which other plugin it depends:
<idea-plugin url="http://www.jetbrains.com/idea"> <!-- ... some more stuff ... --> <!-- Declare extensions to access extension points in the IntelliJ Platform. --> <extensions defaultExtensionNs="com.intellij"> <appStarter implementation="MyTestPackage.MyTestExtension1" /> <applicationConfigurable implementation="MyTestPackage.MyTestExtension2" /> </extensions> <!-- Declare extensions to access extension points in a custom plugin --> <extensions defaultExtensionNs="MyPluginID"> <MyExtensionPoint1 key="keyValue" implementationClass="MyTestPackage.MyClassImpl"></MyExtensionPoint1> </extensions> <!-- ... some more stuff ... --> </idea-plugin>
It looks to me, that IntelliJ goes similar ways like JPF or as it is proposed in my pull request.
It seems, that the Netbeans module framework does not support optional plugin dependencies. According to their documentation, they are solving this issue by separate plugins to reflect inner plugin dependencies:
This approach leads to the problems, I've pointed out earlier:
Therefore I don't really like the Netbeans approach to this problem. But maybe I've missed something...
OSGi / Eclipse
As far as I know, the Eclipse plugin framework is more or less based on OSGi. Therefore I'm looking at OSGi instead.
According to this tutorial optional plugin dependencies are support by OSGi:
OSGi is quite complex and I did not fully understand all of their concepts. But it looks to me, that it also provides solutions to check plugin requirements of certain extension - e.g. with a custom
As far as I understand, OSGi also wouldn't force the developer to create separate plugins to reflect inner plugin dependencies (like Netbeans or PF4J currently does).
My personal conclusion about this: Two of three comparable solutions to PF4J are addressing optional plugin dependencies. I guess those requirements are not as rare, as one might think. ;)
I'll send you some pull requests for the pf4j.github.io repository in the next one or two weeks. Currently I'm quite busy with the migration of my application to Java 11. Therefore documentation may take some time.
That's good to know. Do you have any plans about a new release in the next few weeks? - Or do you prefer to wait until the documentation was updated?
It would be nice to have a minimum documentation (maybe copy/paste from PR) until you have time to add a more complete documentation.
You should find a pull request with the some additions to the manual.
I've still not released my application with the modifications on PF4J to the public. I guess it will take 1-2 weeks until the changes can be tested on a wider user base. But up to know I did not find any problems during my local tests.
Thank you for being open about my proposals. I appreciate the effort you've put into PF4J and that my pull requests are critically questioned. From my point of view PF4J is well designed, easy to learn and deserves more attention. It's a great and straightforward alternative to bloated solutions like OSGI. Keep up the great work!
With the last changes PF4J is more or less feature complete for my personal use case. Therefore I guess you won't get any bigger proposals by me in the future. But of course I'll continue to look out for bugs and possible bugfixes. ;)
Thank you for your contribution and for your patience!
PF4J is a community driven project so if anybody has a great idea (easy or difficult to implement) I will accept that idea with pleasure.