Re: [JPP-Devel] R: Plan "A" For Supporting Plug-In Dependency

[Sunburned S. <sun...@gm...>]

Paolo,

Thank you for both of your comments. I will consider them carefully before
moving on with any work on the plug-in dependency system.

Landon


On 2/27/07, P.Rizzi Ag.Mobilit=E0 Ambiente <pao...@am...> wrote:
>
>  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 seem=
s
> 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 t=
o
> be "ready"
> as much as possible after their initialize() method, because other plugin=
s
> 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 circula=
r
> 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 plugInsInitia=
lizationComplete()
> 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 fo=
r
> 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:* jum...@li... [mailto:
> jum...@li...]*Per conto di *Sunburned
> Surveyor
> *Inviato:* marted=EC 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 lo=
t
> 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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Jump-pilot-devel mailing list
> Jum...@li...
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>