as i dug into the topic as well already i want to add how i figure we should
tackle the issue.
On 30.04.2012 08:19, Michaël Michaud wrote:
>> Another option might be to reserve a folder name (say ext/plugins) that is
>> excluded from the Sextant search. Each plugin can then have a suitably
>> named sub-folder to contain whatever data is available to the average user
>> (images, symbols, etc).
> My proposition was to create this folder (currently FillPatterns folder)
> beside ext folder and not inside (ex. lib/resources/FillPatterns/), because
> OpenJUMP plugin manager does a recursive scan of the ext plugin folder (which
> is convenient for plugins wich have many dependencies like Sextante).
first and foremost, let's keep the simple structure we have. /lib/ext for
additional extensions and /lib for application libraries or data used by core.
moving folders out of /lib/ext treats symptoms (sometimes easy, right) but does
not solve the root cause, which lays within the loading routines of
PluginManager and Sextante Extension.
> It would probably be possible to exclude FillPatterns folder from Sextante
> search, but it seems more difficult to me because I think Sextante uses the
> same mechanism as any plugin, i.e. the one which recursively scans the ext
> folder and its subfolders. Indeed, sextante loading mechanism is quite
> complex, and I only could prove it scans FillPatterns from tests, not from
> the source code :-(
let me have a look, now the source is in our svn. my current vision would be:
for sextante
- scan only *.jar/*.zip files within a dedicated lib/ext/sextante subfolder
- cache the results of scanning within state.xml if the performance boost of
the above is not enough. save name, size and time attributes and rescan if one
of them changed.
- check speed over a network share as loading from local disks is already fast
enough on current hardware
for PluginManager (general loading)
- although the design allowed placing extension jars into lib/ext/subfolders, i
don't know of extensions that do that and i'd like to retire this.
- only scan lib/ext/*.{zip,jar} for performance reasons, exclude subfolders
- cache the result of scan in state xml, similar as stated above
- add custom classloader that automatically adds a folder and it's contents if
the name matches the *.jar name e.g. sextante-0.6.jar would add
lib/ext/sextante-0.6 if existing. i'd reuse the classloader i already have for
the cts extension, which is a nifty littly thing that actually searches the
parent classloader /after/ the custom entries so that different extensions
actually are able to use different versions of the same library.
for the future (just brainstorming here)
- when this is done we should look into a live download/install/en-/disable
plugin manager functionality
- for this i am opposed to central xml files, that have to be maintained but
rather have extensions deliver this kind of information, so that authors keep
them up to date.
- we would have to track installed files for uninstallation *or* put the
extensions in private folders altogether
..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
