+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 <ppal...@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 <claus.ib...@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 <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 > > >
