Update mixamo.adoc

Update mixamo.adoc

= Mixamo Animation
:author:
:revnumber:
:revdate: 2017/05/25 13:04
:relfileprefix: ../../
:imagesdir: ../..
:experimental:
ifdef::env-github,env-browser[:outfilesuffix: .adoc]

[NOTE]
====
In the near future the Mixamo website will be undergoing some changes that will have some level of effect upon how you animate your character. The only real difference that Adobe says will happen, with respect to auto-rigging your characters, is you no longer can store the assets on the Mixamo website. See this link:http://blogs.adobe.com/adobecare/2017/05/23/download-assets-from-mixamo/[notice] for more info.
====

== Using Mixamo For Model Animation

With very little effort, you can use Adobes Mixamo to fully animate your Blender models. Once you understand the process that is. This guide uses link:https://www.blender.org/download/[Blender version 2.78c] with its default settings along with the Ogre exporter 0.6.0 found <<jme3/advanced/ogrecompatibility.html,here>>. You will need to have FBX file Importing and Exporting initialized in Blender. This can be found under `menu:File[User Preferences > Add-ons]` in the Info header at the top of the program. Be sure to toggle btn:[Auto Run Python Scripts] in the `menu:User Preferences[File]` tab.

== Prepare to Export

To properly animate your models there are a few rules you must follow.

*  Read the link:https://community.mixamo.com/hc/en-us/articles/210310918-Auto-Rigger-Troubleshooting[Auto-Rig Error Troubleshooting] guide before you do anything else.

*  Clean up your Blender file before exporting. This means you have a game ready model that will become the base for all your animations. The following checklist is provided for your convienence.
[% interactive]
- [ ] You have no Animations.
- [ ] You have no Actions stored in the Dope Sheet Action Editor btn:[Browse Action to be linked] buffer.
- [ ] You have UV Mapped your model.
- [ ] You have one Material named the same as your mesh.
- [ ] You have baked and packed your Texture (ie, your using a texture atlas).
- [ ] You have cleared the UV, Material and Texture buffers of unused images, materials and textures.
- [ ] You have applied the Location, Rotation, and Scale to your model.
- [ ] *MOST IMPORTANT OF ALL*, in the `menu:Properties Panel[Scene Tab > Unit Panel]` set the btn:[Unit of Measure] to Meters and the Length to Metric. Adobe uses centimeters for the FBX exporter and if this is not set the models scale will be unusual to say the least. Besides that, JME3 uses 1 WU = 1 Meter so this will keep things consistant. If you are doing this now, you may have to rescale your model before proceding.

== Export

.Blender
.  In the 3d viewport select your model, it will be high-lighted in orange.
.  In the `Info` header at the top of the program select `menu:File[Export > FBX]`.

.FBX Exporter
.  Enter a file path to export to, usually the same directory as your `.blend` file for simplicity.
.  Enter a file name.
.  In the `Export FBX` panel, located in the bottom left of the open window, under the `Main` tab, toggle on the checkbox `Selected Objects`.
.  Leave the `Scale` at 1 but click the button next to it to turn off btn:[Scale all data]. Failure to do so will destroy the scale of your model. If the button is selected, it will be dark in color.
.  Leave the `Forward` and `Up` axis at the default of `-Z Forward` and `Y Up`.
.  Under `Which kind of object to export` deselect everything but `Mesh`.
.  Under the `Geometries` tab, select `Apply Modifiers`.
.  When you are done, click the btn:[Export FBX] button to export the file.

== Import

.Mixamo
.  Create an link:https://www.mixamo.com/[Mixamo] account and login.
.  Navigate to your `My Assets` directory.
.  Select `Upload`.
.  Navigate to the file to be uploaded or drag and drop it onto the file uploader.

== Auto-Rigger

If everything went well the `Auto-Rigger` will open and your model will be facing you.  If not, fix your model in Blender before proceeding.

.  If the model is facing you click btn:[Next].
.  In this panel you will rig your model. Place the markers as shown in the image.
+
[NOTE]
====
Remember that the model is facing you so its right is on your left.
====

.  Select the LOD you are after. This is based off how many bones you want the hand of the model to have. Feel free to cycle through the options to see what each one does.
.  When you are through click the btn:[Next] button to rig your model.
+
[NOTE]
====
This may take some time and if the model does not appear within 2 minutes something has went wrong and you will have to restart the upload process over. This is a trail blazing  process so keep that in mind.
====

When the model appears, click through to the end of the process.

== Download

Navigate to `My Assets`. You should now see your model in a TPose position. This will be your base model for all animations. We will also use it as our newly rigged model for Blender.

.  Select the TPose model and then click the btn:[Queue Download] button.
.  In the `Download Settings` dialog the `Format` is FBX and `Pose` is TPose.
.  Click the btn:[Queue Download] button.

After the file is ready, it will be in your `Downloads` directory on Mixamo.

Click the btn:[Queue Download] button under `Status`, rename the file to TPose and save the it to your computer.  Preferably in the same directory as your blender file.

== Preparing Blender for Animations

Before you can import any animations from Mixamo, you should have a file that is separate from the model file you exported earlier. Although its not required, it's best to do so. Things can go wrong and you dont want to destroy your model file by accident so it's always best to keep things separate. With that said lets begin.

.Blender
.  In the  `Info` header at the top of the program, select `menu:File[New > Reload Startup]`.
. Select the default cube and delete it.
.  In the `Properties Panel, located at the bottom right, select the `Scene` tab. In the `Units` panel change the `Units of measure` to `Meters` and `Length' to `Metric`.

[TIP]
====
You should create and save a default startup file in Blender.  `menu:File[Save Startup File]`. This way you will not have to constantly redo things. Setting your `Units of measure` is the first thing you should do. You can always restore the default startup file by selecting `menu:File[Load Factory Settings]` at any time.
====


GitHub-32555: Updating location to download the CLI

// Module included in the following assemblies:
//
// * cli_reference/openshift_cli/getting-started.adoc
// * installing/installing_aws/installing-aws-user-infra.adoc
// * installing/installing_aws/installing-aws-customizations.adoc
// * installing/installing_aws/installing-aws-default.adoc
// * installing/installing_aws/installing-aws-government-region.adoc
// * installing/installing_aws/installing-aws-network-customizations.adoc
// * installing/installing_aws/installing-aws-private.adoc
// * installing/installing_aws/installing-aws-vpc.adoc
// * installing/installing_aws/installing-restricted-networks-aws-installer-provisioned.adoc
// * installing/installing_azure/installing-azure-customizations.adoc
// * installing/installing_azure/installing-azure-default.adoc
// * installing/installing_azure/installing-azure-government-region.adoc
// * installing/installing_azure/installing-azure-private.adoc
// * installing/installing_azure/installing-azure-vnet.adoc
// * installing/installing_azure/installing-azure-user-infra.adoc
// * installing/installing_bare_metal/installing-bare-metal.adoc
// * installing/installing_gcp/installing-gcp-customizations.adoc
// * installing/installing_gcp/installing-gcp-private.adoc
// * installing/installing_gcp/installing-gcp-default.adoc
// * installing/installing_gcp/installing-gcp-vpc.adoc
// * installing/installing_gcp/installing-gcp-user-infra.adoc
// * installing/installing_gcp/installing-restricted-networks-gcp-installer-provisioned.adoc
// * installing/install_config/installing-restricted-networks-preparations.adoc
// * installing/installing_vmc/installing-vmc-user-infra.adoc
// * installing/installing_vmc/installing-vmc.adoc
// * installing/installing_vmc/installing-vmc-customizations.adoc
// * installing/installing_vmc/installing-vmc-network-customizations.adoc
// * installing/installing_vmc/installing-restricted-networks-vmc.adoc
// * installing/installing_vsphere/installing-vsphere.adoc
// * installing/installing_vsphere/installing-vsphere-installer-provisioned.adoc
// * installing/installing_vsphere/installing-vsphere-installer-provisioned-customizations.adoc
// * installing/installing_vsphere/installing-vsphere-installer-provisioned-network-customizations.adoc
// * installing/installing_vsphere/installing-restricted-networks-installer-provisioned-vsphere.adoc
// * installing/installing_ibm_z/installing-ibm-z.adoc
// * openshift_images/samples-operator-alt-registry.adoc
// * installing/installing_rhv/installing-rhv-customizations.adoc
// * installing/installing_rhv/installing-rhv-default.adoc
// * updating/updating-restricted-network-cluster.adoc
//
// AMQ docs link to this; do not change anchor

ifeval::["{context}" == "updating-restricted-network-cluster"]
:restricted:
endif::[]

[id="cli-installing-cli_{context}"]
= Installing the OpenShift CLI by downloading the binary

You can install the OpenShift CLI (`oc`) to interact with {product-title} from a
command-line interface. You can install `oc` on Linux, Windows, or macOS.

[IMPORTANT]
====
If you installed an earlier version of `oc`, you cannot use it to complete all
of the commands in {product-title} {product-version}. Download and
install the new version of `oc`.
ifdef::restricted[]
If you are upgrading a cluster in a restricted network, install the `oc` version that you plan to upgrade to.
endif::restricted[]
====

