On 06/04/2020 11:48, Alex Dettinger wrote:
a) I think building on top of sinceVersion is good.
b) I don't have strong opinion yet where such information should go.
I don't feel native is the right word, I would tend to see this as a kind
of platform level support like
karaf/spring-boot/camel-k/quarkus-jvm/quarkus-graal/any-concurrent-of-graal.
Each Camel subproject has its own Catalog: Camel Spring Boot Catalog
contains the info about components supported on Spring Boot, Camel
Quarkus Catalog is supposed to contain the info about the components
supported on Quarkus, etc. So the runtime platform info is implicitly
there already and there is IMO no point in having the platform name as a
prefix in the values of the attribute.
The proposed attribute should allow to classify another level of detail
within the given platform. It is quite well thinkable that one day we
will support Spring Boot in native mode - it is still Spring Boot, but a
different flavor.
Now is "GraalVM" a better name than "Native"? I think both would work
for what we need to encode in Camel Quarkus. However, if we go with
"GraalVM", there is some shift in semantics: GraalVM is just one of
potentially many native compilers and one component may support more
than one of them. Hence the type of the attribute should not be an enum,
but rather a list of supported compilers. Thus the name of the attribute
should perhaps be adjusted to "supportedCompilers" or similar. (I wonder
whether "JVM" can be seen as a compiler?)
-- P
hth ;)
Alex
On Mon, Apr 6, 2020 at 10:36 AM Claus Ibsen <claus.ib...@gmail.com> wrote:
On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <o...@oalsafi.com> wrote:
IMO, I'd mark a component as `stable` after a few Camel releases
that include the component, no idea how many, but this at least gives me
the hint that the component is stable enough for this use. That means, a
new component that is being added to camel code base, I'd mark it as
`Preview`. At least in that sense, it can make sense here.
Yeah but that is also what since version is for, you can see that
today, see the since column,
https://camel.apache.org/components/latest/
But yes we could have a default rule in the build tooling so when we
build a release, it would use preview (if no explicit set and that the
component is new, or N-1 release old).
Then we dont need to remember to update all these components manually over
time.
Regards,
Omar
On Mon, Apr 6, 2020 at 9:59 AM Claus Ibsen <claus.ib...@gmail.com>
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.
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.
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>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
