Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Enable test code sharing #197
It looks like you haven't signed our Contributor License Agreement, yet.
You can read and sign our full Contributor License Agreement here.
Once you've signed reply with
Appreciation of efforts,
Refer to this link for build results (access rights to CI server needed):
@larsp I don't think this patch results in any test classes getting packaged in the jar -- it creates a test-jar for the parent project (since you added the test-jar command to the top-level pom.xml), but the parent project has no test classes so you just get a jar file doesn't contain anything useful.
I'm also not sure we want to use the
Which set of classes are you trying to reuse elsewhere? I'm guessing you want ClusterTestHarness since I don't see much else that could be reused. If it's a very limited set of classes from the
Hi @ewencp, you are right that it will create a test jar for the parent pom. Nevertheless is the parent pom referenced as parent in the other module poms and therefore inherits the plugin execution:
$ find . -name "*-tests.jar" ./avro-serializer/target/kafka-avro-serializer-2.0-SNAPSHOT-tests.jar ./client/target/kafka-schema-registry-client-2.0-SNAPSHOT-tests.jar ./core/target/kafka-schema-registry-2.0-SNAPSHOT-tests.jar ./json-serializer/target/kafka-json-serializer-2.0-SNAPSHOT-tests.jar ./target/kafka-schema-registry-parent-2.0-SNAPSHOT-tests.jar
afterwards each individual test jar can be loaded in maven using the classifier
<dependency> <groupId>io.confluent</groupId> <artifactId>kafka-schema-registry</artifactId> <version>2.0-SNAPSHOT</version> <classifier>tests</classifier> <scope>test</scope> </dependency>
Or in gradle via
I wanted to use
@larsp Of course you are correct, I must have been working from a dirty build and missed those test jars.
I'm going to merge this patch. Since everything is in test-jars, I'd still consider them private and therefore unsupported, no compatibility guarantees etc. I think if we want to provide something that will be consistently reusable, even across releases, we should probably try to refactor just those pieces into a separate module. But we can also just do that in a follow up patch.
I've also followed this up with equivalent commits in confluentinc/common, confluentinc/rest-utils, and confluentinc/kafka-rest just so the jars will get published. confluentinc/camus already had the relevant config in the pom file.