Hi, Vladimir > I suggest we do not publish testlib artifacts to Nexus (who needs > Calcite-related assertions and things like that?)
+1 to have the module be published. Some of my users write tests based on functionalities provided from Calcite test framework. Best, Jin Michael Mior <mm...@apache.org> 于2019年12月18日周三 上午7:47写道： > 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 >
