...
| Code Block |
|---|
GET /<cdap-version>/packages.json
ex: /4.0.0/packages.json
[
{
"name": "PurchaseExample",
"label": "Purchase History",
"description": "Example Application demonstrating usage of flows, workflows, mapreduce, and services.",
"author": "Cask",
"org": "Cask Data Inc.",
"version": "4.0.1",
"categories": [ "examples" ]
},
{
"name": "HelloWorld",
"label": "Hello World",
"description": "Simple application demonstrating usage of flows and services.",
"author": "Cask",
"org": "Cask Data Inc.",
"version": "4.0.0",
"categories": [ "examples" ]
},
...
] |
| Note |
|---|
This leaves grouping by category up to the UI. If needed, we could perhaps add packages-<category>.json files that only list the packages in a specific category. This also leaves display of multiple versions of the same package up to the UI. Though it seems like most of the time we would only have one version of the package per cdap version so maybe it's not a big problem. |
...
| Code Block |
|---|
{
...
"dependencies": [
{
"name": "spark-plugins",
"version": "1.5.0"
}
]
} |
Min versions are inclusive and max versions are exclusive.
If other packages are listed as a dependency, the actions for the dependent package must be executed before the actions of the current package.
| Note |
|---|
Package dependencies introduces non-trivial logic in the UI and allow users to create some complex dependency chains. To simplify things in the first version, it may be a good idea to enforce that dependencies are only one level deep. That is, a package cannot depend on a package that has dependencies. |
...
Failures
Since a package spec can contain multiple actions, what happens if some actions succeed and then one action fails? Since the CDAP APIs backing these actions are idempotent, we can ask the user if they want to retry.
...