Re: [JPP-Devel] Sextante / Cadplan plugins compatibility : the end ?

[Michaël M. <mic...@fr...>]

Hi Ede,
> as i dug into the topic as well already i want to add how i figure we should tackle the issue.
You're welcome,
> 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. 
Currently, we have
/lib/* for application library and
/lib/ext/** (with subfolders) for extension
I don't think you can say cause is here or there, we just need to make 
loading mechanism and ressource hierarchy consistent.
Changing folder hierarchy seemed for more easy to me, but we can discuss 
which is better for a maintenance and long term vision.

>> 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:
Most of Sextante loading mechanism is in Sextante, not in Sextante 
bindings, which makes things less confortable.
> for sextante
> - scan only *.jar/*.zip files within a dedicated lib/ext/sextante subfolder
Would be nice, but not sure it is easy (if possible) from the bindings 
jar...
> - 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.
I don't understand what you want to achieve with this
> - 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.
Currently, Sextante does, but as we see, this may not be a good idea.
I think that having Sextante in a subfolder made things clearer, but 
you're right, each plugin should be responsible to load their 
dependencies from their subfolder, not all from all with a recursive scan.
> - 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.
Seems a good idea,
> for the future (just brainstorming here)
> - when this is done we should look into a live download/install/en-/disable plugin manager functionality
Eric started to work on this topic,
> - 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.
Agree, we just should make a repository with a url included in the 
plugin manager from where users can discover "official" plugins.

Michaël
> - 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
> Jum...@li...
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>