On 06/04/2020 14:26, Claus Ibsen wrote:
On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <ppal...@redhat.com> wrote:
Hi,
thanks Claus for writing this down.
On 06/04/2020 09:58, Claus Ibsen wrote:
Hi
Background this PR
https://github.com/apache/camel/pull/3698
a)
I think it can benefit Camel components if we are able to define what
maturity/stability level the component is (find a good name). For
example we could the values that other projects uses such as Quarkus
and WildFly: Stable, Preview, Experimental
However the devil is in the wording. For example does Stable mean that
it's stable forever. And that is a NO. A camel component may change
between LTS releases, as we want to innovate fast and move on. For
example a 3rd party dependency upgrade may cause some changes, or a
major upgrade which we want. SB1 to SB2 etc. netty3 -> netty4. And
sometimes we created a new component and other times we upgraded the
existing component.
My intention was to express runtime stability of a particular release
rather than API/ABI stability over time. - I.e. if base64 component is
marked as "stable" in release 1.2.3 it means we (the authors) have
enough confidence (based on test coverage and/or a low number of known
issues or limitations, etc.) to recommend deploying it in production.
"Production quality" might be a better term for this. The other value (i
took the term "preview") is supposed to be opposite: There are known
issues, known limitations, not enough test coverage or the code is
simply too new to be confident about its runtime stability.
This marker is assigned to some specific release of a component. If
base64 is marked as "stable" in 1.2.3, it does not necessarily imply
anything about the future releases. It may (although it would be rather
unusual) become "preview" in the future (say, because an early major
upgrade of its dependency is instable). It may be removed (after some
deprecation period), its configuration may change substantialy, etc. The
stability assessment is done only for the given release and nothing else.
Yeah actually this is better description of the purpose, so its per release
and dont necessary warrant the same level in the next release.
And this also makes sense for some users to have a hint/warn reported
if they use a non-stable component.
For example with some tooling to report this, or some flag we can turn
on|off in Camel to report this on startup.
b)
The second information that may benefit, is whether a component would
be compilable for native via graalvm. But at this moment then I think
this information is best kept in camel-quarkus as this is where we
know whether its fully native or jvm only.
So I would keep this information in the camel quarkus catalog only.
Yes, Camel Quarkus will presumably be the only one to have the Native
compilation target in its catalog. However, Camel K will leverage that
info and thus the common Camel Catalog model should IMO be able to
express that state. Having a custom catalog model in Camel Quarkus seems
to be impractical for both Camel Quarkus and Camel K. Is that what you
propose?
Yes Camel Quarkus is the only project that has this knowledge. And it
also have some components that are only there,
such as the camel-cute component.
So if Camel K wants to know which extensions are native or not, then
it should use the camel-quarkus catalog.
I agree with you about where the actual Catalog data should be hosted.
What I am still wondering is whether the common Camel Catalog model can
be used to read and write that data. Whether the new field
compilationTarget (or however we name it) may live in BaseModel
https://github.com/apache/camel/pull/3698/files#diff-a802aba48ea32a673ee46150dc70028aR35
or whether Camel Quarkus and Camel K have to define a custom extension
to that model (which I'd find highly impractical).
-- P
This is the game, same for OSGi with the camel-karaf catalog, and for
Spring Boot with the camel-spring-boot catalog.
Ad a)
We could then store this information about maturity level in the
<properties> section of pom.xml where we already store labels,
description, and whether its deprecated.
<properties>
<stability>stable</stability>
...
</properties>
No problem with that. The PR linked above checks the @Experimental
annotation on component, language, etc. classes and if it is present, it
makes the given component "preview". I can remove that.
Thanks,
-- Peter
