[
https://issues.apache.org/jira/browse/CB-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15124669#comment-15124669
]
ASF GitHub Bot commented on CB-10364:
-------------------------------------
Github user riknoll commented on a diff in the pull request:
https://github.com/apache/cordova-docs/pull/474#discussion_r51338895
--- Diff: www/docs/en/dev/plugin_ref/spec.md ---
@@ -17,700 +17,489 @@ license: >
specific language governing permissions and limitations
under the License.
-title: Plugin Specification
+title: Plugin.xml
---
-# Plugin Specification
-
-The `plugin.xml` file is an XML document in the `plugins` namespace:
-`http://apache.org/cordova/ns/plugins/1.0`. It contains a top-level
-`plugin` element that defines the plugin, and children that define the
-structure of the plugin.
-
-A sample plugin element:
+# Plugin.xml
- <?xml version="1.0" encoding="UTF-8"?>
- <plugin xmlns="http://apache.org/cordova/ns/plugins/1.0";
- xmlns:android="http://schemas.android.com/apk/res/android";
- id="com.alunny.foo"
- version="1.0.2">
+Plugin.xml file defines the structure and settings required for your
plugin. It has several elements to provide details about your plugin.
-## _plugin_ Element
+## plugin
-The `plugin` element is the plugin manifest's top-level element. It
-features the following attributes:
+ The `plugin` element is the plugin manifest's top-level element.
-* `xmlns` (required):
- The plugin namespace, `http://apache.org/cordova/ns/plugins/1.0`. If
- the document contains XML from other namespaces, such as tags to be
- added to the `AndroidManifest.xml` file, those namespaces should
- also be included in the top-level element.
+ Attributes(type) | Description
+ ---------------- | ------------
+ xmlns(string) | *Required* <br/> The plugin namespace,
`http://apache.org/cordova/ns/plugins/1.0`. If the document contains XML from
other namespaces, such as tags to be added to the `AndroidManifest.xml` file,
those namespaces should also be included in the <plugin> element.
+ id(string) | *Required* <br/> A reverse-domain style identifier for the
plugin.
+ version(string) | *Required* <br/> A version number for the plugin, that
matches the following major-minor-patch style regular expression:
`^\d+[.]\d+[.]\d+$`
-* `id` (required):
- A reverse-domain style identifier for the plugin, such as
- `com.alunny.foo`
+ Example:
+ ```
+ <?xml version="1.0" encoding="UTF-8"?>
+ <plugin xmlns="http://apache.org/cordova/ns/plugins/1.0";
+ xmlns:android="http://schemas.android.com/apk/res/android";
+ id="com.alunny.foo"
+ version="1.0.2">
+ ```
-* `version` (required):
- A version number for the plugin, that matches the following
- major-minor-patch style regular expression:
+### engines and engine
- ^\d+[.]\d+[.]\d+$
+ The child elements of the `<engines>` element specify versions of Apache
Cordova-based frameworks that this plugin supports. Plugman aborts with a
non-zero code for any plugin whose target project does not meet the engine's
constraints. If no <engine> tags are specified, plugman attempts to install
into the specified cordova project directory blindly.
-## _engines_ and _engine_ Elements
+ Attributes(type) | Description
+ ---------------- | ------------
+ name(string) | *Required* <br/> Name of the engine. Here are the default
engines that are supported : <ul><li> `cordova` </li> <li> `cordova-plugman`
</li> <li> `cordova-android` </li> <li> `cordova-ios` </li> <li>
`cordova-blackberry10` </li> <li> `cordova-wp8` </li> <li> `cordova-windows`
</li> <li> `android-sdk` // returns the highest Android api level installed
</li> <li> `apple-xcode` // returns the xcode version </li> <li> `apple-ios` //
returns the highest iOS version installed </li> <li> `apple-osx` // returns the
OSX version </li> <li> `blackberry-ndk` // returns the native blackberry SDK
version </li> You can also specify a custom framework apart from the default
ones.
+ version(string) | *Required* <br/> The version that your framework must
have in order to install. It should match a major-minor-patch string conforming
to the regular expression: `^\d+[.]\d+[.]\d+$`
+ scriptSrc(string) | **For custom frameworks only** <br/> *Required*
<br/> The script file that tells plugman the version of the custom framework.
Ideally, this file should be within the top level directory of your plugin
directory.
+ platform(string) | **For custom frameworks only** <br/> *Required* <br/>
The platforms your framework supports. You may use the wildcard `*` to say
supported for all platforms, specify multiple with a pipe character like
`android|ios|blackberry10` or just a single platform like `android`.
-The child elements of the `<engines>` element specify versions of
-Apache Cordova-based frameworks that this plugin supports. An example:
+ Examples:
+ ```
+ <engines>
+ <engine name="cordova-android" version="=1.8.0" />
+ </engines>
+ ```
- <engines>
- <engine name="cordova" version="1.7.0" />
- <engine name="cordova" version="1.8.1" />
- <engine name="worklight" version="1.0.0" platform="android"
scriptSrc="worklight_version"/>
- </engines>
+ Engine elements may also specify fuzzy matches using '>', '>=' etc. to
avoid repetition, and to reduce maintenance when the underlying platform is
updated.
+ ```
+ <engines>
+ <engine name="cordova-android" version=">=1.8.0" />
+ </engines>
+ ```
-Similar to the `<plugin>` element's `version` attribute, the specified
-version string should match a major-minor-patch string conforming to
-the regular expression:
+ The `<engine>` tags also has default support for all of the main
platforms Cordova exists on. Specifying the cordova engine tag means that all
versions of Cordova on any platform must satisfy the engine version attribute.
You may also list specific platforms and their versions in order to override
the catch-all cordova engine:
+ ```
+ <engines>
+ <engine name="cordova" version=">=1.7.0" />
+ <engine name="cordova-android" version=">=1.8.0" />
+ <engine name="cordova-ios" version=">=1.7.1" />
+ </engines>
+ ```
- ^\d+[.]\d+[.]\d+$
+ Custom frameworks example:
+ ```
+ <engines>
+ <engine name="my_custom_framework" version="1.0.0" platform="android"
scriptSrc="path_to_my_custom_framework_version"/>
+ <engine name="another_framework" version=">0.2.0"
platform="ios|android" scriptSrc="path_to_another_framework_version"/>
+ <engine name="even_more_framework" version=">=2.2.0" platform="*"
scriptSrc="path_to_even_more_framework_version"/>
+ </engines>
+ ```
-Engine elements may also specify fuzzy matches to avoid repetition,
-and to reduce maintenance when the underlying platform is updated.
-Tools should support a minimum of `>`, `>=`, `<` and `<=`, for
-example:
+### name
- <engines>
- <engine name="cordova" version=">=1.7.0" />
- <engine name="cordova" version="<1.8.1" />
- </engines>
+ The `name` element is used to specify the name of the plugin. This
element does not (yet) handle localization.
-The `<engine>` tags also has default support for all of the main platforms
Cordova exists on.
-Specifying the `cordova` engine tag means that all versions of Cordova on
any platform must
-satisfy the engine version attribute. You may also list specific platforms
and their versions
-in order to override the catch-all `cordova` engine:
+ Example:
+ ```
+ <name>Foo</name>
+ ```
- <engines>
- <engine name="cordova" version=">=1.7.0" />
- <engine name="cordova-android" version=">=1.8.0" />
- <engine name="cordova-ios" version=">=1.7.1" />
- </engines>
+### description
-Here's a list of the default engines that the `<engine>` tag supports:
+ The `description` element is used to specify the description of the
plugin. This element does not (yet) handle localization.
-* `cordova`
-* `cordova-plugman`
-* `cordova-amazon-fireos`
-* `cordova-android`
-* `cordova-ios`
-* `cordova-blackberry10`
-* `cordova-wp8`
-* `cordova-windows8`
-* `android-sdk` // returns the highest Android api level installed
-* `apple-xcode` // returns the xcode version
-* `apple-ios` // returns the highest iOS version installed
-* `apple-osx` // returns the OSX version
-* `blackberry-ndk` // returns the native blackberry SDK version
-
-Specifying custom Apache Cordova-based frameworks should be listed under
the engine tag like so:
+ Example:
+ ```
+ <description>Foo plugin description</description>
+ ```
- <engines>
- <engine name="my_custom_framework" version="1.0.0"
platform="android" scriptSrc="path_to_my_custom_framework_version"/>
- <engine name="another_framework" version=">0.2.0"
platform="ios|android" scriptSrc="path_to_another_framework_version"/>
- <engine name="even_more_framework" version=">=2.2.0" platform="*"
scriptSrc="path_to_even_more_framework_version"/>
- </engines>
+### author
-A custom Apache Cordova-based framework requires that an engine element
includes the following attributes:
-`name`, `version`, `scriptSrc`, and `platform`.
+ The content of the `author` element contains the name of the plugin
author.
-* `name` (required): A human-readable name for your custom framework.
+ Example:
+ ```
+ <author>Foo plugin author</author>
+ ```
-* `version` (required): The version that your framework must have in order
to install.
+### keywords
-* `scriptSrc` (required): The script file that tells plugman what version
of the custom framework is.
-Ideally, this file should be within the top level directory of your plugin
directory.
+ The content of the `keywords` element contains comma separated keywords
to describe the plugin.
-* `platform` (required): Which platforms that your framework supports. You
may use the wildcard `*`
-to say supported for all platforms, specify multiple with a pipe character
like `android|ios|blackberry10`
-or just a single platform like `android`.
+ Example:
+ ```
+ <license>foo,bar</license>
+ ```
-plugman aborts with a non-zero code for any plugin whose target
-project does not meet the engine's constraints.
+### license
-If no `<engine>` tags are specified, plugman attempts to install into
-the specified cordova project directory blindly.
+ This element is used to specify the license of the plugin.
-## _name_ Element
+ Example:
+ ```
+ <license>Apache 2.0 License</license>
+ ```
+
+### asset
-A human-readable name for the plugin, whose text content contains the
-name of the plugin. For example:
+ This element is used to list the files or directories to be copied into
a Cordova app's www directory. Any `<asset>` elements that are nested within
`<platform>` elements specify platform-specific web assets.
- <name>Foo</name>
+ Attributes(type) | Description
+ ---------------- | ------------
+ src(string) | *Required* <br/> Where the file or directory is located
in the plugin package, relative to the plugin.xml document. If a file does not
exist at the specified src location, plugman stops and reverses the
installation process, issues a notification about the conflict, and exits with
a non-zero code.
+ target(string) | *Required* <br/> Where the file or directory should be
located in the Cordova app, relative to the www directory. If a file already
exists at the target location, plugman stops and reverses the installation
process, issues a notification about the conflict, and exits with a non-zero
code.
-This element does not (yet) handle localization.
+ Examples:
+ ```
+ <!-- a single file, to be copied in the root directory -->
+ <asset src="www/foo.js" target="foo.js" />
+ <!-- a directory, also to be copied in the root directory -->
+ <asset src="www/foo" target="foo" />
+ ```
-## _description_ Element
+ Assets can be targeted to subdirectories as well. This will create the
js/experimental directory within the www directory, unless already present, and
copy the new-foo.js file and renames it to foo.js.
+ ```
+ <asset src="www/new-foo.js" target="js/experimental/foo.js" />
+ ```
-A human-readable description for the plugin. The text content of the
element contains
-the description of the plugin. An example:
+### js-module
- <description>Foo plugin description</description>
+ Most plugins include one or more JavaScript files. Each `<js-module>`
tag corresponds to a JavaScript file, and prevents the plugin's users from
having to add a `<script>` tag for each file. Do not wrap the file with
cordova.define, as it is added automatically. The module is wrapped in a
closure, with module, exports, and require in scope, as is normal for AMD
modules. Nesting `<js-module>` elements within `<platform>` declares
platform-specific JavaScript module bindings.
-This element does not (yet) handle localization.
+ Attributes(type) | Description
+ ---------------- | ------------
+ src(string) | References a file in the plugin directory relative to the
plugin.xml file. If src does not resolve to an existing file, plugman stops and
reverses the installation, issues a notification of the problem, and exits with
a non-zero code.
+ name(string) | Provides the last part of the module name. It can
generally be whatever you like, and it only matters if you want to use
cordova.require to import other parts of your plugins in your JavaScript code.
The module name for a `<js-module>` is your plugin's id followed by the value
of name.
-## _author_ Element
+ Example:
-Plugin author name. The text content of the element contains
-the name of the plugin author. An example:
+ When installing a plugin with the example below, socket.js is copied to
`www/plugins/my.plugin.id/socket.js`, and added as an entry to
`www/cordova_plugins.js`. At load time, code in cordova.js uses XHR to read
each file and inject a `<script>` tag into HTML.
+ ```
+ <js-module src="socket.js" name="Socket">
+ </js-module>
+ ```
+ Also for this example, with a plugin id of `chrome.socket`, the module
name will be `chrome.socket.Socket`.
- <author>Foo plugin description</author>
+#### clobbers
-## _keywords_ Element
+ Allowed within `<js-module>` element. Used to specify the namespace
under `window` object where module.exports gets inserted. You can have as many
`<clobbers>` as you
+ like. Any object not available on `window` is created.
-Plugin keywords. The text content of the element contains comma separated
keywords to describe the plugin. An example:
+ Attributes(type) | Description
+ ---------------- | ------------
+ target(string) | The namespace where module.exports gets inserted to.
- <keywords>foo,bar</keywords>
+ Example:
+ ```
+ <js-module src="socket.js" name="Socket">
+ <clobbers target="chrome.socket" />
+ </js-module>
+ ```
+ Here module.exports gets inserted into the `window` object as
`window.chrome.socket`.
-## _license_ Element
+#### merges
-Plugin license. The text content of the element contains the plugin
license. An example:
+ Allowed within `<js-module>` element. Used to specify the namespace
under `window` object where module.exports gets merged with any existing value.
If any key already exists, the module's version overrides the original. You can
have as many `<merges>` as you like. Any object not available on `window` is
created.
- <license>Apache 2.0 License</license>
+ Attributes(type) | Description
+ ---------------- | ------------
+ target(string) | The namespace which module.exports gets merged to.
-## _asset_ Element
+ Example:
+ ```
+ <js-module src="socket.js" name="Socket">
+ <merges target="chrome.socket" />
+ </js-module>
+ ```
+ Here module.exports gets merged with any existing value at
`window.chrome.socket`.
-One or more elements listing the files or directories to be copied
-into a Cordova app's `www` directory. Examples:
+#### runs
- <!-- a single file, to be copied in the root directory -->
- <asset src="www/foo.js" target="foo.js" />
- <!-- a directory, also to be copied in the root directory -->
- <asset src="www/foo" target="foo" />
+ Allowed within `<js-module>` element. It implies that your code should
be specified with `cordova.require`, but not installed on the `window` object.
This is useful when initializing the module, attaching event handlers or
otherwise. You can only have up to one `<runs/>` tag. Note that including a
`<runs/>` with `<clobbers/>` or `<merges/>` is redundant, since they also
`cordova.require` your module.
-All `<asset>` tags require both `src` and `target` attributes.
-Web-only plugins contains mostly `<asset>` elements. Any `<asset>`
-elements that are nested within `<platform>` elements specify
-platform-specific web assets, as described below. Attributes include:
+ Example:
+ ```
+ <js-module src="socket.js" name="Socket">
+ <runs/>
+ </js-module>
+ ```
-* `src` (required):
- Where the file or directory is located in the plugin package,
- relative to the `plugin.xml` document. If a file does not exist at
- the specified `src` location, plugman stops and reverses the
- installation process, issues a notification about the conflict, and
- exits with a non-zero code.
+### dependency
-* `target` (required):
+ The `<dependency>` tag allows you to specify other plugins on which the
current plugin depends. While future versions will access them from plugin
repositories, in the short term plugins are directly referenced as URLs by
`<dependency>` tags. In the future, version constraints will be introduced, and
a plugin repository will exist to support fetching by name instead of explicit
URLs.
- Where the file or directory should be located in the Cordova app,
- relative to the `www` directory.
- Assets can be targeted to subdirectories, for example:
+ Attributes(type) | Description
+ ---------------- | ------------
+ id(string) | Provides the ID of the plugin. It should be globally
unique, and expressed in reverse-domain style. While neither of these
restrictions is currently enforced, they may be in the future.
+ url(string) | A URL for the plugin. This should reference a git
repository, which plugman attempts to clone.
+ commit(string) | This is any git reference understood by `git checkout`:
a branch or tag name (e.g., `master`, `0.3.1`), or a commit hash (e.g.,
`975ddb228af811dd8bb37ed1dfd092a3d05295f9`).
+ subdir(string) | Specifies that the targeted plugin dependency exists as
a subdirectory of the git repository. This is helpful because it allows the
repository to contain several related plugins, each specified individually.
<br/> If you set the `url` of a `<dependency>` tag to `"."` and provide a
`subdir`, the dependent plugin is installed from the same local or remote git
repository as the parent plugin that specifies the `<dependency>` tag. <br/>
Note that the `subdir` always specifies a path relative to the _root_ of the
git repository, not the parent plugin. This is true even if you installed the
plugin with a local path directly to it. Plugman finds the root of the git
repository and then finds the other plugin from there.
+
+ Example:
+ ```
+ <dependency id="com.plugin.id"
url="https://github.com/myuser/someplugin"; commit="428931ada3891801"
subdir="some/path/here" />
+ ```
+
+### platform
+
+ Identifies platforms that have associated native code or require
modifications to their configuration files. Tools using this specification can
identify supported platforms and install the code into Cordova projects.
Plugins without `<platform>` tags are assumed to be JavaScript-only, and
therefore installable on any and all platforms.
+
+ Attributes(type) | Description
+ ---------------- | ------------
+ name(string) | *Required* <br/> Allowed values: ios, android,
blackberry10, amazon-fireos, wp8, windows <br/> Identifies a platform as
supported, associating the element's children with that platform.
+
+ Example:
+ ```
+ <platform name="android">
+ <!-- android-specific elements -->
+ </platform>
+ ```
+
+#### source-file
+
+ Identifies executable source code that should be installed into a
project.
+
+ Attributes(type) | Description
+ ---------------- | ------------
+ src(string) | *Required* <br/> Location of the file relative to
plugin.xml. If the src file can't be found, plugman stops and reverses the
installation, issues a notification about the problem, and exits with a
non-zero code.
+ target-dir(string) | A directory into which the files should be copied,
relative to the root of the Cordova project. In practice, this is most
important for Java-based platforms, where a file in the `com.alunny.foo`
package must be located within the `com/alunny/foo` directory. For platforms
where the source directory is not important, this attribute should be omitted.
+ framework(boolean) | *Default: false* <br/> ==iOS== <br/> If set to
true, also adds the specified file as a framework to the project.
+ compiler-flags(string) | ==iOS== <br/> If set, assigns the specified
compiler flags for the particular source file.
+
+ Examples:
+ ```
+ <!-- android -->
+ <source-file src="src/android/Foo.java" target-dir="src/com/alunny/foo"
/>
+ <!-- ios -->
+ <source-file src="src/ios/CDVFoo.m" />
+ <source-file src="src/ios/someLib.a" framework="true" />
+ <source-file src="src/ios/someLib.a" compiler-flags="-fno-objc-arc" />
+ ```
+
+#### header-file
+
+ This is like `<source-file>` element, but specifically for platforms
such as iOS and android that distinguish between source files, headers, and
resources. This is not supported by Windows.
+
+ Example:
+
+ For iOS:
+ ```
+ <header-file src="CDVFoo.h" />
+ ```
+
+#### resource-file
+
+ This is like `<source-file>` element, but specifically for platforms
such as iOS and android that distinguish between source files, headers, and
resources. This is supported by Windows.
+
+ Attributes(type) | Description
+ ---------------- | ------------
+ arch(string) | ==windows== <br/> Allowed values: `x86`, `x64` or `ARM`.
<br/> Indicates that the file should only be included when building for the
specified architecture.
+ device-target | ==windows== <br/> Allowed values: `win` (or `windows`),
`phone` or `all`. <br/> Indicates that the file should only be included when
building for the specified target device type.
+ versions | ==windows== <br/> Indicates that the file should only be
included when building for versions that match the specified version string.
Value can be any valid node semantic version range string.
+
+ Examples:
+
+ For android:
+ ```
+ <resource-file src="FooPluginStrings.xml"
target="res/values/FooPluginStrings.xml" />
+ ```
+
+ For windows:
+ ```
+ <resource-file src="src/windows/win81/MobServices.pri"
target="win81/MobServices.pri" device-target="windows" versions="8.1"
arch="x64"/>
+ ```
+
+#### config-file
+
+ Identifies an XML-based configuration file to be modified, where in that
document the modification should take place, and what should be modified.
+ Two file types that have been tested for modification with this element
are `xml` and `plist` files.
+ The `config-file` element only allows you to append new children to an
XML document tree. The children are XML literals to be inserted in the target
document.
+
+ Attributes(type) | Description
+ ---------------- | ------------
+ target(string) | The file to be modified, and the path relative to the
root of the Cordova project. If the specified file does not exist, the tool
ignores the configuration change and continues installation. <br/> The target
can include wildcard (`*`) elements. In this case, plugman recursively searches
through the project directory structure and uses the first match. <br/> On iOS,
the location of configuration files relative to the project directory root is
not known, so specifying a target of `config.xml` resolves to
`cordova-ios-project/MyAppName/config.xml`.
+ parent(string) | An XPath selector referencing the parent of the
elements to be added to the config file. If you use absolute selectors, you can
use a wildcard (`*`) to specify the root element, e.g., `/*/plugins`. If the
selector does not resolve to a child of the specified document, the tool stops
and reverses the installation process, issues a warning, and exits with a
non-zero code. <br/> For `plist` files, the `parent` determines under what
parent key the specified XML should be inserted.
+ after(string) | A prioritized list of accepted siblings after which to
add the XML snippet. Useful for specifying changes in files which require
strict ordering of XML elements like
[this](http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff769509%28v=vs.105%29.aspx#BKMK_EXTENSIONSelement).
+ device-target(string) | ==windows== <br/> Allowed values: `win`,
`phone`, `all`. <br/> Applicable when affecting the meta-name
`package.appxmanifest`, this attribute indicates that the file should only be
modified when building for the specified target device type.
+ versions(string) | ==windows== <br/> Applicable when affecting the
meta-name `package.appxmanifest`, this attribute indicates that app manifests
for specific Windows versions should only be altered for versions that match
the specified version string. Value can be any valid node semantic version
range string.
+
+ Examples:
+
+ For XML:
+ ```
+ <config-file target="AndroidManifest.xml" parent="/manifest/application">
+ <activity android:name="com.foo.Foo"
android:label="@string/app_name">
+ <intent-filter>
+ </intent-filter>
+ </activity>
+ </config-file>
+ ```
+
+ For `plist`:
+ ```
+ <config-file target="*-Info.plist" parent="CFBundleURLTypes">
+ <array>
+ <dict>
+ <key>PackageName</key>
+ <string>$PACKAGE_NAME</string>
+ </dict>
+ </array>
+ </config-file>
+ ```
+
+ For windows-specific attributes:
+ ```
+ <config-file target="package.appxmanifest"
parent="/Package/Capabilities" versions="<8.1.0">
+ <Capability Name="picturesLibrary" />
+ <DeviceCapability Name="webcam" />
+ </config-file>
+ <config-file target="package.appxmanifest"
parent="/Package/Capabilities" versions=">=8.1.0" device-target="phone">
+ <DeviceCapability Name="webcam" />
+ </config-file>
+ ```
+ The above example will set pre-8.1 platforms (Windows 8, specifically)
to require the `webcam` device capability and the `picturesLibrary` general
capability, and apply the `webcam` device capability only to Windows 8.1
projects that build for Windows Phone. Windows desktop 8.1 systems are
unmodified.
+
+#### plugins-plist
+
+ Specifies a key and value to append to the correct `AppInfo.plist` file
in an iOS Cordova project. This is _outdated_ as it only applies to cordova-ios
2.2.0 and below. Use the `<config-file>` tag for newer versions of Cordova.
+
+ Example:
+ ```
+ <plugins-plist key="Foo" string="CDVFoo" />
+ ```
+
+#### lib-file
+
+ Like source, resource, and header files, but specifically for platforms
such as BlackBerry 10 that use user-generated libraries. For the Windows
platform, the `<lib-file>` element allows the inclusion of an `<SDKReference>`
in the generated Windows project files.
+
+ Attributes(type) | Description
+ ---------------- | ------------
+ src(string) | *Required* <br/> The location of the file relative to
`plugin.xml`. If `src` can't be found, plugman stops and reverses the
installation, issues a warning about the problem, and exits with a non-zero
code. <br/> For Windows, it indicates the name of the SDK to include (which
will be used as value of the `Include` attribute of the generated
`<SDKReference>` element).
+ arch(string) | The architecture for which the `.so` file has been built,
either `device` or `simulator`. <br/> For Windows, it indicates that the
`<SDKReference>` should only be included when building for the specified
architecture. Supported values are `x86`, `x64` or `ARM`.
+ device-target(string) | ==windows== <br/> Allowed values: `win` (or
`windows`), `phone` or `all`. <br/> Indicates that the `<SDKReference>` should
only be included when building for the specified target device type.
+ versions(string) | ==windows== <br/> Indicates that the `<SDKReference>`
should only be included when building for versions that match the specified
version string. Value can be any valid node semantic version range string.
+
+ Examples:
+ ```
+ <lib-file src="src/BlackBerry10/native/device/libfoo.so" arch="device" />
+ <lib-file src="src/BlackBerry10/native/simulator/libfoo.so"
arch="simulator" />
+ ```
+
+ For Windows:
+ ```
+ <lib-file src="Microsoft.WinJS.2.0, Version=1.0" arch="x86" />
+ <lib-file src="Microsoft.WinJS.2.0, Version=1.0" versions=">=8.1" />
+ <lib-file src="Microsoft.WinJS.2.0, Version=1.0" target="phone" />
+ <lib-file src="Microsoft.WinJS.2.0, Version=1.0" target="win"
versions="8.0" arch="x86" />
+ ```
+
+#### framework
+
+ Identifies a framework (usually part of the OS/platform) on which the
plugin depends.
+
+ Attributes(type) | Description
+ ---------------- | ------------
+ src(string) | *Required* <br/> The name of the system framework or the
relative path to one which is included as part of your plugin files.
+ custom(boolean) | Is a boolean indicating whether the framework is one
that is included as part of your plugin files.
+ weak(boolean) | *Default: false* <br/> Is a boolean indicating whether
the framework should be weakly linked.
+ type(string) | Is a string indicating the type of framework to add.
+ parent(string) | *Default: .* <br/> Sets the relative path to the
directory containing the sub-project to which to add the reference. The
default, `.`, implies the application project.
+ arch(string) | ==windows== <br/> Allowed values: `x86`, `x64` or `ARM`.
<br/> Indicates that the framework should only be included when building for
the specified architecture.
+ device-target(string) | ==windows== <br/> Allowed values: `win` (or
`windows`), `phone` or `all`. <br/> Indicates that the framework should only
be included when building for the specified target device type.
+ versions(string) | ==windows== <br/> Indicates that the framework should
only be included when building for versions that match the specified version
string. Value can be any valid node semantic version range string.
+ target-dir(string) | ==windows== <br/> Indicates a subdirectory into
which the framework should be copied. In practice, this is most important when
plugin contains different framework versions for different chip architectures
or device targets, but which have the same name. This allows you to specify
different subfolders for each framework version so that they don't overlap each
other.
+
+ Examples:
+
+ For iOS:
+ ```
+ <framework src="libsqlite3.dylib" />
+ <framework src="social.framework" weak="true" />
+ <framework src="relative/path/to/my.framework" custom="true" />
+ ```
+
+ On Android (as of cordova-android@4.0.0), framework tags are used to
include Maven dependencies, or to include bundled library projects.
+ ```
+ <!-- Depend on latest version of GCM from play services -->
+ <framework src="com.google.android.gms:play-services-gcm:+" />
+ <!-- Depend on v21 of appcompat-v7 support library -->
+ <framework src="com.android.support:appcompat-v7:21+" />
+ <!-- Depend on library project included in plugin -->
+ <framework src="relative/path/FeedbackLib" custom="true" />
+ ```
+
+ Framework can also be used to have custom .gradle files sub-included
into the main project's .gradle file:
+ ```
+ <framework src="relative/path/rules.gradle" custom="true"
type="gradleReference" />
+ ```
+
+ On Windows, using `custom='true'` and `type='projectReference'` will add
a reference to the project which will be added to the compile+link steps of the
cordova project. This essentially is the only way currently that a 'custom'
framework can target multiple architectures as they are explicitly built as a
dependency by the referencing cordova application.
+ ```
+ <framework src="path/to/project/LibProj.csproj" custom="true"
type="projectReference"/>
+ ```
+
+ Examples of using these Windows specific attributes:
+ ```
+ <framework src="src/windows/example.dll" arch="x64" />
+ <framework src="src/windows/example.dll" versions=">=8.0" />
+ <framework src="src/windows/example.vcxproj" type="projectReference"
target="win" />
+ <framework src="src/windows/example.vcxproj" type="projectReference"
target="all" versions="8.1" arch="x86" />
+ <framework src="src/windows/example.dll" target-dir="bin/x64" arch="x64"
custom="true"/>
+ ```
- <asset src="www/new-foo.js" target="js/experimental/foo.js" />
+### info
+
+ Additional information provided to users. This is useful when you
require extra steps that can't be easily automated or are beyond plugman's
scope.
- creates the `js/experimental` directory within the `www` directory,
- unless already present, then copies the `new-foo.js` file and
- renames it `foo.js`. If a file already exists at the target
- location, plugman stops and reverses the installation process,
- issues a notification about the conflict, and exits with a non-zero
- code.
+ Example:
+ ```
+ <info>
+ You need to install __Google Play Services__ from the `Android Extras`
section using the Android SDK manager (run `android`).
-## _js-module_ Element
+ You need to add the following line to the `local.properties`:
-Most plugins include one or more JavaScript files. Each `<js-module>`
-tag corresponds to a JavaScript file, and prevents the plugin's users
-from having to add a `<script>` tag for each file. While `<asset>`
-tags simply copy a file from the plugin subdirectory into `www`,
-`<js-module>` tags are much more sophisticated. They look like this:
+
android.library.reference.1=PATH_TO_ANDROID_SDK/sdk/extras/google/google_play_services/libproject/google-play-services_lib
+ </info>
+ ```
- <js-module src="socket.js" name="Socket">
- <clobbers target="chrome.socket" />
- </js-module>
+### hook
-When installing a plugin with the example above, `socket.js` is copied
-to `www/plugins/my.plugin.id/socket.js`, and added as an entry to
-`www/cordova_plugins.js`. At load time, code in `cordova.js` uses XHR
-to read each file and inject a `<script>` tag into HTML. It adds a
-mapping to clobber or merge as appropriate, as described below.
+ Represents your custom script which will be called by Cordova when
certain action occurs (for example, after plugin is added or platform prepare
logic is invoked). This is useful when you need to extend default Cordova
functionality. See [Hooks Guide](../guide/appdev/hooks/index.html) for more
information.
-_Do not_ wrap the file with `cordova.define`, as it is added
-automatically. The module is wrapped in a closure, with `module`,
-`exports`, and `require` in scope, as is normal for AMD modules.
+ Example:
+ ```
+ <hook type="after_plugin_install" src="scripts/afterPluginInstall.js" />
+ ```
-Details for the `<js-module>` tag:
+### uses-permission and variables
--- End diff --
The header for this seems strange. It can probably just be uses-permission.
Also, I think we should make it very clear in the first sentence what platforms
support this. All of the examples are for Android (and `uses-permission` is
also the name of a commonly used tag in `AndroidManifest.xml`), but iOS is
mentioned in the last paragraph?
> Make Plugin Specification (plugin.xml) page a reference
> -------------------------------------------------------
>
> Key: CB-10364
> URL: https://issues.apache.org/jira/browse/CB-10364
> Project: Apache Cordova
> Issue Type: Task
> Components: Docs
> Reporter: Raghav
> Assignee: Raghav
> Labels: Docs-6.x
>
> Plugin specification
> (http://cordova.apache.org/docs/en/latest/plugin_ref/spec.html) needs to be
> modified as per the new reference structure.
> General guidelines:
> - While giving examples, keep them short. Do not repeat for all
> plugins/platforms.
> - Remove all references to cordova plugin registry.
> - Remove Tizen references. The platform is deprecated
> (http://markmail.org/message/hryg6sjswecpgndu)
> - Keep information up to date for the platforms, CLI and plugins
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
