As suggested above, I've prepared a PR that moves CalciteAssert, Matchers,
and a couple of test schemata to the new :testkit module.
calcite-*-tests.jar will no longer be published.
PR: https://github.com/apache/calcite/pull/2558
The tests pass, and the change unlocks migration to Gradle 7.2
Jin>Some of my users write tests based on functionalities provided from
Calcite
Jin>test framework
Frankly speaking, it was somewhat surprising for me, and it does bring
extra demand for having a proper calcite-test-framework.
The naming is hard, however, I would suggest
Julian>All of those changes were done by Vladimir. Not one of these changes
Julian>adds a single feature, or fixes a single bug, in "Calcite the
Julian>product", the library we deliver to our end-users.
Julian, I see you are frustrated that one of your use-cases is broken.
It is really sad it
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
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
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).
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
