Improve maven setup for Maven 4.x compatibility

[wendigo]

No description provided.

[wendigo]

@findepi PTAL

[electrum]

Do we actually ship artifacts from this repository? I thought it was only for testing.

[wendigo]

Good question. We shouldn't

[hashhar]

we shouldn't ship them, since those classes get loaded conditionally and need to be provided by the users.

See

trino/plugin/trino-kafka/src/main/java/io/trino/plugin/kafka/schema/confluent/ConfluentModule.java

Lines 189 to 190 in b90fe09

	// Make JVM to load lazily ProtobufSchemaProvider, so Kafka connector can be used
	// without protobuf dependency for non protobuf based topics

and

trino/plugin/trino-kafka/src/main/java/io/trino/plugin/kafka/schema/confluent/ConfluentModule.java

Lines 256 to 257 in b90fe09

	// Make JVM to load lazily ProtobufSchemaParser, so Kafka connector can be used
	// without protobuf dependency for non protobuf based topics

There's tests for that - https://github.com/trinodb/trino/blob/master/testing/trino-product-tests-launcher/src/main/java/io/trino/tests/product/launcher/env/environment/EnvMultinodeConfluentKafka.java has the confluent jars on classpath while other env does not and we verify that nothing fails without those classes on classpath as long as you don't use specific functionality.

[wendigo]

Yes. it seems that maven 4.x is just more strict. So it doesn't import repository definition from a dependency, which is a good thing I believe. It's just needed to resolve dependencies (provided one as well) but the jar is not part of the final build anyway. All good, just more strict!

[electrum]

We could probably avoid this by moving the Confluent code into a new module with <optional>true</optional>, so that the Kafka plugin won't have a direct dependency on it, but this is fine for now.