Question: i thought if i want to use a plugin missing some classes it will result in an error and the system will either hang up or just do nothing (rather the latter). So what is the point? The person needs simply to remove the plugin. Apart from this, I included in the template for plugin descriptions, I had done, a point listing necessary libraries.. and every developer who wants to have his plugin distributed will add this info (at least in a readme.txt file)
so i do not see a need for adding something which checks external plugins for dependencies stefan Sunburned Surveyor schrieb: > 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] > <mailto:[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] > <mailto:[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 > > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > <mailto: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 > > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > <mailto: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 ------------------------------------------------------------------------- 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
