...

Example
-------
In this example, the plugin is configured to with the unique fields as `fname,lname` and the filter operation as `max(cost)`.


Suppose the input records are:

    +======================================+
    | fname  | lname   | cost   |  zipcode |
    +======================================+
    | bob    | smith   | 50.23  |  12345   |
    | bob    | smith   | 0.50   |  45678   |
    | bob    | jones   | 30.64  |  23456   |
    | alice  | smith   | 1.50   |  34567   |
    | alice  | smith   | 30.21  |  56789   |
    | alice  | jones   | 500.93 |  67890   |
    +======================================+

The plugin will group all the 'bob smith' records together and only output the record that has the maximum cost.
Similarly, only the 'alice smith' record with the highest cost will be included in the output:

    +======================================+
    | fname  | lname   | cost   |  zipcode |
    +======================================+
    | bob    | smith   | 50.23  |  12345   |
    | bob    | jones   | 30.64  |  23456   |
    | alice  | smith   | 30.21  |  56789   |
    | alice  | jones   | 500.93 |  67890   |
    +======================================+

Widgets

• Labels should be capitalized, with the exception of 'a', 'an', 'of', 'the'.
• If a property does not have to be a text box, it probably should not be a textbox.
• Most widgets should specify a placeholder:

   {
    "widget-type": "textbox",
    "label": "Bucket Name",
    "name": "bucket",
    "widget-attributes" : {
      "placeholder": "The bucket to be used to create directories."
    }
  }

...

• Properties should be grouped into the standard 'Basic', 'Credentials', and 'Advanced' sections when possible. 
  • 'Basic' properties generally define the "core" of what the plugin does, likely including most required properties.
  • 'Credentials' are things related to authentication/authorization. Usernames, passwords, account keys, etc.
  • Advanced properties are things new users don't need to look at and are generally related to error scenarios and performance but not functionality.
• Boolean properties should use the 'radio-group' widget type and not a select drop down.

Naming

Coming up with a good name for a plugin and its properties can be a difficult task. The user facing name for plugins and properties is the 'label' specified in the widget json. 

...

User input should be validated as early as possible. Anything static should be validated in the configurePipeline() method. Everything else should be validated in the prepareRun() method.One convention many plugins have used is to have a validate() method on their plugin config object. Sometimes it will take an input schema as an argument. That way the validate() method can easily be called at configure time and at prepare time. It also gives a way to quickly unit test the validation logic without needing to deploy pipelines, which means in the configurePipeline() method.

Some useful things to keep in mind while validating:

• Use the containsMacro() method to check if the property is ready to be validated
• If a property is invalid, throw an IllegalArgumentException InvalidConfigPropertyException with a user friendly message. This message will be shown in the UI and should mention which property is invalid, why it is invalid, and what action the user can take to make it valid.
• If multiple properties are invalid, throw an InvalidStagePropertyException that contains multiple exceptions are the reasons.
• For numeric properties, can the property be 0? Can it be negative? Does it need to be within a certain range?
• The input schema is often required to perform validation. For example, a plugin may operate on a specific field, which can only be a specific type.
• A property cannot be null unless it is annotated as @Nullable.
• Don't forget to handle empty strings.

...