Provisioning operations should generally occur using the software updates dialog, or by invoking p2 tools or APIs. However, there are situations where scripts need to install plugins and features via file system operations, and have the new content dynamically discovered by the system either at startup, or while running. To support this kind of low-level manipulation of the system, p2 supports the notion of watched directories. A watched directory is a place where a user or script can drop files and have them discovered by p2. Various policies can be applied to watched directories to configure when they are checked for new content, and whether to eagerly install discovered content.
The Eclipse platform ships with a default watched directory
dropins. The dropins folder is configured to be scanned during
startup. Thus the dropins folder can be used much like the plugins
directory was used in the past. A subtle twist on old behavior here is
that plug-ins and features added to the dropins folder are properly
installed into the system rather than being forced in. This means p2 has
an opportunity to confirm that the new plug-in doesn't conflict with
other installed plug-ins, and it could even go out and fetch any missing
prerequisites of the newly dropped in plug-ins. This also means you can
later use the GUI to install extra functionality that depends on the
plug-ins in the dropins folder, since p2 knows about them and can reason
about their dependencies. In other words, new plug-ins installed via the
dropins folder behave exactly like plug-ins installed via the user
The dropins folder supports a variety of layouts, depending on the scale of your application and the desired degree of separation of its parts. The simplest layout is to just drop plug-ins in either jar or directory format directly into the dropins folder:
eclipse/ dropins/ org.eclipse.core.tools_188.8.131.52710121455.jar org.eclipse.releng.tools_3.3.0.v20070412/ plugin.xml tools.jar ... etc ... ...
You can also drop in the traditional Eclipse application or extension layout directly in the dropins folder:
eclipse/ dropins/ eclipse/ features/ plugins/
If you have various different components being dropped in, and you want to keep them separate, you can add an additional layer of folders immediately below the dropins folder that contain traditional Eclipse extensions:
eclipse/ dropins/ emf/ eclipse/ features/ plugins/ gef/ eclipse/ features/ plugins/ ... etc ...
Finally, you can add link files as in the traditional Eclipse
links folder. The link file format is the same as a
with a key
path pointing to the extension location. If the location is not an
absolute path, then it is considered relative to the Eclipse install directory. The path can
also start with a variable of the form %PROP% which will be replaced with the
Java system property called PROP if defined.
There is also
an optional key named
optional whose boolean value indicates whether or not
the repository is considered optional. A missing optional repository will suppress error messages
from being printed in the log file.
eclipse/ dropins/ emf.link