Hi,
I tested a bit more the last version of OJ. I found a small bug and some
improvements to possibly do.
Bug: the export in SVG works well for small datasets but doesn't work for
important ones (creation of a kind of strange noisy image
but not in a SVG format, except for the file extension). If it's just an
extract of the important dataset, the export is done without
any problem. I was able to reproduce this problem with more than one layer.
Possible improvements:
- improve the output layer name of the AttributeQuery
plugIn
(com.vividsolutions.jump.workbench.ui.plugin.analysis.AttributeQueryPlugIn);
at the moment, the name is something like it NAMELAYER-operator, e.g.
buildings-=, resulting from the following code : String outputLayerName =
LayerNameGenerator.generateOperationOnLayerName(funcNameToRun,
srcLayer.getName());
It could be improved by using the following
pattern: NAMELAYER-ATTRIBUTENAME_operator_VALUE
- when the window of Sextante is opened, it is impossible to interact with
a OJ project. Therefore, it isn't easy to see quickly the result.
It could be nice to be able to switch between Sextante and OJ (I hadn't
time to find where the code could be improved: sorry to just
propose it like it).
- 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.
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,
- 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
