...
- artifactName
- artifactDescription
- url
- mimetype
- processorPid
Since there are different types of artifacts, some properties depend on the actual type.
For bundles:
- Bundle-Name
- Bundle-SymbolicName
- Bundle-Version
For configuration:
- filename
For other types, please consult the documentation about these types (specifically the classes that implement the interfaces in the org.apache.ace.client.repository.helper
package).
Artifact2Feature
Associates artifacts to features. Associations have a left and right hand side. Both can be expressed as filter conditions, and both have a cardinality.
- leftEndpoint
- rightEndpoint
- leftCardinality rightEndpoint— defaults to 1
- rightCardinality — defaults to 1
Feature
A feature is a grouping mechanism for artifacts. It is commonly used to group together a set of artifacts that together represent some kind of feature to the application.
- name
- description
Feature2Distribution
Associates features to distributions. Associations have a left and right hand side. Both can be expressed as filter conditions, and both have a cardinality.
- leftEndpoint
- rightEndpoint
- leftCardinality — defaults to 1
- rightEndpoint
- rightCardinality — defaults to 1
Distribution
A feature is a grouping mechanism for features. It is commonly used to group together a set of features that together represent some kind of distribution. Distributions are the things you can associate with targets, so you can look at them as the licensable configurations of your software.
- name
- description
Distribution2Target
Associates distributions to targets. Associations have a left and right hand side. Both can be expressed as filter conditions, and both have a cardinality.
- leftEndpoint
- leftCardinality
- rightEndpoint
- leftCardinality — defaults to 1rightEndpoint
- rightCardinality — defaults to 1
Target
A target receives the artifacts you provision to it. Most of the time, a target is an OSGi container and provisioning means you'll actually install the artifacts in the container, but there can be other types of targets (non-OSGi containers, or something completely different).
- id
- autoapprove
A target also has specific state (see below for how that is returned):
- registrationState — Unregistered, Registered
- provisioningState — Idle, InProgress, OK, Failed
- storeState — New, Unapproved, Approved
- currentVersion
- isRegistered
- needsApproval
- autoApprove
- artifactsFromShop
- artifactsFromDeployment
- lastInstallSuccess
Checkout and commit
Similar to the web based UI, this API also works with the concept of checking out a copy to a local working area, altering it in that working area and then committing it back to the server.
...
Now you have a working copy, you can start working with it.
GET /work/ID
Gets you a list of all repositories you can use. Should return: \ ["artifact", "feature", "distribution", "target", "artifact2feature", "feature2distribution", "distribution2target"\] Wiki Markup
GET /work/ID/feature
Lists all feature IDs in the feature repository.
...
Returns a representation of the object, for example: {attributes: {key: "value"}, tags: {key: "value"
}}. If you ask for a target, you will also get its state, so the result will be in the form: {attributes: {key: "value"}, tags: {key: "value"}, state: {key: "value"
}}.
PUT /work/ID/feature/FID
...