You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2020/04/06 07:58:42 UTC
[DISCUSS] - Camel components - Information about stability and native compilation
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
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Apr 6, 2020 at 4:17 PM David Jencks <da...@gmail.com> wrote:
>
> I’ve been looking at the tables of components, data formats, etc in the website and wondering if it would be useful to show "version deprecated since” rather than just the deprecated flag. Is this information even available? Does this seem like a good idea? I expect to propose a different way to construct the tables shortly. IIUC these tables are constructed from the same info source as the catalog.
>
David, you are welcome to look at
https://issues.apache.org/jira/browse/CAMEL-14866
For deprecatedSince then we dont have that information, but we could
include it in the camel-catalog for Camel 3.3 onwards.
I have created a ticket about this
https://issues.apache.org/jira/browse/CAMEL-14867
> David Jencks
>
> > On Apr 6, 2020, at 5:26 AM, Claus Ibsen <cl...@gmail.com> wrote:
> >
> > On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <ppalaga@redhat.com <ma...@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.
> >
> > 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
> >>
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com <http://davsclaus.com/> @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Onder SEZGIN <on...@apache.org>.
+1 to David Jencks.
i raised a while ago but coul not start doing anything on it.
https://camel.465427.n5.nabble.com/deprecated-components-by-which-version-of-camel-td5842700.html
it would be a good addition while playing around with models.
On Mon, Apr 6, 2020 at 5:17 PM David Jencks <da...@gmail.com>
wrote:
> I’ve been looking at the tables of components, data formats, etc in the
> website and wondering if it would be useful to show "version deprecated
> since” rather than just the deprecated flag. Is this information even
> available? Does this seem like a good idea? I expect to propose a
> different way to construct the tables shortly. IIUC these tables are
> constructed from the same info source as the catalog.
>
> David Jencks
>
> > On Apr 6, 2020, at 5:26 AM, Claus Ibsen <cl...@gmail.com> wrote:
> >
> > On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <ppalaga@redhat.com
> <ma...@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.
> >
> > 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
> >>
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com <http://davsclaus.com/> @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2 <
> https://www.manning.com/ibsen2>
>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by David Jencks <da...@gmail.com>.
I’ve been looking at the tables of components, data formats, etc in the website and wondering if it would be useful to show "version deprecated since” rather than just the deprecated flag. Is this information even available? Does this seem like a good idea? I expect to propose a different way to construct the tables shortly. IIUC these tables are constructed from the same info source as the catalog.
David Jencks
> On Apr 6, 2020, at 5:26 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
> On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <ppalaga@redhat.com <ma...@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.
>
> 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
>>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I om okay with a base model have all the potential options across the
different sub projects.
But I dont want the main camel catalog to have data in its catalog
that dont belong there, like the native compilation.
On Mon, Apr 6, 2020 at 4:14 PM Peter Palaga <pp...@redhat.com> wrote:
>
> On 06/04/2020 14:26, Claus Ibsen wrote:
> > On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <pp...@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
> >>
> >
> >
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Peter Palaga <pp...@redhat.com>.
On 06/04/2020 14:26, Claus Ibsen wrote:
> On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <pp...@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
>>
>
>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <pp...@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.
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
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Peter Palaga <pp...@redhat.com>.
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.
> 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?
> 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
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Andrea Cosentino <an...@yahoo.com.INVALID>.
+1 for me.
--
Andrea Cosentino
----------------------------------
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Friday, April 17, 2020, 08:43:11 AM GMT+2, Peter Palaga <pp...@redhat.com> wrote:
Hi,
for the JVM vs Native, Claus proposed a simple boolean attribute
"nativeSupported" yesterday in a chat. It is kind of an escape from the
situation where agree about the usefulness of the "Native" value, but we
cannot find a good name for the attribute and the other "JVM" value.
"nativeSupported" = true|false is pretty minimal and is able to encode
the info we need to pass from Camel Quarkus to Camel K. I'd implement it
unless somebody wants to veto?
Thanks,
-- Peter
On 08/04/2020 10:38, Claus Ibsen wrote:
> Hi
>
> Okay I am moving forward with Peters work, and for starters grab the
> supportLevel piece as that is general and a good addition.
> I have modified the PR and include 3 levels: Experimental, Preview and Stable.
>
> And made changes so we can specify the level in the pom.xml file, as
> that allows to set it explicit for all artefact types.
>
> For the JVM vs Native then let's wait a bit to come up with a better
> term and implementation.
>
> On Tue, Apr 7, 2020 at 11:10 AM Claus Ibsen <cl...@gmail.com> wrote:
>>
>> Hi
>>
>> compiler is likely a bad name, as there are some JDK distributions
>> with their own compilers (IBM J9 compiler, azul has a compiler, etc).
>> So lets kees keep the native/graalvm in camel-quarkus for now, that is
>> where this innovation is happening.
>>
>> However the other thing with the maturity level is a good idea and we
>> should add that to the model.
>>
>> On Tue, Apr 7, 2020 at 10:03 AM Alex Dettinger <al...@gmail.com> wrote:
>>>
>>> Indeed, and conversely we could imagine graal being replaced by another
>>> compile-to-native technology in quarkus or quarkus being able to support a
>>> new kind of VM.
>>> So the place is more in the Camel Quarkus catalog and we may stick to the
>>> quarkus terminology.
>>>
>>> As such, I see native as a better term than graal. And the only quarkus
>>> word generalizing JVM + Native I could think about from quarkus wording is
>>> "mode".
>>> In a way, supporterCompilers could be an idea too, but I don't see JVM has
>>> a possible value then. Maybe there are some other quarkus words applying ?
>>>
>>> On Mon, Apr 6, 2020 at 10:23 PM Peter Palaga <pp...@redhat.com> wrote:
>>>
>>>> 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 <cl...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <om...@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 <cl...@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
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Peter Palaga <pp...@redhat.com>.
Hi,
for the JVM vs Native, Claus proposed a simple boolean attribute
"nativeSupported" yesterday in a chat. It is kind of an escape from the
situation where agree about the usefulness of the "Native" value, but we
cannot find a good name for the attribute and the other "JVM" value.
"nativeSupported" = true|false is pretty minimal and is able to encode
the info we need to pass from Camel Quarkus to Camel K. I'd implement it
unless somebody wants to veto?
Thanks,
-- Peter
On 08/04/2020 10:38, Claus Ibsen wrote:
> Hi
>
> Okay I am moving forward with Peters work, and for starters grab the
> supportLevel piece as that is general and a good addition.
> I have modified the PR and include 3 levels: Experimental, Preview and Stable.
>
> And made changes so we can specify the level in the pom.xml file, as
> that allows to set it explicit for all artefact types.
>
> For the JVM vs Native then let's wait a bit to come up with a better
> term and implementation.
>
> On Tue, Apr 7, 2020 at 11:10 AM Claus Ibsen <cl...@gmail.com> wrote:
>>
>> Hi
>>
>> compiler is likely a bad name, as there are some JDK distributions
>> with their own compilers (IBM J9 compiler, azul has a compiler, etc).
>> So lets kees keep the native/graalvm in camel-quarkus for now, that is
>> where this innovation is happening.
>>
>> However the other thing with the maturity level is a good idea and we
>> should add that to the model.
>>
>> On Tue, Apr 7, 2020 at 10:03 AM Alex Dettinger <al...@gmail.com> wrote:
>>>
>>> Indeed, and conversely we could imagine graal being replaced by another
>>> compile-to-native technology in quarkus or quarkus being able to support a
>>> new kind of VM.
>>> So the place is more in the Camel Quarkus catalog and we may stick to the
>>> quarkus terminology.
>>>
>>> As such, I see native as a better term than graal. And the only quarkus
>>> word generalizing JVM + Native I could think about from quarkus wording is
>>> "mode".
>>> In a way, supporterCompilers could be an idea too, but I don't see JVM has
>>> a possible value then. Maybe there are some other quarkus words applying ?
>>>
>>> On Mon, Apr 6, 2020 at 10:23 PM Peter Palaga <pp...@redhat.com> wrote:
>>>
>>>> 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 <cl...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <om...@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 <cl...@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
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Okay I am moving forward with Peters work, and for starters grab the
supportLevel piece as that is general and a good addition.
I have modified the PR and include 3 levels: Experimental, Preview and Stable.
And made changes so we can specify the level in the pom.xml file, as
that allows to set it explicit for all artefact types.
For the JVM vs Native then let's wait a bit to come up with a better
term and implementation.
On Tue, Apr 7, 2020 at 11:10 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> Hi
>
> compiler is likely a bad name, as there are some JDK distributions
> with their own compilers (IBM J9 compiler, azul has a compiler, etc).
> So lets kees keep the native/graalvm in camel-quarkus for now, that is
> where this innovation is happening.
>
> However the other thing with the maturity level is a good idea and we
> should add that to the model.
>
> On Tue, Apr 7, 2020 at 10:03 AM Alex Dettinger <al...@gmail.com> wrote:
> >
> > Indeed, and conversely we could imagine graal being replaced by another
> > compile-to-native technology in quarkus or quarkus being able to support a
> > new kind of VM.
> > So the place is more in the Camel Quarkus catalog and we may stick to the
> > quarkus terminology.
> >
> > As such, I see native as a better term than graal. And the only quarkus
> > word generalizing JVM + Native I could think about from quarkus wording is
> > "mode".
> > In a way, supporterCompilers could be an idea too, but I don't see JVM has
> > a possible value then. Maybe there are some other quarkus words applying ?
> >
> > On Mon, Apr 6, 2020 at 10:23 PM Peter Palaga <pp...@redhat.com> wrote:
> >
> > > 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 <cl...@gmail.com>
> > > wrote:
> > > >
> > > >> On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <om...@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 <cl...@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
> > > >>
> > > >
> > >
> > >
>
>
>
> --
> 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
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
compiler is likely a bad name, as there are some JDK distributions
with their own compilers (IBM J9 compiler, azul has a compiler, etc).
So lets kees keep the native/graalvm in camel-quarkus for now, that is
where this innovation is happening.
However the other thing with the maturity level is a good idea and we
should add that to the model.
On Tue, Apr 7, 2020 at 10:03 AM Alex Dettinger <al...@gmail.com> wrote:
>
> Indeed, and conversely we could imagine graal being replaced by another
> compile-to-native technology in quarkus or quarkus being able to support a
> new kind of VM.
> So the place is more in the Camel Quarkus catalog and we may stick to the
> quarkus terminology.
>
> As such, I see native as a better term than graal. And the only quarkus
> word generalizing JVM + Native I could think about from quarkus wording is
> "mode".
> In a way, supporterCompilers could be an idea too, but I don't see JVM has
> a possible value then. Maybe there are some other quarkus words applying ?
>
> On Mon, Apr 6, 2020 at 10:23 PM Peter Palaga <pp...@redhat.com> wrote:
>
> > 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 <cl...@gmail.com>
> > wrote:
> > >
> > >> On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <om...@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 <cl...@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
> > >>
> > >
> >
> >
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Alex Dettinger <al...@gmail.com>.
Indeed, and conversely we could imagine graal being replaced by another
compile-to-native technology in quarkus or quarkus being able to support a
new kind of VM.
So the place is more in the Camel Quarkus catalog and we may stick to the
quarkus terminology.
As such, I see native as a better term than graal. And the only quarkus
word generalizing JVM + Native I could think about from quarkus wording is
"mode".
In a way, supporterCompilers could be an idea too, but I don't see JVM has
a possible value then. Maybe there are some other quarkus words applying ?
On Mon, Apr 6, 2020 at 10:23 PM Peter Palaga <pp...@redhat.com> wrote:
> 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 <cl...@gmail.com>
> wrote:
> >
> >> On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <om...@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 <cl...@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
> >>
> >
>
>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Peter Palaga <pp...@redhat.com>.
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 <cl...@gmail.com> wrote:
>
>> On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <om...@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 <cl...@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
>>
>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Alex Dettinger <al...@gmail.com>.
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.
hth ;)
Alex
On Mon, Apr 6, 2020 at 10:36 AM Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <om...@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 <cl...@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
>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi <om...@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 <cl...@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
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Omar Al-Safi <om...@oalsafi.com>.
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.
Regards,
Omar
On Mon, Apr 6, 2020 at 9:59 AM Claus Ibsen <cl...@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
>
Re: [DISCUSS] - Camel components - Information about stability and
native compilation
Posted by Andrea Cosentino <an...@gmail.com>.
Hello,
For a) I do believe we should use something different from stable, we can
use something like "long-term existence" (thats sounds horrible)
For b) I agree it is something specific to Quarkus for the moment
We need a list of support/maturity/stability levels..
Il giorno lun 6 apr 2020 alle ore 09:59 Claus Ibsen <cl...@gmail.com>
ha scritto:
> 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
>