It probably makes sense. But I am exhausted, utterly exhausted, with the "moving stuff around" that Vladimir has done over the last few months.
For example. I ran into a problem running SqlPrettyWriterTest a few days ago[1] that did not exist a few months ago (before the gradle/junit upgrade). After I solved that problem, I can into another, and another. After 3 or 4 days, I am still unable to run the test and have Intellij show the difference in a pop-up window. What caused these problems? Maybe the transition from maven to gradle. Maybe I didn't adequately clean out generated files in my sandox when I transitioned my Intellij project to gradle. Maybe I should be using gradle-based tests in Intellij rather than junit-based tests. Maybe the transition from junit4 to junit5. Who knows? All of those changes were done by Vladimir. Not one of these changes adds a single feature, or fixes a single bug, in "Calcite the product", the library we deliver to our end-users. All of them are supposedly to make developers' lives easier, but I have lost a week. Julian [1] https://issues.apache.org/jira/browse/CALCITE-3595 On Tue, Dec 17, 2019 at 12:49 PM Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > 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
