The dropins folder and supported file layouts

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 called 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 interface.

Supported file layouts

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_1.4.0.200710121455.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 java.util.Properties file 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