<folder> Element
The <folder> element is a child of the <memberList> element and is used to declare a folder to be referenced by the plug-in.
A plug-in can specify a folder to be created in the form of a full path name. For example, /a/b/c. In this example, a and b are interior folders, and c is a leaf folder. The plug-in owns the leaf folder. The admin group is listed as the folder owner group, and the folder is identified as being owned by the plug-in. A plug-in may only create components and plans in a folder that it owns. Users cannot create components, plans or subfolders in a plug-in owned folder.
If an interior folder does not exist when a plug-in is loaded, it is implicitly created. Interior folders may not be owned by a plug-in. The owner group for a plug-in created interior folder is the admin group, but the folder is not identified as belonging to any plug-in. If a plug-in author intends for interior folders to be explicitly owned by a plug-in, the folders should be created individually. In the above example, folder /a would be created first, followed by folder /a/b, then folder /a/b/c.
Unowned interior folders may not be created under an owned interior folder. This requirement prevents plug-in authors from creating components and plans in a folder between owned folders in the folder hierarchy, which would complicate the deletion semantics.
If an interior folder exists and is unowned when a plug-in is loaded, the interior folder is used directly. If an interior folder exists and is owned by a plug-in, the interior folder must be owned either by the current plug-in or by a plug-in on which the current plug-in has a direct dependency. This requirement enables multiple cooperative plug-ins to be distributed separately by a plug-in vendor. By obeying Java package style naming conventions when creating folders, vendors can avoid folder name space collisions.
<folder> Element Attributes
The <folder> element has two attributes:
- © 2010, Oracle Corporation and/or its affiliates