[discrete]
== Installing the OpenShift CLI on Linux

You can install the OpenShift CLI (`oc`) binary on Linux by using the following procedure.

.Procedure

ifdef::openshift-origin[]
. Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
. Download `oc.tar.gz`.
endif::[]
ifndef::openshift-origin[]
. Navigate to the link:https://access.redhat.com/downloads/content/290[{product-title} downloads page] on the Red Hat Customer Portal.
. Select the appropriate version in the *Version* drop-down menu.
. Click *Download Now* next to the *OpenShift v{product-version} Linux Client* entry and save the file.
endif::[]
. Unpack the archive:
+
[source,terminal]
----
$ tar xvzf <file>
----
. Place the `oc` binary in a directory that is on your `PATH`.
+
To check your `PATH`, execute the following command:
+
[source,terminal]
----
$ echo $PATH
----

After you install the OpenShift CLI, it is available using the `oc` command:

[source,terminal]
----
$ oc <command>
----

[discrete]
== Installing the OpenShift CLI on Windows

You can install the OpenShift CLI (`oc`) binary on Windows by using the following procedure.

.Procedure

ifdef::openshift-origin[]
. Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
. Download `oc.zip`.
endif::[]
ifndef::openshift-origin[]
. Navigate to the link:https://access.redhat.com/downloads/content/290[{product-title} downloads page] on the Red Hat Customer Portal.
. Select the appropriate version in the *Version* drop-down menu.
. Click *Download Now* next to the *OpenShift v{product-version} Windows Client* entry and save the file.
endif::[]
. Unzip the archive with a ZIP program.
. Move the `oc` binary to a directory that is on your `PATH`.
+
To check your `PATH`, open the command prompt and execute the following command:
+
[source,terminal]
----
C:\> path
----

After you install the OpenShift CLI, it is available using the `oc` command:

[source,terminal]
----
C:\> oc <command>
----

[discrete]
== Installing the OpenShift CLI on macOS

You can install the OpenShift CLI (`oc`) binary on macOS by using the following procedure.

.Procedure

ifdef::openshift-origin[]
. Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
. Download `oc.tar.gz`.
endif::[]
ifndef::openshift-origin[]
. Navigate to the link:https://access.redhat.com/downloads/content/290[{product-title} downloads page] on the Red Hat Customer Portal.
. Select the appropriate version in the *Version* drop-down menu.
. Click *Download Now* next to the *OpenShift v{product-version} MacOSX Client* entry and save the file.
endif::[]
. Unpack and unzip the archive.
. Move the `oc` binary to a directory on your PATH.
+
To check your `PATH`, open a terminal and execute the following command:
+
[source,terminal]
----
$ echo $PATH
----

After you install the OpenShift CLI, it is available using the `oc` command:

[source,terminal]
----
$ oc <command>
----

ifeval::["{context}" == "updating-restricted-network-cluster"]
:!restricted:
endif::[]

// Module included in the following assemblies:
//
// * cli_reference/openshift_cli/getting-started.adoc
// * installing/installing_aws/installing-aws-user-infra.adoc
// * installing/installing_aws/installing-aws-customizations.adoc
// * installing/installing_aws/installing-aws-default.adoc
// * installing/installing_aws/installing-aws-government-region.adoc
// * installing/installing_aws/installing-aws-network-customizations.adoc
// * installing/installing_aws/installing-aws-private.adoc
// * installing/installing_aws/installing-aws-vpc.adoc
// * installing/installing_aws/installing-restricted-networks-aws-installer-provisioned.adoc
// * installing/installing_azure/installing-azure-customizations.adoc
// * installing/installing_azure/installing-azure-default.adoc
// * installing/installing_azure/installing-azure-government-region.adoc
// * installing/installing_azure/installing-azure-private.adoc
// * installing/installing_azure/installing-azure-vnet.adoc
// * installing/installing_azure/installing-azure-user-infra.adoc
// * installing/installing_bare_metal/installing-bare-metal.adoc
// * installing/installing_gcp/installing-gcp-customizations.adoc
// * installing/installing_gcp/installing-gcp-private.adoc
// * installing/installing_gcp/installing-gcp-default.adoc
// * installing/installing_gcp/installing-gcp-vpc.adoc
// * installing/installing_gcp/installing-gcp-user-infra.adoc
// * installing/installing_gcp/installing-restricted-networks-gcp-installer-provisioned.adoc
// * installing/install_config/installing-restricted-networks-preparations.adoc
// * installing/installing_vmc/installing-vmc-user-infra.adoc
// * installing/installing_vmc/installing-vmc.adoc
// * installing/installing_vmc/installing-vmc-customizations.adoc
// * installing/installing_vmc/installing-vmc-network-customizations.adoc
// * installing/installing_vmc/installing-restricted-networks-vmc.adoc
// * installing/installing_vsphere/installing-vsphere.adoc
// * installing/installing_vsphere/installing-vsphere-installer-provisioned.adoc
// * installing/installing_vsphere/installing-vsphere-installer-provisioned-customizations.adoc
// * installing/installing_vsphere/installing-vsphere-installer-provisioned-network-customizations.adoc
// * installing/installing_vsphere/installing-restricted-networks-installer-provisioned-vsphere.adoc
// * installing/installing_ibm_z/installing-ibm-z.adoc
// * openshift_images/samples-operator-alt-registry.adoc
// * installing/installing_rhv/installing-rhv-customizations.adoc
// * installing/installing_rhv/installing-rhv-default.adoc
// * updating/updating-restricted-network-cluster.adoc
//
// AMQ docs link to this; do not change anchor

ifeval::["{context}" == "updating-restricted-network-cluster"]
:restricted:
endif::[]

[id="cli-installing-cli_{context}"]
= Installing the OpenShift CLI by downloading the binary

You can install the OpenShift CLI (`oc`) to interact with {product-title} from a
command-line interface. You can install `oc` on Linux, Windows, or macOS.

[IMPORTANT]
====
If you installed an earlier version of `oc`, you cannot use it to complete all
of the commands in {product-title} {product-version}. Download and
install the new version of `oc`.
ifdef::restricted[]
If you are upgrading a cluster in a restricted network, install the `oc` version that you plan to upgrade to.
endif::restricted[]
====

[discrete]
== Installing the OpenShift CLI on Linux

You can install the OpenShift CLI (`oc`) binary on Linux by using the following procedure.

.Procedure

ifdef::openshift-origin[]
. Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
. Download `oc.tar.gz`.
endif::[]
ifndef::openshift-origin[]
. Navigate to the link:https://cloud.redhat.com/openshift/install[Infrastructure Provider] page on the {cloud-redhat-com} site.
. Select your infrastructure provider, and, if applicable, your installation type.
. In the *Command line interface* section, select *Linux* from the drop-down menu and click *Download command-line tools*.
endif::[]
. Unpack the archive:
+
[source,terminal]
----
$ tar xvzf <file>
----
. Place the `oc` binary in a directory that is on your `PATH`.
+
To check your `PATH`, execute the following command:
+
[source,terminal]
----
$ echo $PATH
----

After you install the CLI, it is available using the `oc` command:

[source,terminal]
----
$ oc <command>
----

[discrete]
== Installing the OpenShift CLI on Windows

You can install the OpenShift CLI (`oc`) binary on Windows by using the following procedure.

.Procedure

ifdef::openshift-origin[]
. Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
. Download `oc.zip`.
endif::[]
ifndef::openshift-origin[]
. Navigate to the link:https://cloud.redhat.com/openshift/install[Infrastructure Provider] page on the {cloud-redhat-com} site.
. Select your infrastructure provider, and, if applicable, your installation type.
. In the *Command line interface* section, select *Windows* from the drop-down menu and click *Download command-line tools*.
endif::[]
. Unzip the archive with a ZIP program.
. Move the `oc` binary to a directory that is on your `PATH`.
+
To check your `PATH`, open the command prompt and execute the following command:
+
[source,terminal]
----
C:\> path
----

After you install the CLI, it is available using the `oc` command:

[source,terminal]
----
C:\> oc <command>
----

[discrete]
== Installing the OpenShift CLI on macOS

You can install the OpenShift CLI (`oc`) binary on macOS by using the following procedure.

.Procedure

ifdef::openshift-origin[]
. Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
. Download `oc.tar.gz`.
endif::[]
ifndef::openshift-origin[]
. Navigate to the link:https://cloud.redhat.com/openshift/install[Infrastructure Provider] page on the {cloud-redhat-com} site.
. Select your infrastructure provider, and, if applicable, your installation type.
. In the *Command line interface* section, select *MacOS* from the drop-down menu and click *Download command-line tools*.
endif::[]
. Unpack and unzip the archive.
. Move the `oc` binary to a directory on your PATH.
+
To check your `PATH`, open a terminal and execute the following command:
+
[source,terminal]
----
$ echo $PATH
----

After you install the CLI, it is available using the `oc` command:

[source,terminal]
----
$ oc <command>
----

ifeval::["{context}" == "updating-restricted-network-cluster"]
:!restricted:
endif::[]


CAMEL-18031: camel-karaf - Upgrade to 4.4.1

