Good point about the distinction of API and SPI, Pierre!
I'd add from my side that I think polaris-core is in the middle of API and
SPI. Polaris-core can be used in downstream projects and called via its API
(as a library). At the same time downstream projects can plug in different
SPI implementat
It would probably be good to separate the API modules, which define what
other systems can consume, from SPI modules, which define what other
systems can _extend_. Those are two different concerns and could require
two distinct sets of dependencies.
However I do not think we should consider the c
I think we could combine annotation-based stability markers with
module/package separation.
One possible example roadmap could look like this:
- Polaris 1.2: mark key interfaces as @Evolving.
- Polaris 1.3: move them into a polaris-api module and mark the old
locations as @Deprecated.
- Polaris 1.
Looks like we got a consensus to confine SPI in certain modules. Here are a
few candidates:
1. polaris-core
2. All modules under /api
3. polaris-runtime-service, this module is a bit controversial, as it holds
a lot of implementation as well as interfaces. Options would be 1. to move
interfaces to
> If a downstream project uses CDI and something comes out of alignment,
that is usually detected at compile time, so it's still as explicit as
renaming a method IMHO :)
It is certainly obvious to the owners of the downstream project, but in the
context of this discussion, it's not visible to PR a
Hi Michael,
I'm not sure I completely understand your point about explicit vs. implicit.
>From my POV, existing Apache Polaris code is always explicit since it is
available for inspection end-to-end, injection points are annotated and
injection behaviour is controlled by explicit configuration.
Thanks Dennis for listing these SPIs. To make it easy for developer to
understand, I think we have multiple options
1. Annotation-based approach, Apache Spark adopts it, e.g., @Stable,
@@Experimental. It is fine-grained, but it brings a lot of maintenance
costs. For example, which interfaces shoul
Possibly a point with mentioning, then, is that dependencies must be
explicit in order to be clear about where there’s an extension contract.
Some of the CDI work has led to things being less clear as things that were
explicitly passed around are now simply @Injected whenever they’re needed.
That m
Thanks for starting this discussion! Definitely a current gap not having
well-established SPI delineations.
As a starting point, certainly any of the runtime-configurable
factory/supplier types demonstrate intent for service-provider
extensibility achievable without modifying any Polaris code dire
Hi all,
Recently it became apparent that the community has no single opinion
about what an integration point that downstream consumers can rely on
in terms of availability, stability and most importantly functional
and behavioral contracts is.
The Polaris code base itself is still pretty fresh/yo
10 matches
Mail list logo
