Larry,
Thank you for your comments. I want to respond, but please remember I'm not
trying to be argumentative. I want to encourage this discussion so we can
consdier all sides of the issue at hand. I always value your input.
Larry wrote: "Plugins are hard enough to write. I don't think we should add
any additional requirements."
Good point. However, I think this depends on your perspective. In the system
I suggested the developer will have to implement an additional method. In
your suggested system the developer will have to learn the format of
"dependecy file" and will have to write and maintain that file. (If you
think about it, the dependencies for a plugin shouldn't be changing that
much, if ever. That means that this information is easily hardcoded into the
plugin code. I usually think of text files being more useful for information
that will change frequently with use.)
Also remember that the developer doesn't have to implement the
plugInsInitializationCompleted() method. They can leave it as a stub if they
don't want their plug-in to participate in the plug-in dependency system. If
this were a real stikcing point we could move the method to a separate
interface, the "DependencySupport" interface, as an example. Then developers
that wanted to have their plug-in participate in the system could simply
implement the additional interface.
Larry wrote: "Besides, you method does nothing for all
existing plugins unless they are rewritten."
This is a downfall of the system I suggested. Thank you for pointing it out.
However, if we use the system in which the DependencySupport interface
encapsulates the added funcitonality, you could "port" existing plug-ins by
creating a wrapper that implementing the interface. I must admit this is
quite a bit more work that just adding an XML file.
Larry wrote: " The plugin loading code in the core
can then be modified to load the X<: file, use reflection to determine
if the dependent classes are available, log an appropriate error
message, and refuse to load the plugin if the dependencies are not
present."
I had thought about this when considering the ways we could support plug-in
dependency. I decided to leave the appropriate response to an unmet
dependency up to the plug-in developer. In the suggested system that uses an
XML configuration file OpenJUMP decides what to do when a dependency isn't
met. This forces plug-ins to follow something of an "all or nothing" policy.
If I can, as a plug-in developer, program my response to unmet dependencies
in the plugInsInitializationCompleted() method, then I can choose how to
respond. For example, I might only disable some of the funcitonality of the
plug-in, but not completely disable it. I might choose which functions to
disable based on which of the dependencies were not met. I could also
customize my error message to indicate which plug-ins were missing and
explain what effect this would have on my plug-ins functionality.
I'd like to know what you think about this, and I'd really like to hear from
the other developers as well. I know each system will have its advatages and
disadvantages.
The Sunburned Surveyor
On 2/23/07, Larry Becker <[EMAIL PROTECTED]> wrote:
Hi Sunburned,
Plugins are hard enough to write. I don't think we should add
additional requirements. Besides, you method does nothing for all
existing plugins unless they are rewritten. Another solution is to
simply have an XML file be present for each plugin that lists the
major classes that it depends on. The plugin loading code in the core
can then be modified to load the X<: file, use reflection to determine
if the dependent classes are available, log an appropriate error
message, and refuse to load the plugin if the dependencies are not
present. We can either make the XML file optional since simple
plugins don't usually have extra dependencies outside the normal
libraries.
regards,
Larry
On 2/22/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> 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
>
>
--
http://amusingprogrammer.blogspot.com/
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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
