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 <ppal...@redhat.com> wrote: > > On 06/04/2020 14:26, Claus Ibsen wrote: > > On Mon, Apr 6, 2020 at 11:50 AM Peter Palaga <ppal...@redhat.com> 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 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. > >> > >> My intention was to express runtime stability of a particular release > >> rather than API/ABI stability over time. - I.e. if base64 component is > >> marked as "stable" in release 1.2.3 it means we (the authors) have > >> enough confidence (based on test coverage and/or a low number of known > >> issues or limitations, etc.) to recommend deploying it in production. > >> "Production quality" might be a better term for this. The other value (i > >> took the term "preview") is supposed to be opposite: There are known > >> issues, known limitations, not enough test coverage or the code is > >> simply too new to be confident about its runtime stability. > >> > >> This marker is assigned to some specific release of a component. If > >> base64 is marked as "stable" in 1.2.3, it does not necessarily imply > >> anything about the future releases. It may (although it would be rather > >> unusual) become "preview" in the future (say, because an early major > >> upgrade of its dependency is instable). It may be removed (after some > >> deprecation period), its configuration may change substantialy, etc. The > >> stability assessment is done only for the given release and nothing else. > >> > > > > Yeah actually this is better description of the purpose, so its per release > > and dont necessary warrant the same level in the next release. > > > > And this also makes sense for some users to have a hint/warn reported > > if they use a non-stable component. > > For example with some tooling to report this, or some flag we can turn > > on|off in Camel to report this on startup. > > > > > >>> 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. > >> > >> Yes, Camel Quarkus will presumably be the only one to have the Native > >> compilation target in its catalog. However, Camel K will leverage that > >> info and thus the common Camel Catalog model should IMO be able to > >> express that state. Having a custom catalog model in Camel Quarkus seems > >> to be impractical for both Camel Quarkus and Camel K. Is that what you > >> propose? > >> > > > > Yes Camel Quarkus is the only project that has this knowledge. And it > > also have some components that are only there, > > such as the camel-cute component. > > > > So if Camel K wants to know which extensions are native or not, then > > it should use the camel-quarkus catalog. > > I agree with you about where the actual Catalog data should be hosted. > What I am still wondering is whether the common Camel Catalog model can > be used to read and write that data. Whether the new field > compilationTarget (or however we name it) may live in BaseModel > https://github.com/apache/camel/pull/3698/files#diff-a802aba48ea32a673ee46150dc70028aR35 > or whether Camel Quarkus and Camel K have to define a custom extension > to that model (which I'd find highly impractical). > > -- P > > > This is the game, same for OSGi with the camel-karaf catalog, and for > > Spring Boot with the camel-spring-boot catalog. > > > > > >>> 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> > >> > >> No problem with that. The PR linked above checks the @Experimental > >> annotation on component, language, etc. classes and if it is present, it > >> makes the given component "preview". I can remove that. > >> > >> Thanks, > >> > >> -- Peter > >> > > > > > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
