I'll share my take on this.
My first choice would be leveraging the Java access modifiers, which
enforce the visibility by the programming language. Users won't see
non-public classes at all. That is best for the users. Peter mentioned the
potential downside of collocating 50 classes under one pac
Thanks Eduard,
> Are iceberg-flink users aware that classes annotated with @Internal can
potentially break API/ABI compatibility between Iceberg versions
It is documented here:
https://nightlies.apache.org/flink/flink-docs-master/docs/ops/upgrading/
*The classes & members of the Java/Scala APIs
Having a separate "api" gradle module seems a lot of work and so starting
with an "api" package seems to make sense to me. This obviously has the
side-effect you mentioned (requiring package-private classes to be public).
I don't think we have anything in particular in the Iceberg codebase that
wo
One more idea:
- Create a new gradle module for the "api" that would contain all the
classes a client could access.
This would fit nicely to the Iceberg codebase, but would need a serious
refactor of the current code (maybe even the api)
I'm still in favor of the api package solution.
On Wed, Se
