![]() | Structure of a plugin package |
| Prev | Share your work with others | Next |
For external plugins to install and work properly, they must follow some structural guidelines regarding their file hierarchy.
Lets have a look at the prototypic file hierarchy of an elaborate plugin archive. You don’t have to include all of these directories and/or files for a plugin to work (read on to learn what’s absolutely necessary), consider this a “best practice” example:
plugin_name/ inst/ rkward/ plugins/ plugin_name.xml plugin_name.js plugin_name.rkh ... tests/ testsuite_name/ RKTestStandards.sometest_name.rkcommands.R RKTestStandards.sometest_name.rkout ... testsuite.R plugin_name.pluginmap ... ChangeLog README AUTHORS LICENSE DESCRIPTION
In this example, all occasions of plugin_name, testsuite_name and sometest_name are to be replaced with their correct names, accordingly.
You don't have to create this file hierarchy by hand. If you use the function rk.plugin.skeleton() from the rkwarddev package, it will automatically create all necessary files and directories for you.
It is mandatory to include at least three files: a .pluginmap, a plugin .xml description and a plugin .js file. That is, even the "plugins" directory is optional. It might just help to give your files some order, especially if you include more that one plugin/dialog in the archive, which is of course no problem. You can have as many directories for the actual plugin files as you see fit, they just have to resemble the .pluginmap, respectively. It is also possible to even include several .pluginmap files, if it fits your needs, but you should include them all in “plugin_name.pluginmap” then.
Each R package must have a valid DESCRIPTION file, which is also crucial for RKWard