= Apache Camel 3.x Upgrade Guide

This document is for helping you upgrade your Apache Camel application
from Camel 3.x to 3.y. For example if you are upgrading Camel 3.0 to 3.2, then you should follow the guides
from both 3.0 to 3.1 and 3.1 to 3.2.

== Upgrading Camel 3.18 to 3.19

=== camel-api

Added `addClassLoader` method to `org.apache.camel.spi.ClassResolver`.

The default TLS protocol is changed from `TLSv1.2` to `TLSv1.3` in Camel JSSE support.

=== camel-ftp

The default TLS protocol is changed from `TLSv1.2` to `TLSv1.3`.

=== camel-kafka

Updated the documentation to reflect the default TLS protocol in Kafka Clients running on JDK11+
is `TLSv1.2,TLSv1.3` (prefer v1.3 but can fall back to v1.2).

=== camel-netty / camel-netty-http

The default TLS protocol is changed from `TLSv1,TLSv1.1,TLSv1.2` to `TLSv1.2,TLSv1.3`.

=== camel-yaml-dsl

Removed using `template` as a custom alias for `routeTemplate` or `route-template`.

Removed the `tod` custom alias for `toD` or `to-d`.

A route template can now also define a `route` which allows specifying route
options that otherwise is not possible when using `from`.

For example, you can now disable stream-caching, as shown in the snippet below that are from a Kamelet:

[source,yaml]
----
spec:
  template:
    route:
      stream-caching: false
      message-history: true
      from:
        uri: timer:tick
        parameters:
          period: "{{period}}"
        steps:
          - set-body:
              constant: "{{message}}"
          - set-header:
              name: "Content-Type"
              constant: "{{contentType}}"
          - to: kamelet:sink
----

=== camel-salesforce

The URI format for consumer operations has changed. All consumer URIs now use the `subscribe` operation. E.g., `salesforce:subscribe:<topic_name>`, `salesforce:subscribe:event/<event_name>`, `salesforce:subscribe:data/ChangeEvents`.

=== camel-consul

The deprecated options were removed and should be replaced by the following options:

|===
|Deprecated |Replace with

|`connectTimeoutMillis`
|`connectTimeout`

|`readTimeoutMillis`
|`readTimeout`

|`writeTimeoutMillis`
|`writeTimeout`
|===

=== camel-google-bigquery-sql

Parameters in form of `@name` are extracted from the body or message and their type is preserved and translated into corresponding `com.google.cloud.bigquery.StandardSQLTypeName`. See the https://cloud.google.com/java/docs/reference/google-cloud-bigquery/latest/com.google.cloud.bigquery.QueryParameterValue[documentation] for more information. (Conversion to StandardSQLTypeName.STRING was used for each type before)

=== camel-telegram

The component was migrated from the Async HTTP Client to the builtin HTTP client from Java 11 and newer. As such,
* the parameter `clientConfig`, that received an `AsyncHTTPClientConfiguration` instance was removed
* the parameter `client`, that received an `AsyncHttpClient` instance, was modified to receive a HTTPClient instance.

=== xtokenize language

The xtokenize language has moved from `camel-xml-jaxp` to `camel-stax` JAR because
a stax parser was needed anyway to use the language.

=== camel-karaf

Upgraded from Karaf 4.3.x to Karaf 4.4.x, which requires JDK11+.


CAMEL-18665: camel-core: JsseParameters should use the camel provided resource loader instead of its own

= Apache Camel 3.x Upgrade Guide

This document is for helping you upgrade your Apache Camel application
from Camel 3.x to 3.y. For example if you are upgrading Camel 3.0 to 3.2, then you should follow the guides
from both 3.0 to 3.1 and 3.1 to 3.2.

== Upgrading Camel 3.19 to 3.20

=== camel-api

The `org.apache.camel.support.jsse.SSLContextParameters` is now using `ResourceLoader` from `CamelContext`
to load keystore and other resources in a standard way. Therefore, the `SSLContextParameters` now must have been pre-configured
with a `CamelContext` otherwise an exception is thrown.

=== camel-jsonpath

There is a new option `unpackArray` that unpacks a single-element Json array, matched by a Jsonpath, into an object. This option is disabled by default (this behaviour was enabled by default in previous Camel versions). There is a new expression `jsonpathUnpack(String text, Class<?> resultType)` that makes use of this new option.

= Apache Camel 3.x Upgrade Guide

This document is for helping you upgrade your Apache Camel application
from Camel 3.x to 3.y. For example if you are upgrading Camel 3.0 to 3.2, then you should follow the guides
from both 3.0 to 3.1 and 3.1 to 3.2.

== Upgrading Camel 3.19 to 3.20

=== camel-jsonpath

There is a new option `unpackArray` that unpacks a single-element Json array, matched by a Jsonpath, into an object. This option is disabled by default (this behaviour was enabled by default in previous Camel versions). There is a new expression `jsonpathUnpack(String text, Class<?> resultType)` that makes use of this new option.


DBZ-1452 Fix typo

DBZ-1452 Fix typo

= New Record State Extraction
include::../_attributes.adoc[]
:toc:
:toc-placement: macro
:linkattrs:
:icons: font
:source-highlighter: highlight.js

toc::[]

[NOTE]
====
This SMT is supported only for the SQL database connectors, it does not work with the MongoDB connector.
See xref:configuration/mongodb-event-flattening.adoc[here] for the MongoDB equivalent to this SMT.
====

Debezium generates data change events in a form of a complex message structure.
Each event consists of three parts:

* metadata, comprising the type of operation, information on the event source, a timestamp, and optionally transaction information
* the row data before change
* the row data after change

E.g. the general message structure for an `update` change looks like this:

[source,json,indent=0]
----
{
	"op": "u",
	"source": {
		...
	},
	"ts_ms" : "...",
	"before" : {
		"field1" : "oldvalue1",
		"field2" : "oldvalue2"
	},
	"after" : {
		"field1" : "newvalue1",
		"field2" : "newvalue2"
	}
}
----

More details about the message structure are provided in xref:connectors/index.adoc[the documentation for each connector].

This format allows the user to get most information about changes happening in the system.
The downside of using the complex format is that other connectors or other parts of the Kafka ecosystem usually expect the data in a simple message format that can generally be described like so:

[source,json,indent=0]
----
{
	"field1" : "newvalue1",
	"field2" : "newvalue2"
}
----

Debezium provides https://kafka.apache.org/documentation/#connect_transforms[a single message transformation] that crosses the bridge between the complex and simple formats, the https://github.com/debezium/debezium/blob/master/debezium-core/src/main/java/io/debezium/transforms/ExtractNewRecordState.java[ExtractNewRecordState] SMT.

The SMT provides three main functions.
It

* extracts the `after` field from change events and replaces the original event just with this part
* optionally filters delete and tombstone records, as per the capabilities and requirements of downstream consumers
* optionally adds metadata fields from the change event to the outgoing flattened record
* optionally add metadata fields to the header

The SMT can be applied either to a source connector (Debezium) or a sink connector.
We generally recommend to apply the transformation on the sink side as it means that the messages stored in Apache Kafka will contain the whole context.
The final decision depends on use case for each user.

== Configuration
The configuration is a part of source/sink task connector and is expressed in a set of properties:

[source]
----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.drop.tombstones=false
transforms.unwrap.delete.handling.mode=rewrite
transforms.unwrap.add.source.fields=table,lsn
----

=== Record filtering for delete records

The SMT provides a special handling for events that signal a `delete` operation.
When a `DELETE` is executed on a datasource then Debezium generates two events:

* a record with `d` operation that contains only old row data
* (optionally) a record with `null` value and the same key (a "tombstone" message). This record serves as a marker for Apache Kafka that all messages with this key can be removed from the topic during https://kafka.apache.org/documentation/#compaction[log compaction].

Upon processing these two records, the SMT can pass on the `d` record as is,
convert it into another tombstone record or drop it.
The original tombstone message can be passed on as is or also be dropped.

[NOTE]
====
The SMT by default filters out *both* delete records as widely used sink connectors do not support handling of tombstone messages at this point.
====

=== Adding metadata fields to the message

The SMT can optionally add metadata fields from the original change event to the final flattened record. This functionality can be used to add things like the operation or the table from the change event, or connector-specific fields like the Postgres LSN field. For more information on what's available see xref:connectors/index.adoc[the documentation for each connector].

In case of duplicate field names (e.g. "ts_ms" exists twice), the struct should be specified to get the correct field (e.g. "source.ts_ms"). The fields will be prefixed with "\\__" or "__<struct>_", depending on the specification of the struct. Please use a comma separated list without spaces.

For example, the configuration

----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.add.fields=op,table,lsn,source.ts_ms
----

will add

