Closed C0urante closed 5 years ago
@chrise do you recall what classloading issues you ran into because of this setup?
@wicknicks the dependencies for the Avro converter are excluded from packaging with this connector. So if the AvroConverter
class packaged with the connector gets picked up as a converter plugin by Connect, it'll fail since a bunch of classes it relies on are missing.
The
kafka-connect-avro-converter
dependency is added to the POM for this connector so that theAvroData
class can be used to convert from Avro to the Connect record format, but the actualAvroConverter
class (or any of its nested classes) is never used. However, the Connect framework will still sometimes pick up theAvroConverter
present in the plugin archive for the datagen connector and try to use that as an actual converter plugin, even though most of the transitive dependencies for thekafka-connect-avro-converter
dependency are excluded, which then causes classloading issues. The changes here are a bit of a hack: they alter the Confluent Hub archive generated during the connector build by removing theAvroConverter
class (and all of its nested classes) from thekafka-connect-avro-converter
JAR file, so that the converter is never picked up as a plugin by the Connect framework. We could consider publishing theAvroData
class as a separate Maven artifact so that people could add it as a dependency to their project without risk of this happening, but in the meantime, here's a quick-and-dirty solution that allows the connector to work alongside the Avro converter when both are loaded using the plugin path mechanism in Connect.