JET Pack Metadata

• The name can include only letters, digits, '-', and '_'.
• The letters in the name should be all lowercase.
• The name must start with a lowercase letter.
• The name cannot be one of the following reserved names:
• annotation-xml
• color-profile
• font-face
• font-face-src
• font-face-uri
• font-face-format
• font-face-name
• missing-glyph

Note:

• At least one hyphen is required.
• The first segment (up to the first hyphen) is a namespace prefix. The namespace prefix 'oj' is reserved for components that are bundled with the JET release.
• The first hyphen must be followed by at least one character.

NOTE: Only valid for JET Packs and JET Resource Components.

• JET Packs may contain bundles that consist of multiple AMD modules (for example, each component could be packaged as a separate module).
• JET Reference Components may refer to 3rd party packages that include AMD-style bundles.

The configuration object has the following properties:

• the pack name for JET Packs
• some path that is specified by a JET Reference Component's paths metadata

Example:

 "bundles":
   {"oj-foo/some-bundle":
      ["oj-foo/component-one/loader", "oj-foo/component-two/loader"],
    "oj-foo/another-bundle":
      ["oj-foo/component-three/loader", "oj-foo/component-four/loader"],
   }
 

Example:

dependencies:  {"oj-foo-composite1": "1.2.0", "oj-foo-composite2": "2.1.0"}

Note:

• Always use the full name of the component when declaring a dependency upon it.
• JET Packs use their dependencies metadata to specify the exact semantic versions of the JET Custom Components, JET Reference Components, and JET Resource Components that constitute the JET Pack – consequently, semantic version ranges are not permitted in JET Packs.
• JET Packs do not support nesting – in other words a JET Pack may not declare a dependency upon another JET Pack.
• JET Reference Components and JET Resource Components may use semantic version range syntax to specify the range of versions that are acceptable to fulfill their dependency requirements.

For example:

• the name of the license text file packaged with the component
• a URL to a remote license file

A JET Pack is a versioned set of JET Components with additional metadata that enables applications to easily install and configure path mappings to the artifacts in that JET Pack.

• If specified, then there should exist a JET Pack whose name is the pack value, and which lists this component's full name in its dependencies metadata.
• If unspecified, then this is a standalone JET Component that is not a member of any JET Pack.
• JET Packs do not supported nesting and are therefore, by definition, standalone JET Components.

Specifies the name of the AMD-compatible npm package that is referenced by this component. This is needed to allow the consuming application to identify the 3rd party library, for conflict resolution purposes as well as for security scanning and patching.

Each object is defined as follows:

Notes:

• If the paths value is an array, then each array item is of the type described above. When an array is specified, each element must resolve to a unique value for the name property. (In practical terms, that means that only one element in the array can leverage the package property value for its default name value.)
• In addition to its use for JET Reference Components, paths is also valid for JET Packs and JET Resource Components with the following restrictions:
  1. Only a single path mapping is allowed (in other words, the value cannot be an array);
  2. The name sub-property is ignored – the left hand side of the RequireJS path mapping always defaults to the JET Pack or JET Resource Component name property value;
  3. The npm sub-property is ignored – JET Packs and JET Resource Components can leverage the cdn sub-property to configure loading those artifacts at runtime from a CDN;
  4. The information in the paths property is ignored for JET Resource Components that are part of a JET Pack – only the JET Pack itself will be path mapped.

JET Resource Components define and package resources shared by a set of JET Web Components, typically collected into a JET Pack. By default, these shared resources are considered private, but sometimes it makes sense for a JET Resource Component to provide public utility modules that can be independently imported into a JET application.

The publicModules metadata property specifies an array of paths to public modules that can be imported into a JET application. Oracle JET Tooling leverages this metadata to automatically build minified modules for these public utilities.

The full path to the public module to be imported takes the form: [pack]/[name]/[publicModules entry]

Example:

 {
   "name": "utils",
   "pack": "oj-foo",
   "type": "resource",
   "displayName": "oj-foo Utilities",
   "publicModules": [
     "validators/fooValidatorFactory",
     "converters/fooConverterFactory"
   ],
   ...
 }
 

 define(['ojs/ojcore', ..., 'oj-foo/utils/validators/fooValidatorFactory'],
   function(oj, ...) {
     ...
 }
 

 import {fooValidatorFactory} from "oj-foo/utils/validators/fooValidatorFactory.js";
 

Default:  "composite"

Supported values are:

Metadata for JET Web Components are described in more detail in the JET Metadata topic.