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.
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.
- 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,
- 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.
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.
Michaël
- maybe to store the extensions in another repository than lib/ext,
maybe lib/plugins
- a dynamic JAR loaded system, which can be based simply on Java
library or on OSGI for example,
- a xml file to store the user preferences,
- a new plugin which will be loaded by default, reading the xml file
and initialising the plugins defined by the user,
- and then a class to enable the downloading of new plugin and an
interface to manage a possible proxy.
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:
<plugins>
<plugin>
<name>plugin_one.jar</name>
<description>blablabla blablabla</description>
<dependencies>
<dependency>dependency_one.jar</dependency>
<dependency>dependency_two.jar</dependency>
</dependencies>
<version>1.0</version>
</plugin>
</plugins>
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).
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.
What do you think about it? Could it do the trick for you?
Cheers,
Eric
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
