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