> This is a typical use case for nutch plugins and go a step back to > configuration file based dynamic class-loading makes from my point of > view less sense. > Now after most things was ported to plugins using > AnalyzerMap.properties isn't in the style the rest of nutch is > implemented.
Stefan, I clearly understand your meaning. Yes, this proposal breaks the actual plugin architecture. I must acknowledge that I do not know very well the possibilities of the plugin system. Particularly, I don't find any documentation on the plugin.xml file format, and the plugin capabilities. Typically, in the multi-lingual proposal, all the language specific analyzers must have a dependency on the LanguageIdentifierPlugin (it must be called first). How can I specify that? I took a look at the official nutch wiki and on your corporate Wiki but I don't find any documentation on the plugin system capabilities... Do you have any pointer? Otherwise, I will take a look in the code. Regards Jerome -- http://motrech.free.fr/ http://frutch.free.fr/
