Scott Green wrote:
Hi Sami
On 1/16/07, Sami Siren <[EMAIL PROTECTED]> wrote:
Scott Green wrote:
> Thanks Dennis! Your methond should work.
>
> And I really hope there is one directly method say getPluginRootDir()
> in the plugin implementation.
I'd recommend taking path shown by Andrzej because IMO it's bad design
to depend on plugin system from a plugin.
I am not much clear about your reason.
The getPluginRootDir() method mentioned above should expose the
(absolutely) path of xxx-plugin in the below example.
plugins
`-xxx-plugin
`------ lib
`------ conf
`------ src
`------ web (only for web plugin)
`------ plugin.xml
`------ build.xml
Ok. Now imagine that all plugins are packed together in a Jar file (as
is the case with Nutch). Is your method still going to work? Nope.
getPluginRootDir() may still return some non-null value (not sure about
that), but the resources are not available as files because they are
packed into a Jar.
Now, you may have tested your method and found that it does indeed work
- but the reason is a bit obscure: the bin/nutch and bin/hadoop scripts
add your build/ directory to the classpath, so that you can locally test
the latest versions of the code without creating the *.job file.
However, when you run your code on a Hadoop cluster your local build/
directory is no longer accessible, and your method will mysteriously
fail - or even worse, you may get a different version of a resource from
an older version of the build/ directory found on Hadoop tasktracker
nodes ...
Andrzej's idea is limited(?) since i cannot get resources from conf dir.
Absolutely not - that's how the whole Configuration system works.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
