Dear Wiki user, You have subscribed to a wiki page or wiki category on "Nutch Wiki" for change notification.
The "WhichTechnicalConceptsAreBehindTheNutchPluginSystem" page has been changed by LewisJohnMcgibbney: http://wiki.apache.org/nutch/WhichTechnicalConceptsAreBehindTheNutchPluginSystem?action=diff&rev1=3&rev2=4 - -- StefanGroschupf - 06 Oct 2004 - ''This text explains a set of concepts involved in the nutch plugin system as a kind of vocabulary definition.'' As usual in a vocabulary definition, we differ between "should have", "must have" and "can have". == Extension point == - A extension point is a plug that can be extended by third party functionality. Seen as publisher - listener pattern the extension point is a publisher. A extension point must have a definition of the counterpart male connector in form of a java interface. As java doc comments the interface should document what kind of data the two parts will exchange. The interface name should start with a capital I e.g ''IMyExtensionPoint'' (''note: this isn't the case in Nutch 0.5. Does it describe future plans or wishful thinking, Stefan?''). It must be documented if the extension point need 1 or 0...n corresponding enhancements. The extension point implementation must implement a handling of exceptions that can be thrown by the third party counterpart male connectors. + A extension point is a plug that can be extended by third party functionality. Seen as publisher - listener pattern the extension point is a publisher. A extension point must have a definition of the counterpart male connector in form of a java interface. As java doc comments the interface should document what kind of data the two parts will exchange. The interface name should start with a capital '''I''' e.g ''IMyExtensionPoint'' . It must be documented if the extension point need 1 or 0...n corresponding enhancements. The extension point implementation must implement a handling of exceptions that can be thrown by the third party counterpart male connectors. == Extension == @@ -20, +18 @@ == Plugin class == - A plugin can have a plugin class specified in the plugin manifest file. A plugin class extends the ''net.nutch.plugin.Plugin'' class and can override the startUp and shutDown methods. Lifecycle-relevant interactions - like database connections - should be handled in these methods. Until Nutch runtime, only one instance of such a plugin class is alive in the Java virtual machine. None of the plugins included in Nutch 0.5 have plugin classes. + A plugin can have a plugin class specified in the plugin manifest file. A plugin class extends the ''org.apache.nutch.plugin.Plugin'' class and can override the startUp and shutDown methods. Lifecycle-relevant interactions - like database connections - should be handled in these methods. Until Nutch runtime, only one instance of such a plugin class is alive in the Java virtual machine. == Plugin manifest == - Each plugin must have a manifest file. The plugin manifest file is an XML file that contains a set of relevant metadata that describe the content of a plugin in machine-readable form. Besides the information on which extension corresponds to which extension points, it contains information about an optional plugin class and jar libraries which are required. Furthermore, it describes dependencies on other plugins. + Each plugin must have a manifest (plugin.xml) file. The plugin manifest file is an XML file that contains a set of relevant metadata that describe the content of a plugin in machine-readable form. Besides the information on which extension corresponds to which extension points, it contains information about an optional plugin class and jar libraries which are required. Furthermore, it describes dependencies on other plugins. + + == Plugin Dependency Management with Ivy == + + Each plugin must also maintain it's own ivy.xml file including all third party libraries required to run the plugin when it is loaded into the plugin system. == Plugin repository ==
