Hello! No objection to the move :/ But what do you think about publishing the test jar created in google-cloud-platform to be reused without moving the code to the main artifact jar?
I admit that I'm familiar with this technique with maven, and not at all with gradle, but it's described here: https://maven.apache.org/guides/mini/guide-attached-tests.html It relies on the classifier to distinguish between test classes and main classes. Is this possible and/or easy with gradle? I've used this in the past to create "re-usable test artifacts" that remain independent from "real" code but tightly associated with the main artifact. I noticed that elasticsearch publishes main artifacts with `-test` in the artifact name as an alternative strategy (i.e. a separate project). All my best, Ryan On Wed, Jul 31, 2019 at 5:55 AM Mikhail Gryzykhin <gryzykhin.mikh...@gmail.com> wrote: > > +1 > It is completely worth it. > > On Tue, Jul 30, 2019 at 8:50 PM Rui Wang <ruw...@google.com> wrote: >> >> +1. >> >> I did something similar before: move TestBoundedTable to BeamSQL main to >> allow another module tests use it. >> >> >> -Rui >> >> On Tue, Jul 30, 2019 at 6:13 PM Pablo Estrada <pabl...@google.com> wrote: >>> >>> Hello all, >>> I found some test utilities that we use to write unit tests for transforms >>> that read/write to/from BigQuery. These are all the >>> non-(*IT.java/*Test.java) classes in [1]. >>> >>> I believe that users may want to write tests for their own pipelines that >>> may rely on complex DynamicDestination logic (imagine streaming, or side >>> inputs for on-the-fly schema computation, or other tricky issues). >>> >>> I think it makes sense to move these classes to >>> org.apache.beam.io.gcp.bigquery.testing, and publish them in the release. >>> Thoughts? >>> >>> -P. >>> >>> [1] >>> https://github.com/apache/beam/tree/master/sdks/java/io/google-cloud-platform/src/test/java/org/apache/beam/sdk/io/gcp/bigquery
