I read the post on your blog, but it seems to be a crucial detail missing...
A plugin doesn't usually "need" another plugin itself, it probably "needs" what
the other plugin do.
Maybe a plugin needs to attach something to another plugin menu, or use another
plugin services.
So, for the second plugin to use it, the first plugin must have actually been
initialized, so it have
to be already actually done something.
But if the plugins are required not to do anything in their init phase, how all
this could be resolved???
Anyway a solution can be found, but what it's more interesting in your post is
that you're suggesting
to avoid any configuration file unless absolutely necessary.
This is interesting because any container I know about (like Spring, JBoss
microcontainer, The Eclipse
RCP osgi implementation, PicoContainer, etc.) do use configuration files, so
that dependencies
are known before hand and can be resolved (and for other reasons, too).
Also there may be cases were more instances of a single plugin are to be
created, so we probably need
to give a distinct name to each instance and not to each plugin class as a
whole.
In this case, names can not be hard-coded, beacuse they change with each
instance.
I admit I don't like having to write configuration files, but sometimes they
are unavoidable.
The ideal solution may be something were file-configured plugins, hard-coded
configured plugins
and unconfigured plugins (legacy) may live together in peace and happyness.
We should also give a thought about using a container to do instantion and
configuration. It may be used
"inside" the current plugin instantion code, so that it will be "transparent".
A container will give us robust instantion, configuration, dependencies
management and it may give us
also another tricky thing: multiple class loading (I don't know if the current
instantion system in OJ already has it).
Imagine you have two plugins you want to use and that they both use the same
third-party library (say Batik, for example).
It may happen that one plugin require a newer version of this library and the
other one will instead work _only_
with an older one. With multiple class loading you can make them use their own
preferred library version.
Problem is there should be someone with time and knowledge to do this...
One other interesting possibility could be to create a "plugin container
plugin". A plugin capable of doing
plugin instantion and managing, so the existing plugin instantion code would
stay untouched and loading legacy plugins.
The new loader plugin can be added inside any JUMP flavour and will be capable
of creating other plugins
and made them available like they're "native". It can also manage dependencies
with full power for its own plugins
and with, maybe, reduced possibilities for legacy plugins it doesn't directly
control.
About the action to be taken when a dependency is unresolved, it think it
should be left to the dependant plugin.
There may exist "mandatory" dependencies, that make it impossible for a plugin
to live without.
But there may exist "recommended" dependencies, that would reduce a plugin's
functionalities, but leave it
usable, albeit partially.
I hope all this doesn't sound over-complicated. I like it very much the
simplicity of JUMP and I wouldn't want
to see it disrupted by any means. I'm just reasoning about available
possibilities.
Bye
Paolo Rizzi
-----Messaggio originale-----
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] conto di Sunburned Surveyor
Inviato: venerdì 23 febbraio 2007 3.39
A: List for discussion of JPP development and use.
Oggetto: [JPP-Devel] More thoughts on supporting plug-in dependencies...
I've added some more thoughts about supporting plug-in dependencies to my blog:
http://openjump.blogspot.com/
SS
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
