Update: in my case, the easiest way to unblock the situation was following
suggestion #2 from Jacques ("Write a concrete class that implements the
declared interface").
On Fri, Dec 3, 2021 at 8:58 AM Ruben Q L wrote:
> Hello,
>
> Julian, I find myself in a similar position. I upgraded into Calc
Hello,
Julian, I find myself in a similar position. I upgraded into Calcite 1.28
in a certain project. This project had several custom rules, which (due to
the rule config refactoring [1], [2], [3]) now use some deprecated elements
(e.g. RelRule#Config#EMPTY). Recently I tried to adapt my rules to
Thanks for the prompt reply, Jacques. I’ll explore your suggestions and let you
know what I find.
> On Dec 2, 2021, at 1:33 PM, Jacques Nadeau wrote:
>
> Hey Julian,
>
> To me, there are currently three avenues I envisioned for extension project
> use:
> 1. Use the Immutable project or similar
Hey Julian,
To me, there are currently three avenues I envisioned for extension project
use:
1. Use the Immutable project or similar alternatives (e.g. [1])
2. Write a concrete class that implements the declared interface.
3. Use a record metaphor appropriate to the environment you're in that
impl
>Has anyone else run into this problem?
I've no idea how hard it would be to solve, however, it looks like
something worth doing.
It would be sad to require everyone to add annotation processors to their
builds.
Vladimir
I’m trying to write a planner rule in a dependent project. (What what it’s
worth, the project is not open source, and is implemented in Kotlin.) I don’t
want to make the dependent project depend on the Immutables library, because
that introduces an annotation processor and might destabilize our
