tet123/debezium-connector-mysql/pom.xml

904 lines
46 KiB
XML
Raw Normal View History

<?xml version="1.0"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<groupId>io.debezium</groupId>
<artifactId>debezium-parent</artifactId>
<version>2.5.0-SNAPSHOT</version>
<relativePath>../debezium-parent/pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>debezium-connector-mysql</artifactId>
<name>Debezium Connector for MySQL</name>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-core</artifactId>
</dependency>
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-storage-kafka</artifactId>
</dependency>
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-storage-file</artifactId>
</dependency>
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-ddl-parser</artifactId>
</dependency>
<dependency>
<groupId>com.zendesk</groupId>
<artifactId>mysql-binlog-connector-java</artifactId>
</dependency>
2017-05-03 16:17:06 +02:00
<dependency>
<groupId>mil.nga</groupId>
<artifactId>wkb</artifactId>
<scope>test</scope>
2017-05-03 16:17:06 +02:00
</dependency>
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>connect-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.mysql</groupId>
<artifactId>mysql-connector-j</artifactId>
<exclusions>
<exclusion>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- Testing -->
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-core</artifactId>
<type>test-jar</type>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-embedded</artifactId>
<type>test-jar</type>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-embedded</artifactId>
<scope>test</scope>
</dependency>
<dependency>
2022-01-11 09:09:09 +01:00
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<scope>test</scope>
</dependency>
DBZ-64 Added Avro Converter to record verification utilities The `VerifyRecord` utility class has methods that will verify a `SourceRecord`, and is used in many of our integration tests to check whether records are constructed in a valid manner. The utility already checks whether the records can be serialized and deserialized using the JSON converter (provided with Kafka Connect); this change also checks with the Avro Converter (which produces much smaller records and is more suitable for production). Note that version 3.0.0 of the Confluent Avro Converter is required; version 2.1.0-alpha1 could not properly handle complex Schema objects with optional fields (see https://github.com/confluentinc/schema-registry/pull/280). Also, the names of the Kafka Connect schemas used in MySQL source records has changed. # The record's envelope Schema used to be "<serverName>.<database>.<table>" but is now "<serverName>.<database>.<table>.Envelope". # The Schema for record keys used to be named "<database>.<table>/pk", but the '/' character is not valid within a Avro name, and has been changed to "<serverName>.<database>.<table>.Key". # The Schema for record values used to be named "<database>.<table>", but to better fit with the other Schema names it has been changed to "<serverName>.<database>.<table>.Value". Thus, all of the Schemas for a single database table have the same Avro namespace "<serverName>.<database>.<table>" (or "<topicName>") with Avro schema names of "Envelope", "Key", and "Value". All unit and integration tests pass.
2016-06-02 23:23:27 +02:00
<dependency>
<groupId>io.confluent</groupId>
<artifactId>kafka-connect-avro-converter</artifactId>
<scope>test</scope>
DBZ-64 Added Avro Converter to record verification utilities The `VerifyRecord` utility class has methods that will verify a `SourceRecord`, and is used in many of our integration tests to check whether records are constructed in a valid manner. The utility already checks whether the records can be serialized and deserialized using the JSON converter (provided with Kafka Connect); this change also checks with the Avro Converter (which produces much smaller records and is more suitable for production). Note that version 3.0.0 of the Confluent Avro Converter is required; version 2.1.0-alpha1 could not properly handle complex Schema objects with optional fields (see https://github.com/confluentinc/schema-registry/pull/280). Also, the names of the Kafka Connect schemas used in MySQL source records has changed. # The record's envelope Schema used to be "<serverName>.<database>.<table>" but is now "<serverName>.<database>.<table>.Envelope". # The Schema for record keys used to be named "<database>.<table>/pk", but the '/' character is not valid within a Avro name, and has been changed to "<serverName>.<database>.<table>.Key". # The Schema for record values used to be named "<database>.<table>", but to better fit with the other Schema names it has been changed to "<serverName>.<database>.<table>.Value". Thus, all of the Schemas for a single database table have the same Avro namespace "<serverName>.<database>.<table>" (or "<topicName>") with Avro schema names of "Envelope", "Key", and "Value". All unit and integration tests pass.
2016-06-02 23:23:27 +02:00
</dependency>
<dependency>
<groupId>io.apicurio</groupId>
<artifactId>apicurio-registry-utils-converter</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<artifactId>slf4j-jboss-logmanager</artifactId>
<groupId>org.jboss.slf4j</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.awaitility</groupId>
<artifactId>awaitility</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-testing-testcontainers</artifactId>
<scope>test</scope>
2023-07-13 20:57:58 +02:00
<exclusions>
<exclusion>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-launcher</artifactId>
</exclusion>
<exclusion>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>mysql</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<scope>test</scope>
</dependency>
<!-- Used for unit testing with Kafka -->
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka_${version.kafka.scala}</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<properties>
<!--
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
Specify the properties for the various Docker containers.
-->
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
<mysql.user>mysqluser</mysql.user>
<mysql.password>mysqlpw</mysql.password>
<mysql.replica.user>mysqlreplica</mysql.replica.user>
<mysql.replica.password>mysqlpw</mysql.replica.password>
<mysql.port>3306</mysql.port>
<mysql.percona.port>3306</mysql.percona.port>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
<mysql.gtid.port>3306</mysql.gtid.port>
<mysql.gtid.replica.port>3306</mysql.gtid.replica.port>
<mysql.ssl.port>3306</mysql.ssl.port>
2020-08-11 17:19:44 +02:00
<mysql.replica.port>3306</mysql.replica.port> <!-- by default use primary as 'replica' -->
<mysql.init.timeout>60000</mysql.init.timeout> <!-- 60 seconds -->
<apicurio.port>8080</apicurio.port>
<apicurio.init.timeout>60000</apicurio.init.timeout> <!-- 60 seconds -->
<!--
By default, we should use the docker image maintained by the MySQL team. This property is changed with different profiles.
However, we run one container with GTIDs and one without.
-->
<docker.dbs>debezium/mysql-server-test-database</docker.dbs>
<docker.filter>${docker.dbs}</docker.filter>
<docker.skip>false</docker.skip>
2021-05-28 11:21:08 +02:00
<docker.initimage>rm -f /etc/localtime; ln -s /usr/share/zoneinfo/US/Samoa /etc/localtime</docker.initimage>
</properties>
<build>
<plugins>
<plugin>
<groupId>io.fabric8</groupId>
<artifactId>docker-maven-plugin</artifactId>
<configuration>
<watchInterval>500</watchInterval>
<logDate>default</logDate>
<verbose>true</verbose>
<imagePullPolicy>IfNotPresent</imagePullPolicy>
<images>
<!--
Images based on "${mysql.server.image.source}" Docker image
-->
<image>
<!-- A Docker image using a partial MySQL installation maintained by MySQL team. -->
<name>debezium/mysql-server-test-database</name>
<run>
<namingStrategy>none</namingStrategy>
<env>
<MYSQL_ROOT_PASSWORD>debezium-rocks</MYSQL_ROOT_PASSWORD>
<MYSQL_DATABASE>mysql</MYSQL_DATABASE> <!-- database created upon init -->
<MYSQL_USER>${mysql.user}</MYSQL_USER>
<MYSQL_PASSWORD>${mysql.password}</MYSQL_PASSWORD>
</env>
<ports>
<port>${mysql.port}:3306</port>
</ports>
<log>
<prefix>mysql</prefix>
<enabled>true</enabled>
<color>yellow</color>
</log>
<wait>
<log>(MySQL|MariaDB) init process done. Ready for start up.(?s)(.*)(mysqld|mariadbd): ready for connections.</log>
<time>${mysql.init.timeout}</time>
</wait>
</run>
<build>
<from>${mysql.server.image.source}:${version.mysql.server}</from>
<runCmds>
<run>${docker.initimage}</run>
</runCmds>
<assembly>
<inline>
<fileSets>
<fileSet>
<directory>${project.basedir}/src/test/docker/server</directory>
<includes>
<include>my.cnf</include>
</includes>
<outputDirectory>etc/mysql</outputDirectory>
</fileSet>
<fileSet>
<directory>${project.basedir}/src/test/docker/init</directory>
<outputDirectory>docker-entrypoint-initdb.d</outputDirectory>
</fileSet>
</fileSets>
</inline>
<targetDir>/</targetDir>
</assembly>
</build>
<external>
<type>properties</type>
<mode>override</mode>
</external>
</image>
<image>
<!-- A Docker image using a partial MySQL installation maintained by MySQL team
that enable mysql ssl connection -->
<name>debezium/mysql-server-test-database-ssl</name>
<run>
<namingStrategy>none</namingStrategy>
<env>
<MYSQL_ROOT_PASSWORD>debezium-rocks</MYSQL_ROOT_PASSWORD>
<MYSQL_DATABASE>mysql</MYSQL_DATABASE> <!-- database created upon init -->
<MYSQL_USER>${mysql.user}</MYSQL_USER>
<MYSQL_PASSWORD>${mysql.password}</MYSQL_PASSWORD>
</env>
<ports>
<port>${mysql.ssl.port}:3306</port>
</ports>
<volumes>
<bind>
<volume>${project.basedir}/src/test/resources/ssl-certs:/etc/certs</volume>
</bind>
</volumes>
<log>
<prefix>mysql</prefix>
<enabled>true</enabled>
<color>yellow</color>
</log>
<wait>
<log>(MySQL|MariaDB) init process done. Ready for start up.(?s)(.*)(mysqld|mariadbd): ready for connections.</log>
<time>${mysql.init.timeout}</time>
</wait>
</run>
<build>
<from>${mysql.server.image.source}:${version.mysql.server}</from>
<runCmds>
<run>${docker.initimage}</run>
</runCmds>
<assembly>
<inline>
<fileSets>
<fileSet>
<directory>${project.basedir}/src/test/docker/server-ssl</directory>
<includes>
<include>my.cnf</include>
</includes>
<outputDirectory>etc/mysql</outputDirectory>
</fileSet>
<fileSet>
<directory>${project.basedir}/src/test/docker/init</directory>
<outputDirectory>docker-entrypoint-initdb.d</outputDirectory>
</fileSet>
<fileSet>
<directory>${project.basedir}/src/test/docker/init-ssl</directory>
<outputDirectory>docker-entrypoint-initdb.d</outputDirectory>
</fileSet>
</fileSets>
</inline>
<targetDir>/</targetDir>
</assembly>
</build>
<external>
<type>properties</type>
<mode>override</mode>
</external>
</image>
<image>
<!-- A Docker image using a partial MySQL installation maintained by MySQL team. -->
<name>debezium/mysql-server-gtids-test-database</name>
<alias>database-gtids</alias>
<run>
<namingStrategy>alias</namingStrategy>
<env>
<MYSQL_ROOT_PASSWORD>debezium-rocks</MYSQL_ROOT_PASSWORD>
<MYSQL_DATABASE>mysql</MYSQL_DATABASE> <!-- database created upon init -->
<MYSQL_USER>${mysql.user}</MYSQL_USER>
<MYSQL_PASSWORD>${mysql.password}</MYSQL_PASSWORD>
</env>
<ports>
<port>${mysql.gtid.port}:3306</port>
</ports>
<log>
<prefix>mysql-gtids</prefix>
<enabled>true</enabled>
<color>cyan</color>
</log>
<wait>
<log>(MySQL|MariaDB) init process done. Ready for start up.(?s)(.*)(mysqld|mariadbd): ready for connections.</log>
<time>${mysql.init.timeout}</time>
</wait>
</run>
<build>
<from>${mysql.server.image.source}:${version.mysql.server}</from>
<runCmds>
<run>${docker.initimage}</run>
</runCmds>
<assembly>
<inline>
<fileSets>
<fileSet>
<directory>${project.basedir}/src/test/docker/server-gtids</directory>
<includes>
<include>my.cnf</include>
</includes>
<outputDirectory>etc/mysql</outputDirectory>
</fileSet>
<fileSet>
<directory>${project.basedir}/src/test/docker/init</directory>
<outputDirectory>docker-entrypoint-initdb.d</outputDirectory>
</fileSet>
</fileSets>
</inline>
<targetDir>/</targetDir>
</assembly>
</build>
<external>
<type>properties</type>
<mode>override</mode>
</external>
</image>
<image>
<!--
A Docker image using a MySQL installation maintained by MySQL team
that is a replica of `debezium/mysql-server-gtids-test-database`
-->
<name>debezium/mysql-server-gtids-test-database-replica</name>
<run>
<namingStrategy>none</namingStrategy>
<env>
<MYSQL_ROOT_PASSWORD>debezium-rocks</MYSQL_ROOT_PASSWORD>
<MYSQL_USER>${mysql.replica.user}</MYSQL_USER>
<MYSQL_PASSWORD>${mysql.replica.password}</MYSQL_PASSWORD>
</env>
<links>
<link>database-gtids</link>
</links>
<ports>
<port>${mysql.gtid.replica.port}:3306</port>
</ports>
<log>
<prefix>mysql-gtids-replica</prefix>
<enabled>true</enabled>
<color>magenta</color>
</log>
<wait>
<log>(MySQL|MariaDB) init process done. Ready for start up.(?s)(.*)(mysqld|mariadbd): ready for connections.</log>
<time>${mysql.init.timeout}</time>
</wait>
</run>
<build>
<from>${mysql.server.image.source}:${version.mysql.server}</from>
<runCmds>
<run>${docker.initimage}</run>
</runCmds>
<assembly>
<inline>
<fileSets>
<fileSet>
<directory>${project.basedir}/src/test/docker/server-replica</directory>
<includes>
<include>my.cnf</include>
</includes>
<outputDirectory>etc/mysql</outputDirectory>
</fileSet>
<fileSet>
<directory>${project.basedir}/src/test/docker/init-replica</directory>
<outputDirectory>docker-entrypoint-initdb.d</outputDirectory>
</fileSet>
</fileSets>
</inline>
<targetDir>/</targetDir>
</assembly>
</build>
<external>
<type>properties</type>
<mode>override</mode>
</external>
</image>
<image>
<!--
A Docker image using a Percona Server installation
-->
<name>debezium/percona-server-test-database</name>
<run>
<namingStrategy>none</namingStrategy>
<env>
<MYSQL_ROOT_PASSWORD>debezium-rocks</MYSQL_ROOT_PASSWORD>
<MYSQL_USER>${mysql.user}</MYSQL_USER>
<MYSQL_PASSWORD>${mysql.password}</MYSQL_PASSWORD>
<TZ>Pacific/Pago_Pago</TZ>
</env>
<ports>
<port>${mysql.percona.port}:3306</port>
</ports>
<log>
<prefix>percona-server</prefix>
<enabled>true</enabled>
<color>magenta</color>
</log>
<wait>
<log>MySQL init process done. Ready for start up.(?s)(.*)mysqld: ready for connections.</log>
<time>${mysql.init.timeout}</time>
</wait>
</run>
<build>
<from>percona/percona-server:${version.mysql.server}</from>
<assembly>
<inline>
<fileSets>
<fileSet>
<directory>${project.basedir}/src/test/docker/server</directory>
<includes>
<include>my.cnf</include>
</includes>
<outputDirectory>etc/mysql</outputDirectory>
</fileSet>
<fileSet>
<directory>${project.basedir}/src/test/docker/init</directory>
<outputDirectory>docker-entrypoint-initdb.d</outputDirectory>
</fileSet>
</fileSets>
</inline>
<targetDir>/</targetDir>
</assembly>
</build>
<external>
<type>properties</type>
<mode>override</mode>
</external>
</image>
<image>
<name>apicurio/apicurio-registry-mem:${version.apicurio}</name>
<run>
<namingStrategy>none</namingStrategy>
<ports>
<port>${apicurio.port}:8080</port>
</ports>
<log>
<prefix>apicurio</prefix>
<enabled>true</enabled>
<color>blue</color>
</log>
<wait>
<log>.*apicurio-registry-app.*started in.*</log>
<time>${apicurio.init.timeout}</time>
</wait>
</run>
</image>
</images>
</configuration>
<!--
Connect this plugin to the maven lifecycle around the integration-test phase:
start the container in pre-integration-test and stop it in post-integration-test.
-->
<executions>
<execution>
<id>start</id>
<phase>pre-integration-test</phase>
<goals>
<goal>build</goal>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
<!--
Unlike surefire, the failsafe plugin ensures 'post-integration-test' phase always runs, even
when there are failed integration tests. We rely upon this to always shut down the Docker container
after the integration tests (defined as '*IT.java') are run.
-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
<configuration>
<skipTests>${skipITs}</skipTests>
<enableAssertions>true</enableAssertions>
<systemPropertyVariables>
<!-- Make these available to the tests via system properties -->
<database.hostname>${docker.host.address}</database.hostname>
<database.port>${mysql.port}</database.port>
<database.user>${mysql.user}</database.user>
<database.password>${mysql.password}</database.password>
<database.replica.hostname>${docker.host.address}</database.replica.hostname>
<database.replica.port>${mysql.replica.port}</database.replica.port>
<skipLongRunningTests>${skipLongRunningTests}</skipLongRunningTests>
<database.ssl.mode>disabled</database.ssl.mode>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
</systemPropertyVariables>
<runOrder>${runOrder}</runOrder>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
</configuration>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>integration-test</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
2019-09-23 19:01:44 +02:00
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
2019-09-23 19:01:44 +02:00
</plugin>
<plugin>
<groupId>io.debezium</groupId>
<artifactId>debezium-schema-generator</artifactId>
<version>${project.version}</version>
<executions>
<execution>
<id>generate-connector-metadata</id>
<goals>
<goal>generate-api-spec</goal>
</goals>
<phase>prepare-package</phase>
<configuration>
<outputDirectory>${project.build.outputDirectory}/META-INF/resources/</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<resources>
<!-- Apply the properties set in the POM to the resource files -->
<resource>
<filtering>true</filtering>
<directory>src/main/resources</directory>
<includes>
<include>*</include>
<include>**/*</include>
</includes>
</resource>
</resources>
<testResources>
<testResource>
<directory>src/test/resources</directory>
<filtering>false</filtering>
<includes>
<include>*</include>
<include>**/*</include>
</includes>
</testResource>
</testResources>
</build>
<!--
Define several useful profiles
-->
<profiles>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This assembly profile is used during official builds. In addition to
compiling, and running the unit and integration tests like the non-assembly
2017-05-08 17:40:19 +02:00
profiles, this profile creates additional (like the connector plugin archives),
starts up all three Docker containers (normal MySQL, MySQL+GTIDs, and alt-MySQL)
and runs the integration tests against each of them.
To use, specify "-Passembly" on the Maven command line.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<profile>
<id>assembly</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<!-- Run multiple images at the same time, but use different ports for all MySQL servers -->
<docker.dbs>
debezium/mysql-server-test-database,debezium/mysql-server-gtids-test-database,debezium/mysql-server-gtids-test-database-replica,debezium/percona-server-test-database,debezium/mysql-server-test-database-ssl
</docker.dbs>
<mysql.port>4301</mysql.port>
<mysql.gtid.port>4302</mysql.gtid.port>
<mysql.gtid.replica.port>4303</mysql.gtid.replica.port>
<mysql.percona.port>4304</mysql.percona.port>
<mysql.ssl.port>4305</mysql.ssl.port>
</properties>
<build>
<plugins>
<plugin>
2016-03-17 21:58:27 +01:00
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
2016-03-17 21:58:27 +01:00
<dependencies>
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-assembly-descriptors</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>default</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>${project.artifactId}-${project.version}</finalName>
<attach>true</attach> <!-- we want attach & deploy these to Maven -->
<descriptorRefs>
<descriptorRef>${assembly.descriptor}</descriptorRef>
</descriptorRefs>
2020-02-07 08:26:47 +01:00
<tarLongFileMode>posix</tarLongFileMode>
</configuration>
</execution>
</executions>
</plugin>
<!--
Override the failsafe plugin to run the integration tests for each set of databases.
But make sure each database server is used only once ...
-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
2019-09-23 19:01:44 +02:00
<version>${version.failsafe.plugin}</version>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
<configuration>
<skipTests>${skipITs}</skipTests>
<enableAssertions>true</enableAssertions>
<systemPropertyVariables>
<!-- Make these available to the tests via system properties -->
<database.hostname>${docker.host.address}</database.hostname>
<database.user>${mysql.user}</database.user>
<database.password>${mysql.password}</database.password>
<database.replica.hostname>${docker.host.address}</database.replica.hostname>
<database.replica.user>${mysql.replica.user}</database.replica.user>
<database.replica.password>${mysql.replica.password}</database.replica.password>
<database.port>${mysql.port}</database.port>
<database.replica.port>${mysql.port}</database.replica.port>
<database.ssl.mode>disabled</database.ssl.mode>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
<skipLongRunningTests>false</skipLongRunningTests>
<isAssemblyProfileActive>true</isAssemblyProfileActive>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
</systemPropertyVariables>
<runOrder>${runOrder}</runOrder>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
</configuration>
<executions>
<!-- First run the integration tests with the non-GTID server alone -->
<execution>
<id>integration-test-mysql</id>
<goals>
<goal>integration-test</goal>
</goals>
<configuration>
<systemPropertyVariables>
<!-- same port for both, since we're only running one server -->
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
<database.port>${mysql.port}</database.port>
<database.replica.port>${mysql.port}</database.replica.port>
</systemPropertyVariables>
</configuration>
</execution>
<!-- Then run the integration tests with the GTID server + replica server -->
<execution>
<id>integration-test-mysql-gtids-with-replica</id>
<goals>
<goal>integration-test</goal>
</goals>
<configuration>
<systemPropertyVariables>
DBZ-163 Corrected assembly profile in build The Travis-CI builds run the Maven build using the `assembly` profile, and this has been failing quite a bit lately. The first problem appears to be that the Travis-CI environment recently changed to have port 3306 taken, which means that our build fails to start any Docker containers for MySQL that attempt to use this port. A simple fix is to use different ports for the assembly build. However, trying to change the port numbers for some of the profiles caused a lot of problems, and to correct these required refactoring how the properties are set. The Docker Maven plugin is now configured with separate properties that are set once (depending upon the profile) to determine the port assignments of the various Docker containers. The Failsafe plugin executions then use these Maven properties when setting the system variables (e.g., `database.host`) needed in the integration tests. This appears to have worked, but it still is a bit fragile. For example, the assembly profile defines several Failsafe executions, and during this profile these should be the only executions run; however, if not all the properties are set properly, the build seems to also run the default Failsafe execution in addition to the other `assembly` profile executions. (I think properties can’t only be defined in the execution, but need to also be defined in the Failsafe configuration.) The “alternative” MySQL Docker images were removed, since they basically should not provide any different behavior than the `mysql/mysql-server` images we normally used. The extra containers required a lot more resources to run and dramatically increased the complexity of the build. A few other trivial changes were made.
2016-12-05 23:35:04 +01:00
<database.port>${mysql.gtid.port}</database.port>
<database.replica.port>${mysql.gtid.replica.port}</database.replica.port>
</systemPropertyVariables>
</configuration>
</execution>
<!-- Then just Percona Server -->
<execution>
<id>integration-test-percona-server</id>
<goals>
<goal>integration-test</goal>
</goals>
<configuration>
<systemPropertyVariables>
<!-- same port for both, since we're only running one server -->
<database.port>${mysql.percona.port}</database.port>
<database.replica.port>${mysql.percona.port}</database.replica.port>
</systemPropertyVariables>
</configuration>
</execution>
<!-- SSL -->
<execution>
<id>integration-test-ssl</id>
<goals>
<goal>integration-test</goal>
</goals>
<configuration>
<systemPropertyVariables>
<database.ssl.mode>verify_ca</database.ssl.mode>
<database.ssl.truststore>${project.basedir}/src/test/resources/ssl/truststore</database.ssl.truststore>
<database.ssl.truststore.password>debezium</database.ssl.truststore.password>
<database.ssl.keystore>${project.basedir}/src/test/resources/ssl/keystore</database.ssl.keystore>
<database.ssl.keystore.password>debezium</database.ssl.keystore.password>
<!-- same port for both, since we're only running one server -->
<database.port>${mysql.ssl.port}</database.port>
<database.replica.port>${mysql.ssl.port}</database.replica.port>
</systemPropertyVariables>
</configuration>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do not perform any Docker-related functionality
To use, specify "-DskipITs" on the Maven command line.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<profile>
<id>skip-integration-tests</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>skipITs</name>
</property>
</activation>
<properties>
<docker.skip>true</docker.skip>
</properties>
</profile>
<profile>
<id>quick</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>quick</name>
</property>
</activation>
<properties>
<skipITs>true</skipITs>
<docker.skip>true</docker.skip>
</properties>
</profile>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the alternative Docker image for MySQL.
To use, specify "-Dmysql-gtids" or -Pmysql-gtids on the Maven command line.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<profile>
<id>mysql-gtids</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>mysql-gtids</name>
</property>
</activation>
<properties>
<!-- Docker properties -->
<docker.dbs>debezium/mysql-server-gtids-test-database</docker.dbs>
<!-- Integration test properties -->
<database.port>${mysql.gtid.port}</database.port>
<database.replica.port>${mysql.gtid.port}</database.replica.port>
</properties>
</profile>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the Docker image for Percona Server.
To use, specify "-Dpercona-server" or -Ppercona-server on the Maven command line.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<profile>
<id>percona-server</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>percona-server</name>
</property>
</activation>
<properties>
<!-- Docker properties -->
<docker.dbs>debezium/percona-server-test-database</docker.dbs>
<!-- Integration test properties -->
<database.port>${mysql.percona.port}</database.port>
<database.replica.port>${mysql.percona.port}</database.replica.port>
<docker.initimage>ln -s /usr/share/zoneinfo/Pacific/Pago_Pago /etc/localtime</docker.initimage>
</properties>
</profile>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the Docker image for a MySQL replica of another MySQL server
configured to use GTIDs. To use, specify "-Dmysql-replica"
or -Pmysql-replica on the Maven command line.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<profile>
<id>mysql-replica</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>mysql-replica</name>
</property>
</activation>
<properties>
<!-- Docker properties -->
<mysql.gtid.port>3306</mysql.gtid.port>
<mysql.gtid.replica.port>4306</mysql.gtid.replica.port>
<docker.dbs>debezium/mysql-server-gtids-test-database,debezium/mysql-server-gtids-test-database-replica</docker.dbs>
<!-- Integration test properties -->
<database.port>${mysql.gtid.port}</database.port>
<database.replica.port>${mysql.gtid.replica.port}</database.replica.port>
</properties>
</profile>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the alternative Docker image for MySQL.
To use, specify "-Dmysql-ssl" or -Pmysql-ssl on the Maven command line.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<profile>
<id>mysql-ssl</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>mysql-ssl</name>
</property>
</activation>
<properties>
<!-- Docker properties -->
<docker.dbs>debezium/mysql-server-test-database-ssl</docker.dbs>
<!-- Integration test properties -->
<database.port>${mysql.ssl.port}</database.port>
<database.replica.port>${mysql.ssl.port}</database.replica.port>
<docker.initimage>ln -s /usr/share/zoneinfo/Pacific/Pago_Pago /etc/localtime</docker.initimage>
</properties>
</profile>
<profile>
<id>apicurio</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>apicurio</name>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<use.apicurio>true</use.apicurio>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
<properties>
<docker.filter>${docker.dbs},apicurio/apicurio-registry-mem:${version.apicurio}</docker.filter>
</properties>
</profile>
</profiles>
</project>