On 29.04.2012 20:03, Michaël Michaud wrote: > Hi Eric, Ede, >> - the last improvement is about the OJ-PLUS startup. As you mentioned in >> some previous email, the OJ-PLUS is quite slow. >> I was a bit curious so I decided to have a look to understand the reason. >> Here it is (time results based on my laptop configuration, >> i.e. Ubuntu 32-bits 4Go): >> -- normal launching time of OJ-PLUS: 15 seconds >> -- the big change from the previous version was Sextante. So I decided to >> have a look to Sextante. Its initialisation is not in >> the "execute" method but in the "initialise" one. So I moved a part of the >> code from the initialisation to the execution >> and compiled the sextante binding. This change involves other small changes >> for the other Sextante plugins (i.e. automatic >> creation of History, Modeler and Results plugins in the menu) but it >> shouldn't be difficult to manage. Sextante can be initialised >> (in nearly 7-8 seconds) and launched via the menu or the button without >> problem. But the question is, what is the new startup time? >> 7 seconds. Comparatively to the 4 seconds of the OJ-CORE startup, it sounds >> not too bad. > The main problem was really the FillPatterns folder. Without it, full > OpenJUMP PLUS-version > starts in 8 s on my windows vista box. IMHO, as far as startup time is > concerned, we can live like that > and the needed change to avoid the conflict between Sextante and Cadplan > could be made before 1.5.2 release.
the real world issue is people using oj over network here. i had local loading times for PLUS between 10s and 60s which is not perfect but usable. i will check your changes against my slow file server ;)... and come back with times > That said, having a plugin manager able to upload dynamically plugins from a > jar or from a URL would be the ideal. > I'm very enthousiast with this idea that we already discussed a bit on the > list. > Don't forget : > - to have a look at our old plugin manager () > http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/plug-ins/ExtensionManagerPlugin/distrib/ > - to check if we want to follow kosmo solution (did not try it yet) or to > have our own. i'd especially like to checkout the kosmo solution for reusability, as they obviously implemented it very user friendly. hadn't had time to check it in a build from source so far. > - to have a look on the list archive where Ede wrote some limitations of the > current plugin manager > > Other interesting existing solutions : > - jEdit plugin system see > http://www.jedit.org/users-guide/plugin-implement.html > - http://jpf.sourceforge.net/about.html > - http://code.google.com/p/jspf/ > >> >> But maybe it is possible to go further? That's why I decided to test the >> lazy loading that Michaël proposed the other day in your >> "startup of PLUS" discussion and I think OJ has everything we need to do >> what you all proposed. >> First, I created a plugin which allows to create dynamically a new plugin >> following this simple structure: >> - a classical definition: CreationOfPluginPlugin extends AbstractPlugIn >> implements ThreadedPlugIn >> - classical initialisation, >> - add an ok button to launch it via the MultiInputDialog interface, >> - and here is the run method: >> public void run(TaskMonitor monitor, PlugInContext context) { >> new TestPlugin().initialize(context); >> context.getWorkbenchFrame().invalidate(); >> context.getWorkbenchFrame().validate(); >> } >> >> I used the invalidate and validate methods to allow the refresh of the >> workbench in order to see the new menu of the plugin. >> It is unnecessary if the menu title of the new plugin already exists (but >> it's safer to use it as it works in every cases). >> So if we can do it, what do we need more: >> - an interface to do the same thing than in Kosmo: it shouldn't be very >> difficult to do it, as Kosmo is a direct descendant from JUMP i expect they already do it similar to you approach >> - remove the Extension classes of the different plugins to avoid their >> dynamic loading during the startup, > I think Extension can still exist. It can define a single plugin or a set of > consistent plugins. I think it It should > be the entry point for the plugin manager, but should not be loaded by > default. i really like the dropin and run plugin functionality. i'd rather keep it and extend PluginManager to black/whitelist plugins a user does(not) want to load. > If the user choose to upload it the configure method is run. His choice > should be persisted in a configuration file > (workbench-state) so that it can be uploaded automatically the next time. agreed. >> - maybe to store the extensions in another repository than lib/ext, maybe >> lib/plugins disagreed. lib/ext is our current lib/plugins and should simply be managed by PluginManager in the future >> - a dynamic JAR loaded system, which can be based simply on Java library or >> on OSGI for example, can you give an example? >> - a xml file to store the user preferences, exists. workbench-state.xml >> - a new plugin which will be loaded by default, reading the xml file and >> initialising the plugins defined by the user, disagreed. except we want to play safe and establish a second generation PluginManager which runs in parallel until it's stable and can substitute the old one. >> - and then a class to enable the downloading of new plugin and an interface >> to manage a possible proxy. we should simply take over the proxy settings dialog from kosmo which actually set's the jvm proxy setting. >> >> Technically, everything is not too difficult except the last point. Indeed, >> what mechanism use to store the information >> about the plugins? In a first time, we could centralise the plugins, e.g. on >> the OJ sourceforge website, involving that >> we could define a unique xml file to centralise the information and as >> follows: SNIP we had a similar approach, http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/plug-ins/ExtensionManagerPlugin/distrib/ but actually i oppose to a central maintained repository where the extensions are not developed in oj svn. for "our" extensions i actually see no problem as we can easily fix and mod them to fit the download approach's demands. >> Thus we could download this file in OJ, do the differential with the >> existing local plugins (maybe using a md5 key >> which will allow to check if a plugin exist or not and to know if the file >> has been download correctly). i could imagine a cron driven, build repository index here at least for "our" extensions. but let's evaluate how other's namely Kosmo and Jedit do it first. >> >> To go further, we could authorise also other URL for the plugin with the >> same centralise XML system. >> Then think about a more flexible system to allow the upload by developers of >> a plugin with its XML file description. this would have to be moderated and i currently see no capacity let alone someone consistently offering time for this. >> >> What do you think about it? Could it do the trick for you? it is quite a project and i'd rather go slow and mindful than having a one shot like the first trial mentioned above which is mainly a proof of concept but not up to a users/developers expectation. ..ede ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
