Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
If a plugin Y has an optional dependency on X, and X is unloaded, then Y should also be unloaded.
Later, if Y is activated, and then X should be activated first.
Activator and Reloader should also behave consistently to this.
This is related to https://sourceforge.net/tracker/index.php?func=detail&aid=3614465&group_id=588&atid=350588, so I'll take care of the unloading part at the same time as the other tracker.
Activator adjustments should probably be a separate ticket.
Fixed in revision 23051 in jEdit. I didn't do anything with Activator.
I think it would have been better to fix plugins, only a few of them use optional dependencies don't you think ?
How would you fix the plugins? This appears to be a classloader issue, so I'm not sure what you would fix in the plugins?
I think this is only half of the solution -- for example, TaskList has an optional dependency on ProjectViewer. If PV is unloaded, there is no reason for TaskList to also be unloaded. It should be reloaded so that the classloaders are cleaned up. Later, if PV is activated, then TaskList should be reloaded to keep the classloaders straight.
Reopening this since we're still discussing solutions.
Eric Le Lay
I'm in favor of changing core and force-reloading dependent plugins (what has been implemented by Dale), because:
- (practical) it makes the program more robust, when dependents forget to remove so random reference deep down in their code
- (personal preference) it is the duty of core to implement the dependencies and the duty of the plugins to declare the dependencies
Just an update, I have the loading/reloading working well on my local and I believe this is what we are all looking for. As an example, suppose ProjectViewer and Lucene are both loaded when jEdit starts. Lucene has an optional dependency on PV. The user decides to unload PV. In this case, both PV and Lucene are unloaded, then Lucene is reloaded, so Lucene continues to work as expected. Next the user decides to load PV, goes to Plugin Manager, and checks the box for PV. PV is loaded, Plugin Manager checks installed plugins and reloads those with an optional dependency on PV, in this example, Lucene is reloaded. Now both PV and Lucene work as expected.
What's left to do is to check for dependent plugins and ask if they should also be loaded, so expanding the example, ProjectViewer and SVN are both loaded when jEdit starts. SVN has a hard dependency on PV. The user decides to unload PV, and SVN is also unloaded. Next the user decides to load PV. SVN is still installed, so Plugin Manager will ask if SVN should also be loaded.
But if a plugin receive a PluginUpdate.UNLOAD message on an optional dependency it can remove listeners and things related with that optional dependency.
Fixed in revision 23056. This work is in conjunction with work for 3614465, which shows plugin dependency details in the plugin manager details panel. The fix is better than requested -- if a plugin Y has an optional dependency on X and X is unloaded, then Y is reloaded. Later, if X is loaded again, then Y will be reloaded again.
Matthieu, cleaning up on the UNLOAD messages is a good thing, but it turns out it's not sufficient. The classes end up in different classloaders, so in the PV/Lucene example I gave below, if both are loaded, then PV is unloaded then reloaded, Lucene needs to be reloaded so PV can find the Lucene classes. If PV is never reloaded, then just having Lucene react to the UNLOAD message is probably enough, but actually reloading Lucene ensures the classloaders stay clean and cooperate.