Hi Landon, Plan "A" seems good, and I like how you wrote it down so clean!!!
It only seems a little too "simple" and I always fear solutions that seems too
"simple"...
But often they prove to be winners in the end!!!
I have one little change and two requirements to suggest for Plan "A".
.) The change. You should add, to the collection of loaded plugins, all the
plugins
not only the ones implementing the new IPlugInDependency interface.
Then, obviously, you'll pass this collection only to the new plugins.
This way older plugins are unaffected, but newer plugins can nonetheless depend
on them.
.) First requirement. New IPlugInDependency plugins should be required to do as
much
as possible inside their initialize() method, apart from "using" other plugins.
This is important to meet next requirement.
.) Second requirement. New IPlugInDependency plugins should be required to be
"ready"
as much as possible after their initialize() method, because other plugins may
try to "use" them.
But even with these two requirements I see something disturbing...
What if a plugin "readiness" depends on having already "used" another plugin???
Suppose you are writing a plugin that depends on another plugin someone else
wrote.
And this plugin depends on another one (but I'm not talking about circular
dependencies, though).
Maybe the plugInsInitializationComplete() method of the first plugin is called
and so it try to "use" the second,
but this second plugin can't "accept" the call, because its
plugInsInitializationComplete() method hasn't
been called yet and it hadn't any chance to "use" the third plugin.
How will Plan "A" cope with that???
Maybe it can be solved by ensuring the plugInsInitializationComplete() method
is always called "before"
any access to a plugin is granted.
Instead of putting inside the collection a direct reference to a plugin
instance, you could put only it's "name".
To access a plugin one has to ask the core for it, using the "name" as a
reference. This way the core can
call the plugInsInitializationComplete() method of the asked-for plugin and
after that it will give it back to the asker.
Obviously the plugInsInitializationComplete() method will be called only once
for each instance.
This way we can, probably, always ensure a complete plugin "readiness".
This doesn't solve circular dependencies, but there's never a solution for
them...
Bye
Paolo Rizzi
P.S: We're talking about plugins, but what about
com.vividsolutions.jump.workbench.plugin.Extension???
Doesn't it play any part in all this???
-----Messaggio originale-----
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] conto di Sunburned Surveyor
Inviato: martedì 27 febbraio 2007 16.36
A: List for discussion of JPP development and use.
Oggetto: [JPP-Devel] Plan "A" For Supporting Plug-In Dependency
I spent an hour or so after work yesterday providing a more in-depth
explanation of how I thought plug-in dependency might be supported in OpenJUMP.
You can read that information on my OpenJUMP blog:
http://openjump.blogspot.com/
I think it would only take me a few hours to implement Plan "A" in OpenJUMP, if
we decide to do that, and I believe it would really add a lot of flexibility
for plug-in developers.
The Sunburned Surveyor
-------------------------------------------------------------------------
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