----
{ "__op" : "c", __table": "MY_TABLE", "__lsn": "123456789", "__source_ts_ms" : "123456789", ...}
----

to the final flattened record.

For `DELETE` events, this option is only supported when the `delete.handling.mode` option is set to "rewrite".

=== Adding metadata fields to the header

The SMT can optionally add metadata fields from the original change event to the header of the final flattened record. This functionality can be used to add things like the operation or the table from the change event, or connector-specific fields like the Postgres LSN field. For more information on what's available see xref:connectors/index.adoc[the documentation for each connector].

In case of duplicate field names (e.g. "ts_ms" exists twice), the struct should be specified to get the correct field (e.g. "source.ts_ms"). The fields will be prefixed with "\\__" or "__<struct>_", depending on the specification of the struct. Please use a comma separated list without spaces.

For example, the configuration

----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.add.headers=op,table,lsn,source.ts_ms
----

will add headers `__op`, `__table`, `__lsn` and `__source_ts_ms` to the outgoing record.

=== Determine original operation  [DEPRECATED]

_The `operation.header` option is deprecated and scheduled for removal. Please use add.headers instead. If both add.headers and operation.header are specified, the latter will be ignored._

When a message is flattened the final result won't show whether it was an insert, update or first read
(deletions can be detected via tombstones or rewrites, see link:#configuration_options[Configuration options]).

To solve this problem Debezium offers an option to propagate the original operation via a header added to the message.
To enable this feature the option `operation.header` must be set to `true`.

[source]
----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.operation.header=true
----

The possible values are the ones from the `op` field of the original change event.

=== Adding source metadata fields [DEPRECATED]

_The `add.source.fields` option is deprecated and scheduled for removal. Please use add.fields instead. If both add.fields and add.source.fields are specified, the latter will be ignored._

The SMT can optionally add metadata fields from the original change event's `source` structure to the final flattened record (prefixed with "__"). This functionality can be used to add things like the table from the change event, or connector-specific fields like the Postgres LSN field. For more information on what's available in the source structure see xref:connectors/index.adoc[the documentation for each connector].

For example, the configuration

----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.add.source.fields=table,lsn
----

will add

----
{ "__table": "MY_TABLE", "__lsn": "123456789", ...}
----

to the final flattened record.

For `DELETE` events, this option is only supported when the `delete.handling.mode` option is set to "rewrite".

[[configuration_options]]
== Configuration options
[cols="35%a,10%a,55%a",options="header"]
|=======================
|Property
|Default
|Description

|`drop.tombstones`
|`true`
|The SMT removes the tombstone generated by Debezium from the stream.

|`delete.handling.mode`
|`drop`
|The SMT can `drop` (the default), `rewrite` or pass delete events (`none`). The rewrite mode will add a `__deleted` column with true/false values based on record operation.

|`route.by.field`
|
|The column which determines how the events will be routed, the value will the topic name; obtained from the old record state for delete events, and from the new record state otherwise

|`add.fields`
|
|Specify a list of metadata fields to add to the flattened message. In case of duplicate field names (e.g. "ts_ms" exists twice), the struct should be specified to get the correct field (e.g. "source.ts_ms"). The fields will be prefixed with "\\__" or "__<struct>__", depending on the specification of the struct. Please use a comma separated list without spaces.

|`add.headers`
|
|Specify a list of metadata fields to add to the header of the flattened message. In case of duplicate field names (e.g. "ts_ms" exists twice), the struct should be specified to get the correct field (e.g. "source.ts_ms"). The fields will be prefixed with "\\__" or "__<struct>__", depending on the specification of the struct. Please use a comma separated list without spaces.

|`operation.header` DEPRECATED
|`false`
|_This option is deprecated and scheduled for removal. Please use add.headers instead. If both add.headers and operation.header are specified, the latter will be ignored._

The SMT adds the event operation (as obtained from the `op` field of the original record) as a message header.

|`add.source.fields` DEPRECATED
|
|_This option is deprecated and scheduled for removal. Please use add.fields instead. If both add.fields and add.source.fields are specified, the latter will be ignored._

Fields from the change event's `source` structure to add as metadata (prefixed with "__") to the flattened record. Please no
|=======================

= New Record State Extraction
include::../_attributes.adoc[]
:toc:
:toc-placement: macro
:linkattrs:
:icons: font
:source-highlighter: highlight.js

toc::[]

[NOTE]
====
This SMT is supported only for the SQL database connectors, it does not work with the MongoDB connector.
See xref:configuration/mongodb-event-flattening.adoc[here] for the MongoDB equivalent to this SMT.
====

Debezium generates data change events in a form of a complex message structure.
Each events consists of three parts:

* metadata, comprising the type of operation, information on the event source, a timestamp, and optionally transaction information
* the row data before change
* the row data after change

E.g. the general message structure for an `update` change looks like this:

[source,json,indent=0]
----
{
	"op": "u",
	"source": {
		...
	},
	"ts_ms" : "...",
	"before" : {
		"field1" : "oldvalue1",
		"field2" : "oldvalue2"
	},
	"after" : {
		"field1" : "newvalue1",
		"field2" : "newvalue2"
	}
}
----

More details about the message structure are provided in xref:connectors/index.adoc[the documentation for each connector].

This format allows the user to get most information about changes happening in the system.
The downside of using the complex format is that other connectors or other parts of the Kafka ecosystem usually expect the data in a simple message format that can generally be described like so:

[source,json,indent=0]
----
{
	"field1" : "newvalue1",
	"field2" : "newvalue2"
}
----

Debezium provides https://kafka.apache.org/documentation/#connect_transforms[a single message transformation] that crosses the bridge between the complex and simple formats, the https://github.com/debezium/debezium/blob/master/debezium-core/src/main/java/io/debezium/transforms/ExtractNewRecordState.java[ExtractNewRecordState] SMT.

The SMT provides three main functions.
It

* extracts the `after` field from change events and replaces the original event just with this part
* optionally filters delete and tombstone records, as per the capabilities and requirements of downstream consumers
* optionally adds metadata fields from the change event to the outgoing flattened record
* optionally add metadata fields to the header

The SMT can be applied either to a source connector (Debezium) or a sink connector.
We generally recommend to apply the transformation on the sink side as it means that the messages stored in Apache Kafka will contain the whole context.
The final decision depends on use case for each user.

== Configuration
The configuration is a part of source/sink task connector and is expressed in a set of properties:

[source]
----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.drop.tombstones=false
transforms.unwrap.delete.handling.mode=rewrite
transforms.unwrap.add.source.fields=table,lsn
----

=== Record filtering for delete records

The SMT provides a special handling for events that signal a `delete` operation.
When a `DELETE` is executed on a datasource then Debezium generates two events:

* a record with `d` operation that contains only old row data
* (optionally) a record with `null` value and the same key (a "tombstone" message). This record serves as a marker for Apache Kafka that all messages with this key can be removed from the topic during https://kafka.apache.org/documentation/#compaction[log compaction].

Upon processing these two records, the SMT can pass on the `d` record as is,
convert it into another tombstone record or drop it.
The original tombstone message can be passed on as is or also be dropped.

[NOTE]
====
The SMT by default filters out *both* delete records as widely used sink connectors do not support handling of tombstone messages at this point.
====

=== Adding metadata fields to the message

The SMT can optionally add metadata fields from the original change event to the final flattened record. This functionality can be used to add things like the operation or the table from the change event, or connector-specific fields like the Postgres LSN field. For more information on what's available see xref:connectors/index.adoc[the documentation for each connector].

In case of duplicate field names (e.g. "ts_ms" exists twice), the struct should be specified to get the correct field (e.g. "source.ts_ms"). The fields will be prefixed with "\\__" or "__<struct>_", depending on the specification of the struct. Please use a comma separated list without spaces.

For example, the configuration

----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.add.fields=op,table,lsn,source.ts_ms
----

will add

----
{ "__op" : "c", __table": "MY_TABLE", "__lsn": "123456789", "__source_ts_ms" : "123456789", ...}
----

to the final flattened record.

For `DELETE` events, this option is only supported when the `delete.handling.mode` option is set to "rewrite".

=== Adding metadata fields to the header

The SMT can optionally add metadata fields from the original change event to the header of the final flattened record. This functionality can be used to add things like the operation or the table from the change event, or connector-specific fields like the Postgres LSN field. For more information on what's available see xref:connectors/index.adoc[the documentation for each connector].

In case of duplicate field names (e.g. "ts_ms" exists twice), the struct should be specified to get the correct field (e.g. "source.ts_ms"). The fields will be prefixed with "\\__" or "__<struct>_", depending on the specification of the struct. Please use a comma separated list without spaces.

For example, the configuration

----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.add.headers=op,table,lsn,source.ts_ms
----

will add headers `__op`, `__table`, `__lsn` and `__source_ts_ms` to the outgoing record.

=== Determine original operation  [DEPRECATED]

_The `operation.header` option is deprecated and scheduled for removal. Please use add.headers instead. If both add.headers and operation.header are specified, the latter will be ignored._

When a message is flattened the final result won't show whether it was an insert, update or first read
(deletions can be detected via tombstones or rewrites, see link:#configuration_options[Configuration options]).

To solve this problem Debezium offers an option to propagate the original operation via a header added to the message.
To enable this feature the option `operation.header` must be set to `true`.

[source]
----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.operation.header=true
----

The possible values are the ones from the `op` field of the original change event.

=== Adding source metadata fields [DEPRECATED]

_The `add.source.fields` option is deprecated and scheduled for removal. Please use add.fields instead. If both add.fields and add.source.fields are specified, the latter will be ignored._

The SMT can optionally add metadata fields from the original change event's `source` structure to the final flattened record (prefixed with "__"). This functionality can be used to add things like the table from the change event, or connector-specific fields like the Postgres LSN field. For more information on what's available in the source structure see xref:connectors/index.adoc[the documentation for each connector].

For example, the configuration

----
transforms=unwrap,...
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.add.source.fields=table,lsn
----

will add

----
{ "__table": "MY_TABLE", "__lsn": "123456789", ...}
----

to the final flattened record.

For `DELETE` events, this option is only supported when the `delete.handling.mode` option is set to "rewrite".

[[configuration_options]]
== Configuration options
[cols="35%a,10%a,55%a",options="header"]
|=======================
|Property
|Default
|Description

|`drop.tombstones`
|`true`
|The SMT removes the tombstone generated by Debezium from the stream.

|`delete.handling.mode`
|`drop`
|The SMT can `drop` (the default), `rewrite` or pass delete events (`none`). The rewrite mode will add a `__deleted` column with true/false values based on record operation.

|`route.by.field`
|
|The column which determines how the events will be routed, the value will the topic name; obtained from the old record state for delete events, and from the new record state otherwise

|`add.fields`
|
|Specify a list of metadata fields to add to the flattened message. In case of duplicate field names (e.g. "ts_ms" exists twice), the struct should be specified to get the correct field (e.g. "source.ts_ms"). The fields will be prefixed with "\\__" or "__<struct>__", depending on the specification of the struct. Please use a comma separated list without spaces.

|`add.headers`
|
|Specify a list of metadata fields to add to the header of the flattened message. In case of duplicate field names (e.g. "ts_ms" exists twice), the struct should be specified to get the correct field (e.g. "source.ts_ms"). The fields will be prefixed with "\\__" or "__<struct>__", depending on the specification of the struct. Please use a comma separated list without spaces.

|`operation.header` DEPRECATED
|`false`
|_This option is deprecated and scheduled for removal. Please use add.headers instead. If both add.headers and operation.header are specified, the latter will be ignored._

The SMT adds the event operation (as obtained from the `op` field of the original record) as a message header.

|`add.source.fields` DEPRECATED
|
|_This option is deprecated and scheduled for removal. Please use add.fields instead. If both add.fields and add.source.fields are specified, the latter will be ignored._

Fields from the change event's `source` structure to add as metadata (prefixed with "__") to the flattened record. Please no
|=======================


More notes and small bash fixes

More notes and small bash fixes

= Bedework Enterprise Calendar System
:title: Bedework Enterprise Calendar System
:doctype: standard
:imagesdir: ./resources/
:toc: left
:toclevels: 3
:sectnumlevels: 3

:overview-dir: overview/
:admin-dir: administrators/
:deployer-dir: deployers/
:dev-dir: development/
:older-dir: older/

:sectnums!:

include::foreword.adoc[]
include::introduction.adoc[]

:sectnums:

[[overview]]
== Overview

include::{overview-dir}features.adoc[]
include::{overview-dir}release-notes.adoc[]
include::{overview-dir}issues.adoc[]
include::{overview-dir}system-overview.adoc[]
include::{overview-dir}history.adoc[]
include::{overview-dir}standards.adoc[]
include::{overview-dir}technologies.adoc[]

== General Administration
include::{admin-dir}reindex.adoc[]

== Public Administrator Features
include::{admin-dir}addTopicalArea.adoc[]
include::{admin-dir}eventRegistration.adoc[]
include::{admin-dir}subscriptions.adoc[]
include::{admin-dir}authusers.adoc[]

== Deployers
include::{deployer-dir}installing.adoc[]
include::{deployer-dir}installing-quickstart.adoc[]
include::{deployer-dir}deploying-servers.adoc[]
include::{deployer-dir}configure-wildfly.adoc[]
include::{deployer-dir}databases.adoc[]
include::{deployer-dir}elasticsearch.adoc[]
include::{deployer-dir}eventRegistration.adoc[]
include::{deployer-dir}synch-engine.adoc[]
include::{deployer-dir}locations.adoc[]

== Development
include::{dev-dir}todo.adoc[]
include::{dev-dir}caldavtester.adoc[]

[[older-releases]]
== Older Bedework Versions (3.10 and Prior)
include::{older-dir}releases.adoc[]

= Bedework Enterprise Calendar System
:title: Bedework Enterprise Calendar System
:doctype: standard
:imagesdir: ./resources/
:toc: left
:toclevels: 3
:sectnumlevels: 3

:overview-dir: overview/
:admin-dir: administrators/
:deployer-dir: deployers/
:dev-dir: development/
:older-dir: older/

:sectnums!:

include::foreword.adoc[]
include::introduction.adoc[]

:sectnums:

[[overview]]
== Overview

include::{overview-dir}features.adoc[]
include::{overview-dir}release-notes.adoc[]
include::{overview-dir}issues.adoc[]
include::{overview-dir}system-overview.adoc[]
include::{overview-dir}history.adoc[]
include::{overview-dir}standards.adoc[]
include::{overview-dir}technologies.adoc[]

== General Administration
include::{admin-dir}reindex.adoc[]

== Public Administrator Features
include::{admin-dir}eventRegistration.adoc[]
include::{admin-dir}subscriptions.adoc[]
include::{admin-dir}authusers.adoc[]

== Deployers
include::{deployer-dir}installing.adoc[]
include::{deployer-dir}installing-quickstart.adoc[]
include::{deployer-dir}deploying-servers.adoc[]
include::{deployer-dir}configure-wildfly.adoc[]
include::{deployer-dir}databases.adoc[]
include::{deployer-dir}elasticsearch.adoc[]
include::{deployer-dir}eventRegistration.adoc[]
include::{deployer-dir}synch-engine.adoc[]
include::{deployer-dir}locations.adoc[]

== Development
include::{dev-dir}todo.adoc[]
include::{dev-dir}caldavtester.adoc[]

[[older-releases]]
== Older Bedework Versions (3.10 and Prior)
include::{older-dir}releases.adoc[]


Simple input tutorial

Simple input tutorial

= Chronicle-Queue-Sample

First open the module `Chronicle-Queue-Sample`.
Go to the sub-module `simple-input`, then `src`, `main`, `java` and `net.openhft.chronicle.queue.simple.input`.

This will that you to `InputMain.java` and `OutputMain.java` java classes.
This is one of the simple demonstrations of how Chronicle Queue can be used.

Select `InputMain` from the side bar and run `InputMain.java` by right-clicking on the code and selecting `Run 'InputMain.main()'`.
After the code has been run the first time using this method, the green arrow in the top right of the screen can be used to run that code again the next time.

A window at the bottom of the screen will appear with the words `type something`, as the code has instructed it to do.

You may write anything you wish in this window and your `Enter` button to submit it.

The program will then again ask you to `type something`, and again you should type another word.

This program is set on a loop and will continue to pose this same instruction until it is broken.
This is done by not writing anything and leaving the next line blank before pressing `Enter`.

It is recommended that you type at least three words for the sake of this example.

The excitement doesn't end here, however.
You must then open `OutputMain.java` and run that by right-clicking on the code, the same way you ran `InputMain.java`.

A new window will appear next to the `InputMain` one, simple listing the content you previously entered.

This demonstrates a program that can store and recall data that is submitted in another place.

= Chronicle-Queue-Sample

First open the module***** `Chronicle-Queue-Sample`. Go to the sub-module `simple-input`, then `src`, `main`, `java` and `net.openhft.chronicle.queue.simple.input`.

This will that you to `InputMain.java` and `OutputMain.java` java classes.***** This is one of the simple demonstrations of how Chronicle Queue can be used.

Select `InputMain` from the side bar and run `InputMain.java` by right-clicking on the code and selecting `Run 'InputMain.main()'`.
After the code has been run the first time using this method, the green arrow in the top right of the screen can be used to run that code again the next time.

A window at the bottom of the screen will appear with the words `type something`, as the code has instructed it to do.

You may write anything you wish in this window and your `Enter` button to submit it.

The program will then again ask you to `type something`, and again you should type another word.

This program is set on a loop and will continue to pose this same instruction until it is broken.
This is done by not writing anything and leaving the next line blank before pressing `Enter`.

It is recommended that you type at least three words for the sake of this example.

The excitement doesn't end here, however.
You must then open `OutputMain.java` and run that by right-clicking on the code, the same way you ran `InputMain.java`.

A new window will appear next to the `InputMain` one, simple listing the content you previously entered.


Update 2015-04-15-Montar-el-entorno-de-trabajo-adecuado-12.adoc


Update 2018-02-14-Fencing-RHV-or-o-Virt-nested-hypervisors.adoc


Update 2016-03-06-Study-plan.adoc

Update 2016-03-06-Study-plan.adoc


Update 2016-12-22-SkyRC-Q200-Review.adoc

= SkyRC Q200 - Review
:published_at: 2016-12-22
:hp-tags: SkyRC, Charger, Q200,
Octávio Maia <octaviojmaia@gmail.com>

image::http://www.skyrc.com/image/data/980px_en/Q200/01.jpg[]

== Introduction

Welcome to my review of the SkyRC Q200 review. +
Before heading further into this review, I’d like to thank Shawn Tong over at SkyRC for making this review possible and Pedro over at Ibermodel for sending the actual unit for review!

== Overview

Let’s firstly take a look at the box that the Q200 comes in.

*[BOX PICTURES]*

It’s a well built box that includes all the information you might need to know printed on the box.

*Specifications:*

 * AC Input: 100 – 240 V (up to 200W)
 * DC Input: 11 – 18 V (up to 300W)
 * Current: Max. 200mA / cell
 * LiPo / LiFe / LiHV / Li-Ion / NiMH / NiCD / Pb
 * Product weight: 1.3 kg
 * Package weight: 2.1 kg
 * Product size (L x W x H): 19.70 x 18.20 x 7.10 cm
 * Package size (L x W x H): 22.00 x 20.00 x 8.00 cm
 * 4 charging ports, each with it’s own temperature sensor port alongside with the correspondent balance port.
 * MicroUSB connector for the PC Link Software
 * USB Power output rated at 5V/2.1A

== Unboxing

Inside the box we'll find the following items:

 * SkyRC Q200 Charger
 * Manual
 * 4 x XH balance boards
 * 4 x leads with XT60 connectors (all the XT60 leads come with a plastic holder that make plugging in your leads much easier. A nice touch)
 * 2 x leads with no connector (useful for making your owns connectors, e.g: Deans connector, DC jack, etc.)
 * Power cable

*[ACCESSORIES PICTURES]* +
But what is the big deal about this new charger from SkyRC? +
It’s the latest 4-port charger from SkyRC, making it very useful for charging multiple LiPo batteries at the same time without resorting to parallel boards that can often cause unbalanced cells or other issues.

This is a very well built charger, and while made of platic, it's a very high quality finish. +
I rather enjoy the plastic unit instead of aluminum due to the impossibility of accidentally shorting something on the metal frame.

All the cables are made of high quality silicone wire, which is a must nowadays. +
The manual is also very well printed and has everything needed in case you are unware how the charger works.

== Charging

*[BATTERIES CHARGING PICTURES]* +
The charger has a power switch, which I consider very useful and also has two cooling fans, which while charging are very silent, but when discharging 4 batteries at the same time they can ramp up quite easily. +
The Q200 main advantage over it’s competition is it’s compact size and the 4 completely independent charging ports, that can easily be configured to charge different chemistry batteries at the same time, without causing issues to other packs. This is very useful when charging LiPo and Li-Ion 18650 cells. It’s also LiHV compatible, which not all chargers are.  +

*[LIPO AND LI ION CHARGING PIC]* +

=== Field Charging

It also allows for AC input without the need for a power supply, due to its integrated power supply. It’s also capable of using DC current, which can be useful for field charging with a car battery or even a big LiPo battery. +

*[POWERBANK PIC]*

=== Charging procedure

It’s a very intuitive charger, and can be controlled like all standard 4-button chargers, with another button to control which channel is selected. Everything is displayed on a very nice quality colour screen, with a resolution of 480x320 pixels (sadly this is not a touch screen, but for the price point it's understandable). +
It also allows for customizable power outputs between channels A/C and B/D when using AC mode. +
By default each channel is set at 50W, but can easily be changed. This can be useful if you’re charging a big mAh LiPo battery, like a 5000mAh unit since you can set appropriate wattage values for charging.  +
Once you setup the desired wattage on channel B, for example 79W, then channel D will automatically be set to 21W due to the 100W restriction. The same happens on channels A and C.

image::https://github.com/OctavioMaia/octaviomaia.github.io/blob/master/images/watts.PNG?raw=trueG[]

Channels A/C can be used to charge up to 10A, while C/D can charge up to 5A. +

=== Discharging

Discharge rates are limited to 10W per channel, which for 4s is 0.6A per channel. +

*[DISCARGE PIC]*

== Extra Features

=== IR Measurement

Along with standard features like Battery meter, it also supports IR Resistance measurement, which is useful for battery maintenance and tracking. +
*[IR MEASUREMENT picture]*

=== Bluetooth App

Another feature of the Q200 charger is that it has its own Bluetooth app for smartphones. +
From what I’ve been able to tell Bluetooth is always on, although it would be nice if it had an option to turn it off in the settings. +
Although thinking I would rarely use this app I find it very useful and have come to use it very often. I have set a QR code for LiPo balance charging, which I use often with the app. +
All I have to do is I scan the QR code and it automatically starts balance charging my 4S LiPo batteries at 1.3A, which is very useful and straight-forward.

*[BLUETOOTH APP]*

=== Device charging

This device also supports charging any device that can be charged using an USB Port. It outputs 5V/2.1A which is more than enough for charging your typical smartphone or tablet device. Due to outputting 2.1A it can also charge more power dense devices, like powerbanks.

*[DEVICE CHARGING]*

== Ending thoughts

What can I say about this charger? Is it good enough to recommend purchasing? +
Shortly, yes, definitely!

*Pros:*

	* Well built.
    * Allows up to 4 batteries charging at the same time.
    * LiHV support.
    * Built-in power supply!
    * Compact size.
    * Supports AC and DC current.
    * Beautiful and intuitive screen.
    * Bluetooth app support.
    * QR Code support.

*Cons:*

	* No way to turn off Bluetooth (minor complaint here)
    * No touch screen.
    * 200W may not be enough when charging several high capacity LiPo batteries at 1C.

If you're interested in purchasing a SkyRC Q200, be sure to reach out to Pedro over at Ibermodel. He'll be sure to have one shipped to you at a very affordable price.

Email: pedro@ibermodel.es +
Telephone: 945601444 (Spain)

= SkyRC Q200 - Review
:published_at: 2016-12-22
:hp-tags: SkyRC, Charger, Q200,
Octávio Maia <octaviojmaia@gmail.com>

image::http://www.skyrc.com/image/data/980px_en/Q200/01.jpg[]

== Introduction

Welcome to my review of the SkyRC Q200 review. +
Before heading further into this review, I’d like to thank Shawn Tong over at SkyRC for sending me this charger and making all of this possible!

== Overview

Let’s firstly take a look at the box that the Q200 comes in.

*[BOX PICTURES]*

It’s a well built box that includes all the information you might need to know printed on the box.

*Specifications:*

 * AC Input: 100 – 240 V (up to 200W)
 * DC Input: 11 – 18 V (up to 300W)
 * Current: Max. 200mA / cell
 * LiPo / LiFe / LiHV / Li-Ion / NiMH / NiCD / Pb
 * Product weight: 1.3 kg
 * Package weight: 2.1 kg
 * Product size (L x W x H): 19.70 x 18.20 x 7.10 cm
 * Package size (L x W x H): 22.00 x 20.00 x 8.00 cm
 * 4 charging ports, each with it’s own temperature sensor port alongside with the correspondent balance port.
 * MicroUSB connector for the PC Link Software
 * USB Power output rated at 5V/2.1A

=== Unboxing

Inside the box we'll find the following items:

 * SkyRC Q200 Charger
 * Manual
 * 4 x XH balance boards
 * 4 x leads with XT60 connectors (all the XT60 leads come with a plastic holder that make plugging in your leads much easier. A nice touch)
 * 2 x leads with no connector (useful for making your owns connectors, e.g: Deans connector, DC jack, etc.)
 * Power cable

*[ACCESSORIES PICTURES]* +
But what is the big deal about this new charger from SkyRC? +
It’s the latest 4-port charger from SkyRC, making it very useful for charging multiple LiPo batteries at the same time without resorting to parallel boards that can often cause unbalanced cells or other issues. +

=== Charging

*[BATTERIES CHARGING PICTURES]* +
The charger has a power switch, which I consider very useful and also has two cooling fans, which while charging are very silent, but when discharging 4 batteries at the same time they can ramp up quite easily. +
The Q200 main advantage over it’s competition is it’s compact size and the 4 completely independent charging ports, that can easily be configured to charge different chemistry batteries at the same time, without causing issues to other packs. This is very useful when charging LiPo and Li-Ion 18650 cells. It’s also LiHV compatible, which not all chargers are.  +

*[LIPO AND LI ION CHARGING PIC]* +

==== Field Charging

It also allows for AC input without the need for a power supply, due to its integrated power supply. It’s also capable of using DC current, which can be useful for field charging with a car battery or even a big LiPo battery. +

*[POWERBANK PIC]*

==== Charging procedure

It’s a very intuitive charger, and can be controlled like all standard 4-button chargers, with another button to control which channel is selected. Everything is displayed on a very nice quality colour screen, with a resolution of 480x320 pixels. +
It also allows for customizable power outputs between channels A/C and B/D when using AC mode. +
By default each channel is set at 50W, but can easily be changed. This can be useful if you’re charging a big mAh LiPo battery, like a 5000mAh unit since you can set appropriate wattage values for charging.  +
Once you setup the desired wattage on channel A, for example 79W, then channel C will automatically be set to 21W due to the 100W restriction.

image::https://github.com/OctavioMaia/octaviomaia.github.io/blob/master/images/watts.PNG?raw=trueG[]

Channels A/C can be used to charge up to 10A, while C/D can charge up to 5A. +

==== Discharging

Discharge rates are limited to 10W per channel, which for 4s is 0.6A per channel. +

*[DISCARGE PIC]*

== Extra Features

=== IR Measurement

Along with standard features like Battery meter, it also supports IR Resistance measurement, which is useful for battery maintenance and tracking. +
*[IR MEASUREMENT picture]*

=== Bluetooth App

Another feature of the Q200 charger is that it has its own Bluetooth app for smartphones. +
From what I’ve been able to tell Bluetooth is always on, although it would be nice if it had an option to turn it off in the settings. +
Although thinking I would rarely use this app I find it very useful and have come to use it very often. I have set a QR code for LiPo balance charging, which I use often with the app. +
All I have to do is I scan the QR code and it automatically starts balance charging my 4S LiPo batteries at 1.3A, which is very useful and straight-forward.

*[BLUETOOTH APP]*

=== Device charging


Make style changes in CNI content

Make style changes in CNI content

- https://bugzilla.redhat.com/show_bug.cgi?id=1708542

// Module included in the following assemblies:
//
// * networking/managing_multinetworking.adoc

[id="multinetwork-creating-first-attachments-{context}"]
= Creating additional network interfaces

Additional interfaces for Pods are defined in CNI configurations that are stored
as Custom Resources (CRs). These CRs can be created, listed, edited, and deleted
using the `oc` tool.

The following procedure configures a `macvlan` interface on a Pod. This
configuration might not apply to all production environments, but you can use
the same procedure for other CNI plug-ins.

== Creating a CNI configuration for an additional interface as a CR

[NOTE]
====
If you want to attach an additional interface to a Pod, the CR that defines the
interface must be in the same project (namespace) as the Pod.
====

. Create a project to store CNI configurations as CRs and the Pods that will use
the CRs.
+
----
$ oc new-project multinetwork-example
----

. Create the CR that will define an additional network interface. Create a YAML
file called `macvlan-conf.yaml` with the following contents:
+
[source,yaml]
----
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition <1>
metadata:
  name: macvlan-conf <2>
spec:
  config: '{ <3>
      "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "eth0",
      "mode": "bridge",
      "ipam": {
        "type": "host-local",
        "subnet": "192.168.1.0/24",
        "rangeStart": "192.168.1.200",
        "rangeEnd": "192.168.1.216",
        "routes": [
          { "dst": "0.0.0.0/0" }
        ],
        "gateway": "192.168.1.1"
      }
    }'
----
+
<1> `kind: NetworkAttachmentDefinition`. This is the name for the CR where this
configuration will be stored. It is a custom extension of Kubernetes that
defines how networks are attached to Pods.
<2> `name` maps to the annotation, which is used in the next step.
<3> `config`: The CNI configuration is packaged in the `config` field.
+
The configuration is specific to a plug-in, which enables `macvlan`. Note the
`type` line in the CNI configuration portion. Aside from the IPAM (IP address
management) parameters for networking, in this example the `master` field must
reference a network interface that resides on the node(s) hosting the Pod(s).

. Run the following command to create the CR:
+
----
$ oc create -f macvlan-conf.yaml
----

[NOTE]
====
This example is based on a `macvlan` CNI plug-in. Note that in AWS environments,
macvlan traffic might be filtered and, therefore, might not reach the desired
destination.
====

== Managing the CRs for additional interfaces

You can manage the CRs for additional interfaces using the `oc` CLI.

Use the following command to list the CRs for additional interfaces:

----
$ oc get network-attachment-definitions.k8s.cni.cncf.io
----

Use the following command to delete CRs for additional interfaces:

----
$ oc delete network-attachment-definitions.k8s.cni.cncf.io macvlan-conf
----

== Creating an annotated Pod that uses the CR

To create a Pod that uses the additional interface, use an annotation that
refers to the CR. Create a YAML file called `samplepod.yaml` for a Pod with the
following contents:

[source,yaml]
----
apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf <1>
spec:
  containers:
  - name: samplepod
    command: ["/bin/bash", "-c", "sleep 2000000000000"]
    image: centos/tools
----

<1> The `annotations` field contains `k8s.v1.cni.cncf.io/networks:
macvlan-conf`, which correlates to the `name` field in the CR defined earlier.

Run the following command to create the `samplepod` Pod:

----
$ oc create -f samplepod.yaml
----

To verify that an additional network interface has been created and attached to
the Pod, use the following command to list the IPv4 address information:

----
$ oc exec -it samplepod -- ip -4 addr
----

Three interfaces are listed in the output:

----
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 <1>
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP  link-netnsid 0 <2>
    inet 10.244.1.4/24 scope global eth0
       valid_lft forever preferred_lft forever
4: net1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN  link-netnsid 0 <3>
    inet 192.168.1.203/24 scope global net1
       valid_lft forever preferred_lft forever
----

<1> `lo`: A loopback interface.
<2> `eth0`: The interface that connects to the cluster-wide default network.
<3> `net1`: The new interface that you just created.

=== Attaching multiple interfaces to a Pod

To attach more than one additional interface to a Pod, specify multiple names,
in comma-delimited format, in the `annotations` field in the Pod definition.

The following `annotations` field in a Pod definition specifies different CRs
for the additional interfaces:

[source,yaml]
----
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf, tertiary-conf, quaternary-conf
----

The following `annotations` field in a Pod definition specifies the same CR for
the additional interfaces:

[source,yaml]
----
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf, macvlan-conf
----

== Viewing the interface configuration in a running Pod

After the Pod is running, you can review the configurations of the additional
interfaces created. To view the sample Pod from the earlier example, execute the
following command.

----
$ oc describe pod samplepod
----

The `metadata` section of the output contains a list of annotations, which are
displayed in JSON format:

[source,yaml]
----
Annotations:
  k8s.v1.cni.cncf.io/networks: macvlan-conf
  k8s.v1.cni.cncf.io/networks-status:
    [{
        "name": "openshift-sdn", <1>
        "ips": [
            "10.131.0.10"
        ],
        "default": true,
        "dns": {}
    },{
        "name": "macvlan-conf",
        "interface": "net1", <2>
        "ips": [ <3>
            "192.168.1.200"
        ],
        "mac": "72:00:53:b4:48:c4", <4>
        "dns": {} <5>
    }]
----

<1> `name` refers to the custom resource name, `macvlan-conf`.
<2> `interface` refers to the name of the interface in the Pod.
<3> `ips` is a list of IP addresses as assigned to the Pod.
<4> `mac` is the MAC address of the interface.
<5> `dns` refers DNS for the interface.

The first annotation, `k8s.v1.cni.cncf.io/networks: macvlan-conf`, refers to the
CR created in the example. This annotation was specified in the Pod definition.

The second annotation is `k8s.v1.cni.cncf.io/networks-status`. There are two
interfaces listed under `k8s.v1.cni.cncf.io/networks-status`.

* The first interface describes the interface for the default network,
`openshift-sdn`. This interface is created as `eth0`. It is used for
communications within the cluster.

* The second interface is the additional interface that you created, `net1`. The
output above lists some key values that were configured when the interface was
created, for example, the IP addresses that were assigned to the Pod.

// Module included in the following assemblies:
//
// * networking/managing_multinetworking.adoc

[id="multinetwork-creating-first-attachments-{context}"]
= Creating additional network interfaces

Additional interfaces for Pods are defined in CNI configurations that are stored
as Custom Resources (CRs). These CRs can be created, listed, edited, and deleted
using the `oc` tool.

The procedure below configures a `macvlan` interface on a Pod. This
configuration might not apply to all production environments, but you use the
same procedure for other CNI plug-ins.

== Creating a CNI configuration for an additional interface as a CR

[NOTE]
====
If you want to attach an additional interface to a Pod, the CR that defines the
interface must be in the same project (namespace) as the Pod.
====

. Create a project to store CNI configurations as CRs and the Pods that will use
the CRs.
+
----
$ oc new-project multinetwork-example
----

. Create the CR that will define an additional network interface. Create a YAML
file called `macvlan-conf.yaml` with the following contents:
+
[source,yaml]
----
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition <1>
metadata:
  name: macvlan-conf <2>
spec:
  config: '{ <3>
      "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "eth0",
      "mode": "bridge",
      "ipam": {
        "type": "host-local",
        "subnet": "192.168.1.0/24",
        "rangeStart": "192.168.1.200",
        "rangeEnd": "192.168.1.216",
        "routes": [
          { "dst": "0.0.0.0/0" }
        ],
        "gateway": "192.168.1.1"
      }
    }'
----
+
<1> `kind: NetworkAttachmentDefinition`. This is the name for the CR where this
configuration will be stored. It is a custom extension of Kubernetes that
defines how networks are attached to Pods.
<2> `name` maps to the annotation, which is used in the next step.
<3> `config`: The CNI configuration is packaged in the `config` field.
+
The configuration above is specific to a plug-in, which enables `macvlan`. Note
the `type` line in the CNI configuration portion. Aside from the IPAM (IP
address management) parameters for networking, in this example the `master`
field must reference a network interface that resides on the node(s) hosting the
Pod(s).

. Run the following command to create the CR:
+
----
$ oc create -f macvlan-conf.yaml
----

[NOTE]
====
This example is based on a `macvlan` CNI plug-in. Note that in AWS environments,
macvlan traffic might be filtered and, therefore, might not reach the desired
destination.
====

== Managing the CRs for additional interfaces

You can manage the CRs for additional interfaces using the `oc` CLI.

Use the following command to list the CRs for additional interfaces:

----
$ oc get network-attachment-definitions.k8s.cni.cncf.io
----

Use the following command to delete CRs for additional interfaces:

----
$ oc delete network-attachment-definitions.k8s.cni.cncf.io macvlan-conf
----

== Creating an annotated Pod that uses the CR

To create a Pod that uses the additional interface, use an annotation that
refers to the CR. Create a YAML file called `samplepod.yaml` for a Pod with the
following contents:

[source,yaml]
----
apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf <1>
spec:
  containers:
  - name: samplepod
    command: ["/bin/bash", "-c", "sleep 2000000000000"]
    image: centos/tools
----

<1> The `annotations` field contains `k8s.v1.cni.cncf.io/networks:
macvlan-conf`, which correlates to the `name` field in the CR defined earlier.

Run the following command to create the `samplepod` Pod:

----
$ oc create -f samplepod.yaml
----

To verify that an additional network interface has been created and attached to
the Pod, use the following command to list the IPv4 address information:

----
$ oc exec -it samplepod -- ip -4 addr
----

Three interfaces are listed in the output:

----
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 <1>
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP  link-netnsid 0 <2>
    inet 10.244.1.4/24 scope global eth0
       valid_lft forever preferred_lft forever
4: net1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN  link-netnsid 0 <3>
    inet 192.168.1.203/24 scope global net1
       valid_lft forever preferred_lft forever
----

<1> `lo`: A loopback interface.
<2> `eth0`: The interface that connects to the cluster-wide default network.
<3> `net1`: The new interface that you just created.

=== Attaching multiple interfaces to a Pod

To attach more than one additional interface to a Pod, specify multiple names,
in comma-delimited format, in the `annotations` field in the Pod definition.

The following `annotations` field in a Pod definition specifies different CRs
for the additional interfaces:

[source,yaml]
----
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf, tertiary-conf, quaternary-conf
----

The following `annotations` field in a Pod definition specifies the same CR for
the additional interfaces:

[source,yaml]
----
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf, macvlan-conf
----

== Viewing the interface configuration in a running Pod

After the Pod is running, you can review the configurations of the additional
interfaces created. To view the sample Pod from the earlier example, execute the
following command.

----
$ oc describe pod samplepod
----

The `metadata` section of the output contains a list of annotations, which are
displayed in JSON format:

[source,yaml]
----
Annotations:
  k8s.v1.cni.cncf.io/networks: macvlan-conf
  k8s.v1.cni.cncf.io/networks-status:
    [{
        "name": "openshift-sdn", <1>
        "ips": [
            "10.131.0.10"
        ],
        "default": true,
        "dns": {}
    },{
        "name": "macvlan-conf",
        "interface": "net1", <2>
        "ips": [ <3>
            "192.168.1.200"
        ],
        "mac": "72:00:53:b4:48:c4", <4>
        "dns": {} <5>
    }]
----

<1> `name` refers to the custom resource name, `macvlan-conf`.
<2> `interface` refers to the name of the interface in the Pod.
<3> `ips` is a list of IP addresses as assigned to the Pod.
<4> `mac` is the MAC address of the interface.
<5> `dns` refers DNS for the interface.

The first annotation, `k8s.v1.cni.cncf.io/networks: macvlan-conf`, refers to the
CR created in the example. This annotation was specified in the Pod definition.

The second annotation is `k8s.v1.cni.cncf.io/networks-status`. There are two
interfaces listed under `k8s.v1.cni.cncf.io/networks-status`.

* The first interface describes the interface for the default network,
`openshift-sdn`. This interface is created as `eth0`. It is used for
communications within the cluster.

* The second interface is the additional interface that you created, `net1`. The
output above lists some key values that were configured when the interface was
created, for example, the IP addresses that were assigned to the Pod.


Fix typo in doc

Fix typo in doc

[[vertx:run]]
== *vertx:run*
This goal allows to run the Vert.x application as part of the maven build.
The application is always run as a forked process.

The goal does not have any exclusive configuration,  **<<common:run-configurations,Common Run Configuration>>**
defines all the applicable configurations for the goal

[cols="1,5,2,3"]
|===
| Element | Description | Property| Default

| redeploy
| Whether or not the redeployment is enabled
|
| false

| redeployScanPeriod
| The file system check period (in milliseconds)
| vertx.redeploy.scan.period
| 1000

| redeployGracePeriod
| The amount of time (in milliseconds) to wait between 2 re-deployments
| vertx.redeploy.grace.period
| 1000

| redeployTerminationPeriod
| the amount of time (in milliseconds) to wait after having stopped the application (before launching user command).
  This is useful on Windows, where the process is not killed immediately.
| vertx.redeploy.termination.period
| 0

| config
| The configuration file to use to configure the application. This property is passed as the `-config` option to vertx
run.
|
| src/main/config/application.json or src/main/config/application.yml

| jvmArgs
| The Java Options that will be used when starting the application, these are the values that are
typically passed to vert.x applications using --java-opts.
| vertx.jvmArguments
| _no arguments_
|===

When the redeployment is enabled, it replays the plugin configured between the _generate-source_ and
_process-classes_ phases.

So to start a Vert.x application just launch:

[source]
----
mvn vertx:run
----

If the sources are not compiled, the plugin executes `mvn compile` for you.

**IMPORTANT**: `vertx:run` starts the application in a forked JVM.

[[vertx:debug]]
== *vertx:debug*
This goal allows to debug the Vert.x application.

The goal does not have any exclusive configuration,  **<<common:run-configurations,Common Run Configuration>>**
defines all the applicable configurations for the goal

[cols="1,5,2,3"]
|===
| Element | Description | Property| Default

| config
| The configuration file to use to configure the application. This property is passed as the `-config` option to vertx
run.
|
| src/main/config/application.json or src/main/config/application.yml

| jvmArgs
| The Java Options that will be used when starting the application, these are the values that are
typically passed to vert.x applications using --java-opts.
| vertx.jvmArguments
| _no arguments_

| debugPort
| The debugger port
| debug.port
| 5005

| debugSuspend
| Whether or not the application must wait until a debugger is attached to start
| debug.suspend
| false
|===

**IMPORTANT**: the redeploy mode and debug cannot be used together. When `vertx:debug` is launched, the redeployment
mode is disabled.

[[vertx:run]]
== *vertx:run*
This goal allows to run the Vert.x application as part of the maven build.
The application is always run as a forked process.

The goal does not have any exclusive configuration,  **<<common:run-configurations,Common Run Configuration>>**
defines all the applicable configurations for the goal

[cols="1,5,2,3"]
|===
| Element | Description | Property| Default

| redeploy
| Whether or not the redeployment is enabled
|
| false

| redeployScanPeriod
| The file system check period (in milliseconds)
| vertx.redeploy.scan.period
| 1000

| redeployGracePeriod
| The amount of time (in milliseconds) to wait between 2 re-deployments
| vertx.redeploy.grace.period
| 1000

| redeployTerminationPeriod
| the amount of time (in millisecods) to wait after having stopped the application (before launching user command).
  This is useful on Windows, where the process is not killed immediately.
| vertx.redeploy.termination.period
| 0

| config
| The configuration file to use to configure the application. This property is passed as the `-config` option to vertx
run.
|
| src/main/config/application.json or src/main/config/application.yml

| jvmArgs
| The Java Options that will be used when starting the application, these are the values that are
typically passed to vert.x applications using --java-opts.
| vertx.jvmArguments
| _no arguments_
|===

When the redeployment is enabled, it replays the plugin configured between the _generate-source_ and
_process-classes_ phases.

So to start a Vert.x application just launch:

[source]
----
mvn vertx:run
----

If the sources are not compiled, the plugin executes `mvn compile` for you.

**IMPORTANT**: `vertx:run` starts the application in a forked JVM.

[[vertx:debug]]
== *vertx:debug*
This goal allows to debug the Vert.x application.

The goal does not have any exclusive configuration,  **<<common:run-configurations,Common Run Configuration>>**
defines all the applicable configurations for the goal

[cols="1,5,2,3"]
|===
| Element | Description | Property| Default

| config
| The configuration file to use to configure the application. This property is passed as the `-config` option to vertx
run.
|
| src/main/config/application.json or src/main/config/application.yml

| jvmArgs
| The Java Options that will be used when starting the application, these are the values that are
typically passed to vert.x applications using --java-opts.
| vertx.jvmArguments
| _no arguments_

| debugPort
| The debugger port
| debug.port
| 5005

| debugSuspend
| Whether or not the application must wait until a debugger is attached to start
| debug.suspend
| false
|===

**IMPORTANT**: the redeploy mode and debug cannot be used together. When `vertx:debug` is launched, the redeployment
mode is disabled.