Migrating Apicurio Registry deployments

Procedure

1. Export all the data from Apicurio Registry 1.1 using the exportV1 tool. This generates a registry-export.zip file in your current directory:

   java -jar apicurio-registry-utils-exportV1-2.4.4.SP1-redhat-00001.jar http://old-registry.my-company.com/api

2. Import the .zip file into Apicurio Registry 2.x using the import API:

   curl -X POST "http://new-registry.my-company.com/apis/registry/v2/admin/import" \
     -H "Accept: application/json" -H "Content-Type: application/zip" \
     --data-binary @registry-export.zip

3. Check that all the artifacts have been imported into the new 2.x registry by running these commands and comparing the count field:

   curl "http://old-registry.my-company.com/api/search/artifacts"

   curl "http://new-registry.my-company.com/apis/registry/v2/search/artifacts"

Procedure

1. If you are using the Apicurio Registry Java REST client, you must change the Maven dependencies for the Apicurio Registry Java client libraries, which have been repackaged in version 2.x:

   <dependency>
       <groupId>io.apicurio</groupId>
       <artifactId>apicurio-registry-client</artifactId>
       <version>2.4.4.SP1-redhat-00001</version>
   </dependency>

2. In your Java client application, you must change your registry URL configuration, from pointing to the existing v1 API path to the new v2 path. For example:

   public class ClientExample {
   
       private static final RegistryRestClient client;
   
        public static void main(String[] args) throws Exception {
           // Create a registry client
           String registryUrl = "https://new-registry.my-company.com/apis/registry/v2";
           RegistryClient client = RegistryClientFactory.create(registryUrl);
       }
   }

   You can find more details on the Java client in the Red Hat build of Apicurio Registry User Guide.

3. If you are using the Apicurio Registry SerDes libraries, you must change the Maven dependencies, which have been repackaged in version 2.x. In Apicurio Registry 1.1, the SerDes libraries were all provided with only one Maven dependency:

   <dependency>
       <groupId>io.apicurio</groupId>
       <artifactId>apicurio-registry-utils-serde</artifactId>
       <version>1.3.2.Final-redhat-00002</version>
   </dependency>

   In Apicurio Registry 2.x, the SerDes libraries have been split into three Maven dependencies, one for each supported data format: avro, protobuf, and json schema, depending on your use cases:

   <dependency>
       <groupId>io.apicurio</groupId>
       <artifactId>apicurio-registry-serdes-avro-serde</artifactId>
       <version>2.4.4.SP1-redhat-00001</version>
   </dependency>
   <dependency>
       <groupId>io.apicurio</groupId>
       <artifactId>apicurio-registry-serdes-protobuf-serde</artifactId>
       <version>2.4.4.SP1-redhat-00001</version>
   </dependency>
   <dependency>
       <groupId>io.apicurio</groupId>
       <artifactId>apicurio-registry-serdes-jsonschema-serde</artifactId>
       <version>2.4.4.SP1-redhat-00001</version>
   </dependency>

4. In your Kafka producer and consumer Java applications, you must change your registry URL configuration from pointing to the existing v1 API path to the new v2 path. For example:

   Existing registry v1 API path:

   props.putIfAbsent(AbstractKafkaSerDe.REGISTRY_URL_CONFIG_PARAM, "http://old-registry.my-company.com/api");

   New registry v2 API path:

   props.putIfAbsent(SerdeConfig.REGISTRY_URL, "http://new-registry.my-company.com/apis/registry/v2");

   The refactored SerDes libraries also include other important changes to configuration properties. For more details on SerDes configuration, see the Red Hat build of Apicurio Registry User Guide.