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, Prev
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
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
On Mon, Apr 6, 2020 at 10:14 AM Omar Al-Safi 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 bei
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-gr
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
On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga 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 d
On 06/04/2020 14:26, Claus Ibsen wrote:
On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga 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
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
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 wrote:
>
> On 06/04/2020 14:26, Cla
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/q
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 t
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
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
+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
wrote:
>
On Mon, Apr 6, 2020 at 4:17 PM David Jencks 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 th
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.
"nativeSup
+1 for me.
--
Andrea Cosentino
--
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Friday, April 17, 2020, 08:43:11 AM GMT+2, Peter Palaga
wrote:
Hi,
for the J
18 matches
Mail list logo
