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
Hi Team,
Currently I'm working on the Flink Table Maintenance see:
https://github.com/apache/iceberg/pull/11144#discussion_r1764015878, and
with Steven we are trying to find a good way to organize the incoming 50
classes.
There will be:
- ~10 classes which will be used by the users
- ~10 classes
