Pentaho Web Package

The Pentaho Platform detects and manages OSGi bundles that contain Pentaho Web Packages, collecting the information needed to build the AMD/RequireJS configuration and to setup the mappings needed to serve the package resources through HTTP.

The package is described by a package.json file, based upon the package.json spec and is mostly compatible with files generated by the npm tool.

These are, for now, the relevant supported fields:

name and version

mandatory

The most important fields in package.json are the name and version fields. Those are required, and the package must not install without them.

The name and version together form a unique system identifier for the package which is used internally as the base AMD/RequireJS module identifier and as part of the HTTP location where the resources are served.

Example:

{
  "name": "my-viz-lib",
  "version": "1.0.0"
}

Names can also be scoped to an organization, as in:

{
  "name": "@my-org/viz-lib",
  "version": "1.0.0"
}

paths

Exposes the resources under a given package path under a base module identifier.

When unspecified, the literal package name is used to map the package’s root path, as if the following had been specified:

{
  "name": "@my-org/viz-lib",
  "version": "1.0.0",
  "paths": {
    "@my-org/viz-lib": "/"
  }
}

While it is common to specify scoped and hyphenated package names, AMD module identifiers are, more commonly, valid JavaScript identifiers. So, in this case, it would make more sense to explicitly specify a root module, such as in:

{
  "name": "@my-org/viz-lib",
  "version": "1.0.0",
  "paths": {
    "myOrg/visual": "/"
  }
}

dependencies

Dependencies are specified in a simple object that maps a package name to a version range. The version range is a string which has one or more space-separated descriptors, as defined in https://github.com/npm/node-semver#ranges.

{
  "name": "@my-org/viz-lib", 
  "version": "1.0.0",
  "paths": {
    "myOrg/visual": "/"
  },
  "dependencies": { 
    "bar": "~2.0" 
  }
}

This information is used by the platform to find out the dependency tree, do the runtime dependency resolution, and build the proper AMD/RequireJS mappings that will allow each package to request external modules that satisfy the dependencies’ version restrictions.

For instance, in the above example, the code in the @my-org/viz-lib package can use modules from the bar dependency without the knowledge that it is available at a path such as /bar@2.1.4/foo.

Unsupported identifiers

Only version ranges are supported. You cannot use:

config

A configuration object that is made available to AMD/RequireJS modules that match the module identifier listed in the config object. Modules with a matching module identifier can access the configuration object via module.config.

In particular, this is used to configure the pentaho/modules module, used as a basic inversion-of-control mechanism to inject the package resources into the system.

For instance, to declare that the package JavaScript module at config.js exports a value which is an instance of the type pentaho/config/spec/IRuleSet, you would do:

{ 
  "name": "@my-org/viz-lib", 
  "version": "1.0.0",
  "paths": {
    "myOrg/visual": "/"
  },
  "config": {
    "pentaho/modules": {
      "myOrg/visual/config": {"type": "pentaho/config/spec/IRuleSet"}
    }
  }
}

Another use is to declare that a type such as that exported by the JavaScript module at Model.js is subtype of the visualization base type, pentaho/visual/Model:

{ 
  "name": "@my-org/viz-lib", 
  "version": "1.0.0",
  "paths": {
    "myOrg/visual": "/"
  },
  "config": {
    "pentaho/modules": {
      "myOrg/visual/Model": {"base": "pentaho/visual/Model"}
    }
  }
}