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 <ppal...@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 <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 > >> > > > >
