The following commented accelerator.yaml should help you get started writing your own accelerators.
accelerator: # The `accelerator` section serves to document how an accelerator is presented to the # user in the accelerator web ui. # displayName: a descripive human-readable name. This should be short so as to look nice # in a list of many accelerators shown to a user. displayName: Hello Spring Boot # description: a more detailed description that a user might see if they took a closer # look at a particular accelerator. description: Simple Hello World Rest Service based on Spring Boot # iconUrl: Optional, a nice colorful, icon for your accelerator to make it stand out visually. iconUrl: https://raw.githubusercontent.com/simple-starters/icons/master/icon-cloud.png # tags: A list of classification tags. The ui allows users to search for accelerators based on tags tags: - Java - Spring - Function # options are 'parameters' that can affect how the accelerator behaves. # The purpose of the 'options' section is # - to list all applicable options # - describe each option in enough detail so that the UI can create # a suitable input widget for it. options: # a list of options # a first option - name: greeting # name: each option must have a name. # This must be # - camelCase # - unique (i.e. no two options can have the same name) # This is like a 'variable' used by the accelerator to refer to # and use the value during its execution. # This name is 'internal' to your accelerator and is not shown to # the user. label: Greeting Message # A human readable version of the `name`. This is used to identify an # option to the user in the UI. # This should be short (so as not to look ugly in a ui with limited # space available for labeling the input widgets). # There are no limits on what characters can be used in the label (so spaces # are allowed). description: Greeting message displayed by the Hello World app. # An optional more detailed description / explanation that can be shown to # to the user in the UI when the short label alone might not be enough to understand # its purpose. dataType: string # type of data the accelerator expects during execution (this is # like the type of the 'variable'. # possible dataTypes are string, boolean, number or [string] (the latter meaning a # list of strings inputType: text # Related to the dataType but somewhat independent, this identifies the type # of widget shown in the ui. Available types are: # - text - the default # - toggle (boolean on/off control) # - textarea (single text value with larger input that allows linebreaks) # - checkbox - multi-value selection from choices # - select - single value selection from choices # - radio - alternative single value selection from choices # - tag - multi-value input ui for entering single-word tags required: true defaultValue: Hello Accelerator # second option: - name: packageName label: "Package Name" description: Name of Java package dataType: string inputType: text defaultValue: somepackage # another option: - name: buildType label: Build Type description: Choose whether to use Maven or Gradle to build the project. dataType: string inputType: select choices: - value: Maven text: Maven (pom.xml) - value: Gradle text: Gradle (build.gradle) # The 'engine' section describes how to take the files from the accelerator # repo root folder and 'transform' them into the contents of a generated project / zip. # transformation operate on the files as a set and can do things like: # - filtering the set of files (i.e. removing / keeping only files that match certain criteria) # - changing the contents of a file (e.g. replacing some strings in them) # - renaming or moving files (changing the paths of the files) engine: # this is the 'global' transformation node. It produces the final set of # files to be zipped and returned from the accelerator. # As input it receives all the files from the acceletor repo root. # The properties in this node dictate how this set of files is # transformed into a final set of files to zip up as the accelerator # result. include: ["**/*.md", "**/*.xml", "**/*.gradle", "**/*.java"] # This globally defined `include` filters the set of files # retaining only those matching a given list of path patterns. # This can ensure that only files in the repo matching the list of # patterns will be seen / considered by the accelerator. exclude: ["**/secret/**"] # This globally defined `exclude` further restricts what files are considered. # This example ensures files in any directory called `secret` are never considered. # Under 'let' you can define additional variables and assign them values # These 'derived symbols' function much like options, but instead of # being supplied from a UI widget, they are computed by the accelerator itself. let: - name: includePoms # name of a symbol, must be camelCase expression: "#buildType == 'Maven'" # <- SpEL expression given as a string. You must take care to use # proper quotes to avoid yaml treating '#' as starting a comment. - name: includeGradle expression: "#buildType == 'Gradle'" merge: # This merge section executes each of its children 'in parallel'. # Each child receives a copy of the current set of input files. # (i.e. the files that are remaining after considering the `include` and `exclude`. # Each of the children thus produces a set of files. # Merge then combines all the files from all the children, as if by overlaying them on top of eachother # in the same directory. If more than one child produces a file with the same path, # this 'conflict' is resolved by dropping the file contents from the earlier child # and keeping only the later one. # merge child 1: this child node wants to contribute 'gradle' files to the final result - condition: "#includeGradle" # this child is disabled if the Gradle option was not selected by the user # A disabled child doesn't contribute anything to the final result. include: ["*.gradle"] # this child only focusses on gradle files (ignoring all other files) # merge child 2: this child wants to contribute 'pom' files to the final result - condition: "#includePoms" include: ["pom.xml"] # merge child 3: this child wants to contribute Java code and README.md to the final result - include: ["**/*.java", "README.md"] # Using: chain you can specify additional transformations to be applied to the set # of files produced by this child (i.e. the `ReplaceText` below is only applied to .java files and README.md) chain: - type: ReplaceText substitutions: - text: "Hello World!" with: "#greeting" chain: # Globally specified chain, works just like the one `from merge child 3`. But because it is global, it # applies transformation to all files globally. # # The chain has a list of child transformations. These transformation are applied after everything else # in the same node (here we are in the 'global node'). # # The children in a chain are applied sequentially. - type: RewritePath regex: (.*)simpleboot(.*) rewriteTo: "#g1 + #packageName + #g2" # SpEL expression. You can use '#g1' and '#g2' to reference 'match groups' - type: ReplaceText substitutions: - text: simpleboot with: "#packageName" onConflict: Fail # other values are 'UseFirst', 'UseLast' or 'Append' # when merging (or really any operation) produces multiple files at the same path # this defines how that conflict is handled. # Fail: raise an error when conflict happens # UseFirst: keep the contents of the first file # UseLast: keep the contents of the last file # Append: keep both as by using `cat <first-file> <second-file>`).