Sounds good to me. Although I'd still like to see the module be
published. I'm currently using it my notebooks project
(https://github.com/michaelmior/calcite-notebooks) because some of the
test code removes boilerplate when writing examples.
--
Michael Mior
mm...@apache.org
Le mar. 17 déc. 2019 à 15:49, Vladimir Sitnikov
<sitnikov.vladi...@gmail.com> a écrit :
>
> Hi,
>
> Currently
> org.apache.calcite.test.CalciteAssert, org.apache.calcite.util.TestUtil,
> and probably other classes are hard to find.
> I suggest we create a testlib module (or something like that), that would
> contain "test framework" code.
>
> That would make test framework easier to discover (one could open the full
> set of packages in the testlib),
> and it would make "autocomplete" better (especially for adapters).
>
> I suggest we do not publish testlib artifacts to Nexus (who needs
> Calcite-related assertions and things like that?)
>
> Currently testImplementation(project(":core", "testClasses")) is used in
> lots of places, and it causes "core"
> test clases appear in autocomplete menu for adapters.
> For example, typing "new Sql..." in GeodeAssertions suggests
> SqlAdvisorJdbcTest which is valid, yet it is weird.
>
> What do you think?
>
> Just in case you did not know: file movement in Git keeps history (even in
> case there are slight modifications).
> However, the key idea here is to keep files in their current packages, but
> move them into teslib module.
>
> Vladimir
