Page Comparison

...

• The @Nullable annotation tells CDAP that the field is not required. Without that annotation, CDAP will complain if no plugin property for delimiter is given.

• Configuration fields can be annotated with an @Description that will be returned by the Artifact HTTP RESTful APIMicroservices Plugin Detail.

• The @Macro annotation makes the field message macro-enabled; this allows the value of the field message to be a "macro key" whose value will be set at runtime.

...

Sometimes there is a need to use classes in a third-party JAR as plugins. For example, you may want to be able to use a JDBC driver as a plugin. In these situations, you have no control over the code, which means you cannot annotate the relevant class with the @Plugin annotation. If this is the case, you can explicitly specify the plugins when deploying the artifact. For example, if you are using the HTTP RESTful APIMicroservices, you set the Artifact-Plugins, Artifact-Version, and Artifact-Extends headers when deploying the artifact:

...

A system artifact is available to users across any namespace. A user artifact is available only to users in the namespace to which it is deployed. By design, deploying as a user artifact just requires access to the Artifact HTTP RESTful APIMicroservices, while deploying as a system artifact requires access to the filesystem of the CDAP Master. This then requires administrator access and permission.

...

Once your JARs and matching configuration files are in place, a CDAP CLI command (load artifact) or a HTTP RESTful API Microservices call to load system artifacts can be made to load the artifacts. As described in the documentation on Artifacts, only snapshot artifacts can be re-deployed without requiring that they first be deleted.

...

To deploy the artifact as a user artifact, use the Artifact HTTP RESTful Microservices API Add Artifact or the CLI.

When using the HTTP RESTful APIMicroservices, you will need to specify the Artifact-Extends header. Unless the artifact's version is defined in the manifest file of the JAR file you upload, you will also need to specify the Artifact-Version header.

...

For example, to deploy custom-transforms-1.0.0.jar using the RESTful APIMicroservices:

$ curl -w"\n" -X POST "localhost:11015/v3/namespaces/default/artifacts/custom-transforms" \
-H "Artifact-Extends: system:cdap-data-pipeline[6.2.0, 6.2.0]/system:cdap-data-streams[6.2.0, 6.2.0]" \
--data-binary @/path/to/custom-transforms-1.0.0.jar

...

You can deploy third-party JARs in the same way except the plugin information needs to be explicitly listed. As described in the documentation on Artifacts, only snapshot artifacts can be re-deployed without requiring that they first be deleted.

Using the RESTful API Microservices (note that if the artifact version is not in the JAR manifest file, it needs to be set explicitly, as the JAR contents are uploaded without the filename):

...

You can verify that a plugin artifact was added successfully by using the Artifact HTTP RESTful API to Microservices to retrieve artifact details. For example, to retrieve detail about our custom-transforms artifact:

...

You can verify that the plugins in your newly-added artifact are available to its parent by using the Artifact HTTP RESTful API to Microservices to list plugins of a specific type. For example, to check if cdap-data-pipeline can access the plugins in the custom-transforms artifact:

...