Registration of various objects, files and hints into layer is pretty central to the way NetBeans based applications handle communication between modules. This page summarizes the list of such extension points defined by modules with API.
To get your API listed here, use
<api type='export' group='layer' ... /> in
your module arch.xml document.
Context menu actions are read from the layer folder
Loaders/text/x-ant+xml/Actions.
"Projects/org-netbeans-modules-maven/Archetypes" folder contains fileobjects
that represent archetypes. The archetypes are defined by the following file attributes:
groupId mandatory
artifactId mandatory
version mandatory
repository optional url of the archetype's repository
nameBundleKey optional key in bundle file that holds localized name
descriptionBundleKey optional key in bundle file that holds localized description
<folder name="OptionsExport">
<!-- category -->
<folder name="MyCategory">
<!-- category display name -->
<attr name="displayName"
bundlevalue="org.netbeans.modules.mymodule.options.Bundle#Category_Display_Name"/>
<!-- item -->
<file name="MyItem1">
<attr name="displayName" bundlevalue="org.netbeans.modules.mymodule.options.Bundle#Item1_Display_Name"/>
<!-- include regex pattern rooted to userdir -->
<attr name="include" stringvalue="config/Preferences/org/netbeans/modules/mymodule/.*|config/mymodule/.*"/>
<!-- exclude regex pattern rooted to userdir -->
<attr name="exclude" stringvalue="config/mymodule/obsolete/.*"/>
</file>
<!-- item -->
<file name="MyItem2">
<attr name="displayName" bundlevalue="org.netbeans.modules.mymodule.options.Bundle#Item2_Display_Name"/>
<!-- include pattern with properties constrain -->
<attr name="include" stringvalue="config/mymodule[.]properties#key[1-9].*|keyA.*#|config/mymodule[.]xml"/>
<!-- exclude pattern with properties constrain -->
<attr name="exclude" stringvalue="config/obsolete[.]properties#key5"/>
</file>
</folder>
</folder>
Include/exclude patterns may contain either a regular expression defining
files relatively to userdir (see MyItem1) or a compound pattern defining
files and property keys (see MyItem2). A compound pattern consists of
file regex pattern followed by hash delimiter (#) then property key
regex pattern followed by another hash delimiter. Hash delimiter can be
ommited at the end of compound pattern. For example, a compound pattern
can have the following structure
filePattern1#keyPattern1#|filePattern2|filePattern3#keyPattern3.
Several project related actions are registered in the Actions folder in the layer.
Product branding is intended to use those actions to build main menu, toolbars and shortcuts.
New (or import) project wizards can be registered in a special folder
Templates/Projects/.
Providers of generic project actions can register Action and JSeparator
instances in a special folder Projects/Actions/. So if any module wishes
to extend, hide or reorder some of them it can just register its actions there. Example:
<folder name="Projects" >
<folder name="Actions" >
<file name="org-mymodule-MyAction.instance" >
<attr name="instanceCreate" stringvalue="org.mymodule.MyAction" />
</file>
</folder>
</folder>
File templates can be registered with various attributes, some specific to
the project system.
Under Templates/Licenses folder should be registered various license headers
that can be imported by templates using scripting. The recommended format of filename is
license-[licensename].txt e.g. license-cddl.txt.
Several project related actions are registered in the Actions folder in the layer.
Product branding is intended to use those actions to build main menu, toolbars and shortcuts.
Services/ProjectConvertors/)
and requiredFiles and delegate attributes.
New (or import) project wizards can be registered in a special folder
Templates/Projects/.
Providers of generic project actions can register Action and JSeparator
instances in a special folder Projects/Actions/. So if any module wishes
to extend, hide or reorder some of them it can just register its actions there. Example:
<folder name="Projects" >
<folder name="Actions" >
<file name="org-mymodule-MyAction.instance" >
<attr name="instanceCreate" stringvalue="org.mymodule.MyAction" />
</file>
</folder>
</folder>
File templates can be registered with various attributes, some specific to
the project system.
Under Templates/Licenses folder should be registered various license headers
that can be imported by templates using scripting. The recommended format of filename is
license-[licensename].txt e.g. license-cddl.txt.
There's a private XML file for user settings for each palette model.
Task List framework defines the following folders in XML layer:
/TaskList/Scanners - register your instances of task scanners here
/TaskList/ScanningScopes - here you can add additional scanning
scopes
/TaskList/Groups - here you can define additional task groups, for example:
<folder name="TaskList">
<folder name="Groups">
<file name="mygroup.instance">
<attr name="instanceCreate" methodvalue="org.netbeans.spi.tasklist.Task.createGroup"/>
<attr name="localizingBundle" stringvalue="org.mymodule.resources.Bundle"/>
<attr name="groupName" stringvalue="my-unique-group-name"/>
<attr name="diplayNameKey" stringvalue="LBL_my_group"/>
<attr name="descriptionKey" stringvalue="HINT_my_group"/>
<attr name="iconKey" stringvalue="ICON_my_group"/>
</file>
</folder>
</folder>
Tasks are organized into groups according
to their importance (error/warning/todo etc). The task group is specified when the Task is created.
Each group is identified by its unique name. The Task List framework provides the following groups:
Additional task groups can be specified in xml layers, see above.
"nb-tasklist-error" - for error-type tasks
"nb-tasklist-warning" - for warning-type tasks
UI/ToolActions folder to make them known
to
ToolsAction.
setAttribute is supported by the filesystem, the
getAttribute can behave like
XMLFileSystem's
methodvalue and newvalue attributes:
getAttribute
with raw: prefix to evaluate the attribute without instantiating it
(e.g. get
Method or
Class values from
methodvalue and newvalue attributes. This API
is not intended for public use at present and can change in future.
Loaders/folder/any/Actions
so if any module wishes
to extend, hide or reorder some of them it can just register its actions there.
Loaders/text/xml/Actions
Loaders/content/unknown/Actions
Loaders/application/x-nbsettings/Actions
Loaders/folder/any/Actions
so if any module wishes
to extend, hide or reorder some of them it can just register its actions there.
Loaders/text/xml/Actions
Loaders/content/unknown/Actions
Loaders/application/x-nbsettings/Actions
Loaders/mime/type/Factories.
The main menu of the application is composed by reading
Since version 7.44 one can attach Menu/
folder in the layer. A sub folder is treated as a sub menu.
Instances of individual files (usually .instance
or .shadow) may then represent
Action
or
JMenuItem
or
JSeparator.
property-prefix attribute
to every folder. Then all the file attributes are scanned and if some
of them start with the specified prefix they are placed a
client
properties on the
JMenu
instance (after stripping the prefix off).
Editors/TabActions.
Apache NetBeans 13 Documentation | APIs Layer list