Various issues migrating apicurio-registry-maven-plugin v2 to v3

[creckord]

Description

Registry Version: 3.0.4
Persistence type: sql (Postgres 15)

As part of migrating our Apicurio Registry over to v3, I am trying to migrate our Maven builds from apicurio-registry-maven-plugin v2 to v3 and running into various issues. I'll collect them here at first, as to not spam the tracker. But feel free to request separate reports if they seem warranted.

Environment

Windows 11
Maven 3.9.9
JDK 21.0.5 (Temurin 21.0.5+11-LTS)
apicurio-registry-maven-plugin 3.0.4

1. Missing documentation of plugin changes

Just a minor thing, but I found no good documentation on the changes in the Maven plugin (side note, a reference of the plugin's configuration options and goals in the typical maven plugin documentation style would be awesome - the documentation under https://www.apicur.io/registry/docs/apicurio-registry/3.0.x/getting-started/assembly-managing-registry-artifacts-maven.html is rather spotty), and it isn't covered in the migration guide at all.

Some things I stumbled over:

• <type> is <artifactType> now
• <registryUrl> now has to point to /apis/registry/v3 instead of the server root
• <ifExists> enum values have changed

2. Mismatch on existing schemas

I have successfully migrated my schemas over from the v2 registry following the migration guide.

However, when I now try to re-register the exact, unchanged version of an artifact again, I get a 409 VersionAlreadyExistsException. Doing the same with the v2 client against the v2 server is successful. This seems to be the case for all artifacts that have references.

Artifact definition:

    <artifact>
        <groupId>default</groupId>
        <artifactId>MyExampleEvent</artifactId>
        <version>9</version>
        <artifactType>AVRO</artifactType>
        <file>
            ${project.build.directory}/avro/MyExampleEvent.avsc
        </file>
        <ifExists>FIND_OR_CREATE_VERSION</ifExists>
        <canonicalize>true</canonicalize>
        <references>
            <reference>
                <groupId>default</groupId>
                <artifactId>MyExampleReference</artifactId>
                <version>3</version>
                <artifactType>AVRO</artifactType>
                <ifExists>FIND_OR_CREATE_VERSION</ifExists>
                <canonicalize>true</canonicalize>
                <file>
                    ${project.build.directory}/avro/MyExampleReference.avsc
                </file>
                <name>
                    org.example.MyExampleReference
                </name>
            </reference>
        </references>
    </artifact>

Due to #5627 I wasn't able to verify what would happen if I used the v2 plugin against the v3 server. But as I understand, canonicalization and content matching is done completely server-side, so I would expect it's actually the same.

3. Rule violation causes not visible

When the upload fails due to a rule violation (e.g. the aforementioned VersionAlreadyExistsException), the only information I get is a generic "rule violation" message devoid of any information as to the rule or the cause of its violation:

[ERROR] Exception while registering artifact [default] / [MyExampleEvent]
io.apicurio.registry.rest.client.models.RuleViolationProblemDetails
    at io.apicurio.registry.rest.client.models.RuleViolationProblemDetails.createFromDiscriminatorValue (RuleViolationProblemDetails.java:62)
    at io.kiota.serialization.json.JsonParseNode.getObjectValue (JsonParseNode.java:247)
    at io.kiota.http.vertx.VertXRequestAdapter.lambda$throwIfFailedResponse$0 (VertXRequestAdapter.java:400)
    ...

I had to debug into the plugin to find out which rule was violated here. Not sure if it's the same for violations other than VersionAlreadyExists.

4. Vert.x not shut down cleanly

Not sure if this is caused by the preceding upload errors, but the Maven build always ends with an exception that is apparently caused by Vert.x still running in the background while the plugin's class realm is torn down:

Exception in thread "Thread-4" java.lang.NoClassDefFoundError: io/vertx/core/file/impl/FileSystemImpl$11
        at io.vertx.core.file.impl.FileSystemImpl.delete(FileSystemImpl.java:898)
        at io.vertx.core.file.impl.FileCache.deleteCacheDir(FileCache.java:140)
        at io.vertx.core.file.impl.FileCache.lambda$runHook$0(FileCache.java:92)
        at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.ClassNotFoundException: io.vertx.core.file.impl.FileSystemImpl$11
        at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
        at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:225)
        at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:210)
        at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:205)
        ... 4 more

5. Vert.x incompatibility on Windows

More of an fyi, but I wasn't able to use the v3 plugin at all at first, because the netty client used under the hood wasn't able to configure the correct DNS servers from the OS. This seems to be a problem of running Vert.x inside of Maven, because outside of it, this works perfectly.

I filed codehaus-plexus/plexus-classworlds#119 for this one.

Workaround was: MAVEN_OPTS="--add-opens jdk.naming.dns/com.sun.jndi.dns=java.naming"

[apicurio-bot]

Thank you for reporting an issue!

Pinging @jsenko to respond or triage.