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 <aldettin...@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 <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 > > >> > > > > > > > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
