Re: comments on c-k-c docs state && RI preview

[Andrea Cosentino]

I think it would be really great to have it for camel-k and all the other
subprojects.

Il giorno mer 19 gen 2022 alle ore 07:27 Claus Ibsen 
ha scritto:

> On Wed, Jan 19, 2022 at 3:08 AM David Jencks 
> wrote:
> >
> > Putting the conclusion at the top….
> >
> > https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
> 
> >
> > I put the compatibility table at the bottom of the index page, added a
> kamelets column, and turned entries into links where plausible.
> >
> > The table is also on the compatibility matrix page.
> >
> > If the index page looks good, I’ll remove the compatibility page and
> squash everything.
> >
> > No one has commented on whether such a table would be useful or
> desirable for other camel subprojects.
> >
>
> Whoa that matrix looks really good.
>
> Yes I think its a good idea for other sub projects to have this page too.
>
>
>
>
>
> > David Jencks
> >
> > > On Jan 18, 2022, at 6:19 AM, Andrea  wrote:
> > >
> > >
> > >
> > > On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
> > >>
> > >>
> > >>> On Jan 17, 2022, at 1:50 PM, Andrea  wrote:
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
> > 
> > 
> > > On Jan 17, 2022, at 3:23 AM, Andrea  and...@tarocch.it>> wrote:
> > >
> > >
> > >
> > > On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> > >> Thanks, inline...
> > >>
> > >>> On Jan 16, 2022, at 1:04 AM, Andrea  and...@tarocch.it>> wrote:
> > >>>
> > >>> Hello,
> > >>>
> > >>> comments inline:
> > >>>
> > >>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> >  I noticed a few things working on the RI info for
> camel-kafka-connector.
> > 
> >  - the compatibility matrices are thoroughly out of date, e.g.
> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> <
> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
> <
> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> <
> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> >>
> > >>>
> > >>> Awesome, basically a collection of the content of all these notes
> > >>> 
> > >>> could be the generated compatibility matrix page?  Or is there
> already a way where that content is sown other that for the last release?
> > >>
> > >> Here’s a basic generated table for the compatibility matrix:
> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
> > >>
> > >> Note:
> > >> - it will only ever have one line per branch: there’s no way to have
> separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only
> one doc version that covers all of these.
> > >
> > > well in case it is needed we can always do a version from a tag
> > >> - It only has currently documented versions listed. This makes it
> self-maintaining: adding anything else will require periodic manual
> updates, which will gradually decay into wrong or outdated information.
> > >>
> > >> Are these acceptable limitations?
> > >
> > > fine for me
> > >>
> > >> - This version of the table isn’t quite finished: for instance the
> “branch” for next is wrong.  If we like this generated table in principle,
> I can fix that and turn most entries into links.
> > >
> > > can you also add the version of the kamelet catalog?
> > >>
> > >> However, I’m not entirely sure that having this information
> duplicated/aggregated from the index pages is useful. I think we should
> just delete the compatibility matrix page.  WDYT?
> > >
> > > as long as the table is somewhere I don't particularly care; it is
> fine to put it in the index page and remove the compatibility matrix page
> > >>
> > >> On the other hand, if this table is popular, maybe we should have one
> for each  subproject.
> > >>
> > >> David Jencks
> > >>
> > >>>
> > >>>
> > >>> Yep the compatibility matrix page needs some love... a column
> mentioning kamelet catalog version needs to be added and probably we can
> remove some old rows?
> > >>> willing to help on this on too? :)
> > >>
> > >> I think the entire existing matrix is out of date and should be
> removed?  Or are there usable versions of c-k-c that aren’t documented?
> > >>
> > >> I wonder if the RI information is sufficient, WDYT?
> > >
> > > Where can I see a preview of the site with the IR information?
> > 
> > 
> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <
> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>
>  >
> shows all three branches (including 

Re: comments on c-k-c docs state && RI preview

[Claus Ibsen]

On Wed, Jan 19, 2022 at 3:08 AM David Jencks  wrote:
>
> Putting the conclusion at the top….
>
> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html 
> 
>
> I put the compatibility table at the bottom of the index page, added a 
> kamelets column, and turned entries into links where plausible.
>
> The table is also on the compatibility matrix page.
>
> If the index page looks good, I’ll remove the compatibility page and squash 
> everything.
>
> No one has commented on whether such a table would be useful or desirable for 
> other camel subprojects.
>

Whoa that matrix looks really good.

Yes I think its a good idea for other sub projects to have this page too.





> David Jencks
>
> > On Jan 18, 2022, at 6:19 AM, Andrea  wrote:
> >
> >
> >
> > On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
> >>
> >>
> >>> On Jan 17, 2022, at 1:50 PM, Andrea  wrote:
> >>>
> >>>
> >>>
> >>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
> 
> 
> > On Jan 17, 2022, at 3:23 AM, Andrea  > > wrote:
> >
> >
> >
> > On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> >> Thanks, inline...
> >>
> >>> On Jan 16, 2022, at 1:04 AM, Andrea  >>> > wrote:
> >>>
> >>> Hello,
> >>>
> >>> comments inline:
> >>>
> >>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
>  I noticed a few things working on the RI info for 
>  camel-kafka-connector.
> 
>  - the compatibility matrices are thoroughly out of date, e.g. 
>  https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
>   
>  
>   
>     
>  >
> >>>
> >>> Awesome, basically a collection of the content of all these notes
> >>> 
> >>> could be the generated compatibility matrix page?  Or is there already a 
> >>> way where that content is sown other that for the last release?
> >>
> >> Here’s a basic generated table for the compatibility matrix: 
> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
> >>
> >> Note:
> >> - it will only ever have one line per branch: there’s no way to have 
> >> separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only 
> >> one doc version that covers all of these.
> >
> > well in case it is needed we can always do a version from a tag
> >> - It only has currently documented versions listed. This makes it 
> >> self-maintaining: adding anything else will require periodic manual 
> >> updates, which will gradually decay into wrong or outdated information.
> >>
> >> Are these acceptable limitations?
> >
> > fine for me
> >>
> >> - This version of the table isn’t quite finished: for instance the 
> >> “branch” for next is wrong.  If we like this generated table in principle, 
> >> I can fix that and turn most entries into links.
> >
> > can you also add the version of the kamelet catalog?
> >>
> >> However, I’m not entirely sure that having this information 
> >> duplicated/aggregated from the index pages is useful. I think we should 
> >> just delete the compatibility matrix page.  WDYT?
> >
> > as long as the table is somewhere I don't particularly care; it is fine to 
> > put it in the index page and remove the compatibility matrix page
> >>
> >> On the other hand, if this table is popular, maybe we should have one for 
> >> each  subproject.
> >>
> >> David Jencks
> >>
> >>>
> >>>
> >>> Yep the compatibility matrix page needs some love... a column 
> >>> mentioning kamelet catalog version needs to be added and probably we 
> >>> can remove some old rows?
> >>> willing to help on this on too? :)
> >>
> >> I think the entire existing matrix is out of date and should be 
> >> removed?  Or are there usable versions of c-k-c that aren’t documented?
> >>
> >> I wonder if the RI information is sufficient, WDYT?
> >
> > Where can I see a preview of the site with the IR information?
> 
>  https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html 
>  
>   
>     
>  >
>   shows all three branches (including not-quite-released 1.0).
> 
> >>
> >> If you’re sure we need the matrix, let me know where it should start 
> >> and I’ll 

Re: comments on c-k-c docs state && RI preview

[David Jencks]

Putting the conclusion at the top….

https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html 


I put the compatibility table at the bottom of the index page, added a kamelets 
column, and turned entries into links where plausible.

The table is also on the compatibility matrix page.

If the index page looks good, I’ll remove the compatibility page and squash 
everything.

No one has commented on whether such a table would be useful or desirable for 
other camel subprojects.

David Jencks

> On Jan 18, 2022, at 6:19 AM, Andrea  wrote:
> 
> 
> 
> On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
>> 
>> 
>>> On Jan 17, 2022, at 1:50 PM, Andrea  wrote:
>>> 
>>> 
>>> 
>>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
 
 
> On Jan 17, 2022, at 3:23 AM, Andrea  > wrote:
> 
> 
> 
> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
>> Thanks, inline...
>> 
>>> On Jan 16, 2022, at 1:04 AM, Andrea >> > wrote:
>>> 
>>> Hello,
>>> 
>>> comments inline:
>>> 
>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
 I noticed a few things working on the RI info for 
 camel-kafka-connector.
 
 - the compatibility matrices are thoroughly out of date, e.g. 
 https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
  
 
  
 >
>>> 
>>> Awesome, basically a collection of the content of all these notes
>>> 
>>> could be the generated compatibility matrix page?  Or is there already a 
>>> way where that content is sown other that for the last release?
>> 
>> Here’s a basic generated table for the compatibility matrix: 
>> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
>> 
>> Note:
>> - it will only ever have one line per branch: there’s no way to have 
>> separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only one 
>> doc version that covers all of these.
> 
> well in case it is needed we can always do a version from a tag
>> - It only has currently documented versions listed. This makes it 
>> self-maintaining: adding anything else will require periodic manual updates, 
>> which will gradually decay into wrong or outdated information.
>> 
>> Are these acceptable limitations? 
> 
> fine for me
>> 
>> - This version of the table isn’t quite finished: for instance the “branch” 
>> for next is wrong.  If we like this generated table in principle, I can fix 
>> that and turn most entries into links. 
> 
> can you also add the version of the kamelet catalog?
>> 
>> However, I’m not entirely sure that having this information 
>> duplicated/aggregated from the index pages is useful. I think we should just 
>> delete the compatibility matrix page.  WDYT? 
> 
> as long as the table is somewhere I don't particularly care; it is fine to 
> put it in the index page and remove the compatibility matrix page
>> 
>> On the other hand, if this table is popular, maybe we should have one for 
>> each  subproject.
>> 
>> David Jencks
>> 
>>> 
>>> 
>>> Yep the compatibility matrix page needs some love... a column 
>>> mentioning kamelet catalog version needs to be added and probably we 
>>> can remove some old rows?
>>> willing to help on this on too? :)
>> 
>> I think the entire existing matrix is out of date and should be removed? 
>>  Or are there usable versions of c-k-c that aren’t documented?
>> 
>> I wonder if the RI information is sufficient, WDYT?
> 
> Where can I see a preview of the site with the IR information?
 
 https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html 
  
 >
  shows all three branches (including not-quite-released 1.0).
 
>> 
>> If you’re sure we need the matrix, let me know where it should start and 
>> I’ll make some PRs.  I’d suggest having only one copy, perhaps in next, 
>> and referring to it from the other branches.
>>> 
 
 - All other camel subprojects use e.g. 2.5.x as the Antora component 
 version, but c-k-c is using 0.11.0.  Especially since it’s LTS I think 
 we should change it to 0.11.x so when 0.11.1 comes out the version 
 

Re: [HEADS UP] - Renaming inconsistent data format names in model

[Claus Ibsen]

On Tue, Jan 18, 2022 at 4:39 PM Marat Gubaidullin
 wrote:
>
> camel-yaml-dsl.json and camelYamlDsl.json
>

Yes this is a good idea and nice hint in the file name.

I created a ticket
https://issues.apache.org/jira/browse/CAMEL-17510

> On Tue., Jan. 18, 2022, 09:05 Claus Ibsen  wrote:
>
> > On Tue, Jan 18, 2022 at 2:39 PM Luca Burgazzoli 
> > wrote:
> > >
> > > On Tue, Jan 18, 2022 at 2:31 PM Claus Ibsen 
> > wrote:
> > >
> > > > On Tue, Jan 18, 2022 at 12:39 AM Marat Gubaidullin
> > > >  wrote:
> > > > >
> > > > > 1. I could omit kebab cased properties in generator while we have
> > both.
> > > > > 2. When read YAML Karavan "camelize" properties and DSL. Internal
> > Karavan
> > > > > Camel Definitions are in camel case. So output YAML is also camel
> > case.
> > > > >
> > > >
> > > > Yeah we can do that and for Camel 3.15 have both camelCase and
> > > > kebab-case in the yaml-dsl.
> > > > Where kebab-case is deprecated.
> > > >
> > >
> > > I'm not very sure we can support both kebab anc camel case in
> > > camel-yaml-dsl.json, (as
> > > example,. there may be an issue with required properties) however we may
> > > think to just
> > > deprecate the kebab case in the json schema but we can keep support in
> > the
> > > yaml loader.
> > >
> >
> > Ah so could we just generate two schema files, one with kebab-case and
> > another with camelCase.
> > Then Marat can use the camelCase for the Karavan tool.
> >
> > The current yaml-dsl is all kebab-case based, in the generated model
> > serializers.
> >
> > The parser is conforming to kebab-case, eg such as (so we support both
> > cases in the parser/loader)
> >
> > final String propertyName =
> > StringHelper.camelCaseToDash(key.getValue()).toLowerCase(Locale.US);
> >
> >
> >
> >
> > >
> > > > This gives us that "wriggle room" to let kamelets, camel-k and others
> > > > migrate to camelCase.
> > > > Then in Camel 3.16 og 3.17 we can drop kebab and when we are fully
> > > > migrated.
> > > >
> > > >
> > > >
> > > > > On Mon., Jan. 17, 2022, 09:49 Claus Ibsen 
> > wrote:
> > > > >
> > > > > > On Mon, Jan 17, 2022 at 3:17 PM Marat Gubaidullin
> > > > > >  wrote:
> > > > > > >
> > > > > > > Hello Claus,
> > > > > > >
> > > > > > > 1. There is a typo (gzipDeflator instead of gzipDeflater) in the
> > data
> > > > > > > format name
> > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/camel/blob/4829e4b7c9fec2ea785411a1ccad65339e080520/core/camel-core-model/src/main/java/org/apache/camel/model/dataformat/DataFormatsDefinition.java#L57
> > > > > > >
> > > > > > > 2. I have fetched, built and still have data format names (and
> > > > almost all
> > > > > > > other properties) in kabab case in camel-yaml-dsl.json
> > > > > > >
> > > > > >
> > > > > > One problem with having both camelCase and kebab-case in the
> > > > > > camel-yaml-dsl.json is that you would have double properties for
> > > > > > everything.
> > > > > > Then in the tooling you would need to filter out the duplicated
> > kebab
> > > > > > based properties.
> > > > > >
> > > > > > Or we switch over to camelCase only. For the existing kamelets
> > then we
> > > > > > need to update those, but they are almost all in camelCase anyway.
> > > > > > There is a few EIPs like set-header and set-property they are
> > using,
> > > > > > which should be setHeader and setProperty.
> > > > > > So the migration is easy.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > On Mon, Jan 17, 2022 at 2:51 AM Claus Ibsen <
> > claus.ib...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > Just a heads up that I have squashed and merged this to the
> > main
> > > > > > branch.
> > > > > > > >
> > > > > > > > On Sun, Jan 16, 2022 at 3:12 PM Claus Ibsen <
> > claus.ib...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi
> > > > > > > > >
> > > > > > > > > Ticket: https://issues.apache.org/jira/browse/CAMEL-17499
> > > > > > > > >
> > > > > > > > > The data formats have over the time become inconsistent in
> > the
> > > > model
> > > > > > > > > and their names and also name vs camel-xxx JAR name etc.
> > > > > > > > >
> > > > > > > > > So after the 3.14 LTS release and where we drop JDK8 then we
> > are
> > > > > > doing
> > > > > > > > > some house cleaning.
> > > > > > > > > We also have some components to be marked as deprecated and
> > to be
> > > > > > > > removed later.
> > > > > > > > >
> > > > > > > > > The data format renaming is a more complex "thing" as we
> > have a
> > > > bunch
> > > > > > > > > of source code generated files based on those names.
> > > > > > > > >
> > > > > > > > > So a rename of eg zipfile to zipFile (to use camel case) that
> > > > causes
> > > > > > > > > the generated files to keep the existing file name because
> > the
> > > > lower
> > > > > > > > > case name existed. So to "fix" this a commit is needed to
> > delete
> > > > the
> > > > > > > > > first, and then another to regenerate the files.
> > > > > > > > 

Re: [HEADS UP] - Renaming inconsistent data format names in model

[Marat Gubaidullin]

camel-yaml-dsl.json and camelYamlDsl.json

On Tue., Jan. 18, 2022, 09:05 Claus Ibsen  wrote:

> On Tue, Jan 18, 2022 at 2:39 PM Luca Burgazzoli 
> wrote:
> >
> > On Tue, Jan 18, 2022 at 2:31 PM Claus Ibsen 
> wrote:
> >
> > > On Tue, Jan 18, 2022 at 12:39 AM Marat Gubaidullin
> > >  wrote:
> > > >
> > > > 1. I could omit kebab cased properties in generator while we have
> both.
> > > > 2. When read YAML Karavan "camelize" properties and DSL. Internal
> Karavan
> > > > Camel Definitions are in camel case. So output YAML is also camel
> case.
> > > >
> > >
> > > Yeah we can do that and for Camel 3.15 have both camelCase and
> > > kebab-case in the yaml-dsl.
> > > Where kebab-case is deprecated.
> > >
> >
> > I'm not very sure we can support both kebab anc camel case in
> > camel-yaml-dsl.json, (as
> > example,. there may be an issue with required properties) however we may
> > think to just
> > deprecate the kebab case in the json schema but we can keep support in
> the
> > yaml loader.
> >
>
> Ah so could we just generate two schema files, one with kebab-case and
> another with camelCase.
> Then Marat can use the camelCase for the Karavan tool.
>
> The current yaml-dsl is all kebab-case based, in the generated model
> serializers.
>
> The parser is conforming to kebab-case, eg such as (so we support both
> cases in the parser/loader)
>
> final String propertyName =
> StringHelper.camelCaseToDash(key.getValue()).toLowerCase(Locale.US);
>
>
>
>
> >
> > > This gives us that "wriggle room" to let kamelets, camel-k and others
> > > migrate to camelCase.
> > > Then in Camel 3.16 og 3.17 we can drop kebab and when we are fully
> > > migrated.
> > >
> > >
> > >
> > > > On Mon., Jan. 17, 2022, 09:49 Claus Ibsen 
> wrote:
> > > >
> > > > > On Mon, Jan 17, 2022 at 3:17 PM Marat Gubaidullin
> > > > >  wrote:
> > > > > >
> > > > > > Hello Claus,
> > > > > >
> > > > > > 1. There is a typo (gzipDeflator instead of gzipDeflater) in the
> data
> > > > > > format name
> > > > > >
> > > > >
> > >
> https://github.com/apache/camel/blob/4829e4b7c9fec2ea785411a1ccad65339e080520/core/camel-core-model/src/main/java/org/apache/camel/model/dataformat/DataFormatsDefinition.java#L57
> > > > > >
> > > > > > 2. I have fetched, built and still have data format names (and
> > > almost all
> > > > > > other properties) in kabab case in camel-yaml-dsl.json
> > > > > >
> > > > >
> > > > > One problem with having both camelCase and kebab-case in the
> > > > > camel-yaml-dsl.json is that you would have double properties for
> > > > > everything.
> > > > > Then in the tooling you would need to filter out the duplicated
> kebab
> > > > > based properties.
> > > > >
> > > > > Or we switch over to camelCase only. For the existing kamelets
> then we
> > > > > need to update those, but they are almost all in camelCase anyway.
> > > > > There is a few EIPs like set-header and set-property they are
> using,
> > > > > which should be setHeader and setProperty.
> > > > > So the migration is easy.
> > > > >
> > > > >
> > > > > >
> > > > > > On Mon, Jan 17, 2022 at 2:51 AM Claus Ibsen <
> claus.ib...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > Just a heads up that I have squashed and merged this to the
> main
> > > > > branch.
> > > > > > >
> > > > > > > On Sun, Jan 16, 2022 at 3:12 PM Claus Ibsen <
> claus.ib...@gmail.com
> > > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > Ticket: https://issues.apache.org/jira/browse/CAMEL-17499
> > > > > > > >
> > > > > > > > The data formats have over the time become inconsistent in
> the
> > > model
> > > > > > > > and their names and also name vs camel-xxx JAR name etc.
> > > > > > > >
> > > > > > > > So after the 3.14 LTS release and where we drop JDK8 then we
> are
> > > > > doing
> > > > > > > > some house cleaning.
> > > > > > > > We also have some components to be marked as deprecated and
> to be
> > > > > > > removed later.
> > > > > > > >
> > > > > > > > The data format renaming is a more complex "thing" as we
> have a
> > > bunch
> > > > > > > > of source code generated files based on those names.
> > > > > > > >
> > > > > > > > So a rename of eg zipfile to zipFile (to use camel case) that
> > > causes
> > > > > > > > the generated files to keep the existing file name because
> the
> > > lower
> > > > > > > > case name existed. So to "fix" this a commit is needed to
> delete
> > > the
> > > > > > > > first, and then another to regenerate the files.
> > > > > > > >
> > > > > > > > So for all of this work I did this today on a quiet day but
> > > there is
> > > > > > > > about 50 commits in total as there are many regens in this
> line
> > > of
> > > > > > > > spirit to make it all work.
> > > > > > > >
> > > > > > > > I am not sure if a git quash would work?
> > > > > > > >
> > > > > > > > I pushed the code to a branch
> > > > > > > > https://github.com/apache/camel/tree/dataformat-rename
> > > > > > > >
> > > > > > > > And a 

[RESULT] Apache Camel-kafka-connector 1.0.0

[Andrea]

Hi all,

This vote passes with the following result

3 +1 binding votes (Andrea Cosentino,  Zoran Regvart, Claus Ibsen)
2 +1 non-binding (Andrea Tarocchi, Otavio Rodolfo Piskei)

Thanks to everybody.

I'll publish the artifacts in a bit.

Regards,
Andrea.

Re: comments on c-k-c docs state && RI preview

[Andrea]

On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
> 
> 
> > On Jan 17, 2022, at 1:50 PM, Andrea  wrote:
> > 
> > 
> > 
> > On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
> >> 
> >> 
> >> > On Jan 17, 2022, at 3:23 AM, Andrea  >> > > wrote:
> >> > 
> >> > 
> >> > 
> >> > On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> >> >> Thanks, inline...
> >> >> 
> >> >>> On Jan 16, 2022, at 1:04 AM, Andrea  >> >>> > wrote:
> >> >>> 
> >> >>> Hello,
> >> >>> 
> >> >>> comments inline:
> >> >>> 
> >> >>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> >>  I noticed a few things working on the RI info for 
> >>  camel-kafka-connector.
> >>  
> >>  - the compatibility matrices are thoroughly out of date, e.g. 
> >>  https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> >>   
> >>  
> >>   
> >>   >>   
> >>  >
> >  
> > Awesome, basically a collection of the content of all these notes
> > 
> > could be the generated compatibility matrix page?  Or is there already a 
> > way where that content is sown other that for the last release?
> 
> Here’s a basic generated table for the compatibility matrix: 
> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
> 
> Note:
> - it will only ever have one line per branch: there’s no way to have separate 
> lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only one doc 
> version that covers all of these.

well in case it is needed we can always do a version from a tag
> - It only has currently documented versions listed. This makes it 
> self-maintaining: adding anything else will require periodic manual updates, 
> which will gradually decay into wrong or outdated information.
> 
> Are these acceptable limitations? 

fine for me
> 
> - This version of the table isn’t quite finished: for instance the “branch” 
> for next is wrong.  If we like this generated table in principle, I can fix 
> that and turn most entries into links. 

can you also add the version of the kamelet catalog?
> 
> However, I’m not entirely sure that having this information 
> duplicated/aggregated from the index pages is useful. I think we should just 
> delete the compatibility matrix page.  WDYT? 

as long as the table is somewhere I don't particularly care; it is fine to put 
it in the index page and remove the compatibility matrix page
> 
> On the other hand, if this table is popular, maybe we should have one for 
> each  subproject.
> 
> David Jencks
> 
> > 
> > 
> >> >>> Yep the compatibility matrix page needs some love... a column 
> >> >>> mentioning kamelet catalog version needs to be added and probably we 
> >> >>> can remove some old rows?
> >> >>> willing to help on this on too? :)
> >> >> 
> >> >> I think the entire existing matrix is out of date and should be 
> >> >> removed?  Or are there usable versions of c-k-c that aren’t documented?
> >> >> 
> >> >> I wonder if the RI information is sufficient, WDYT?
> >> > 
> >> > Where can I see a preview of the site with the IR information?
> >> 
> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html 
> >>  
> >>  >> >
> >>  shows all three branches (including not-quite-released 1.0).
> >> 
> >> >> 
> >> >> If you’re sure we need the matrix, let me know where it should start 
> >> >> and I’ll make some PRs.  I’d suggest having only one copy, perhaps in 
> >> >> next, and referring to it from the other branches.
> >> >>> 
> >>  
> >>  - All other camel subprojects use e.g. 2.5.x as the Antora component 
> >>  version, but c-k-c is using 0.11.0.  Especially since it’s LTS I 
> >>  think we should change it to 0.11.x so when 0.11.1 comes out the 
> >>  version still makes sense, as well as being consistent with the rest 
> >>  of the site.  I’m setting the 1.0.x branch up to say 1.0.x as the 
> >>  Antora version. 
> >> >>> +1 I agree
> >> >>> 
> >> >> 
> >> >> I’ve changed to 0.11.x in my RI PR.
> >> >> 
> >>  
> >>  - archetype-dataformat-connector has camel-version 3.6.0, rather out 
> >>  of date.
> >> >>> What do you mean here?
> >> >> 
> >> >> I should have looked harder and explained better.  The example output 
> >> >> shown in archetype-dataformat-connector.adoc shows using camel 3.6.0.  
> >> >> This page should probably be updated, and I wonder if it is even 

Re: [HEADS UP] - Renaming inconsistent data format names in model

[Claus Ibsen]

On Tue, Jan 18, 2022 at 2:39 PM Luca Burgazzoli  wrote:
>
> On Tue, Jan 18, 2022 at 2:31 PM Claus Ibsen  wrote:
>
> > On Tue, Jan 18, 2022 at 12:39 AM Marat Gubaidullin
> >  wrote:
> > >
> > > 1. I could omit kebab cased properties in generator while we have both.
> > > 2. When read YAML Karavan "camelize" properties and DSL. Internal Karavan
> > > Camel Definitions are in camel case. So output YAML is also camel case.
> > >
> >
> > Yeah we can do that and for Camel 3.15 have both camelCase and
> > kebab-case in the yaml-dsl.
> > Where kebab-case is deprecated.
> >
>
> I'm not very sure we can support both kebab anc camel case in
> camel-yaml-dsl.json, (as
> example,. there may be an issue with required properties) however we may
> think to just
> deprecate the kebab case in the json schema but we can keep support in the
> yaml loader.
>

Ah so could we just generate two schema files, one with kebab-case and
another with camelCase.
Then Marat can use the camelCase for the Karavan tool.

The current yaml-dsl is all kebab-case based, in the generated model
serializers.

The parser is conforming to kebab-case, eg such as (so we support both
cases in the parser/loader)

final String propertyName =
StringHelper.camelCaseToDash(key.getValue()).toLowerCase(Locale.US);




>
> > This gives us that "wriggle room" to let kamelets, camel-k and others
> > migrate to camelCase.
> > Then in Camel 3.16 og 3.17 we can drop kebab and when we are fully
> > migrated.
> >
> >
> >
> > > On Mon., Jan. 17, 2022, 09:49 Claus Ibsen  wrote:
> > >
> > > > On Mon, Jan 17, 2022 at 3:17 PM Marat Gubaidullin
> > > >  wrote:
> > > > >
> > > > > Hello Claus,
> > > > >
> > > > > 1. There is a typo (gzipDeflator instead of gzipDeflater) in the data
> > > > > format name
> > > > >
> > > >
> > https://github.com/apache/camel/blob/4829e4b7c9fec2ea785411a1ccad65339e080520/core/camel-core-model/src/main/java/org/apache/camel/model/dataformat/DataFormatsDefinition.java#L57
> > > > >
> > > > > 2. I have fetched, built and still have data format names (and
> > almost all
> > > > > other properties) in kabab case in camel-yaml-dsl.json
> > > > >
> > > >
> > > > One problem with having both camelCase and kebab-case in the
> > > > camel-yaml-dsl.json is that you would have double properties for
> > > > everything.
> > > > Then in the tooling you would need to filter out the duplicated kebab
> > > > based properties.
> > > >
> > > > Or we switch over to camelCase only. For the existing kamelets then we
> > > > need to update those, but they are almost all in camelCase anyway.
> > > > There is a few EIPs like set-header and set-property they are using,
> > > > which should be setHeader and setProperty.
> > > > So the migration is easy.
> > > >
> > > >
> > > > >
> > > > > On Mon, Jan 17, 2022 at 2:51 AM Claus Ibsen 
> > > > wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > Just a heads up that I have squashed and merged this to the main
> > > > branch.
> > > > > >
> > > > > > On Sun, Jan 16, 2022 at 3:12 PM Claus Ibsen  > >
> > > > wrote:
> > > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > Ticket: https://issues.apache.org/jira/browse/CAMEL-17499
> > > > > > >
> > > > > > > The data formats have over the time become inconsistent in the
> > model
> > > > > > > and their names and also name vs camel-xxx JAR name etc.
> > > > > > >
> > > > > > > So after the 3.14 LTS release and where we drop JDK8 then we are
> > > > doing
> > > > > > > some house cleaning.
> > > > > > > We also have some components to be marked as deprecated and to be
> > > > > > removed later.
> > > > > > >
> > > > > > > The data format renaming is a more complex "thing" as we have a
> > bunch
> > > > > > > of source code generated files based on those names.
> > > > > > >
> > > > > > > So a rename of eg zipfile to zipFile (to use camel case) that
> > causes
> > > > > > > the generated files to keep the existing file name because the
> > lower
> > > > > > > case name existed. So to "fix" this a commit is needed to delete
> > the
> > > > > > > first, and then another to regenerate the files.
> > > > > > >
> > > > > > > So for all of this work I did this today on a quiet day but
> > there is
> > > > > > > about 50 commits in total as there are many regens in this line
> > of
> > > > > > > spirit to make it all work.
> > > > > > >
> > > > > > > I am not sure if a git quash would work?
> > > > > > >
> > > > > > > I pushed the code to a branch
> > > > > > > https://github.com/apache/camel/tree/dataformat-rename
> > > > > > >
> > > > > > > And a bit PR (we can try to squash this one)
> > > > > > > https://github.com/apache/camel/pull/6760
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Claus Ibsen
> > > > > > > -
> > > > > > > http://davsclaus.com @davsclaus
> > > > > > > Camel in Action 2: https://www.manning.com/ibsen2
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Claus Ibsen
> > > > > > -
> > > > > > 

Re: [HEADS UP] - Renaming inconsistent data format names in model

[Luca Burgazzoli]

On Tue, Jan 18, 2022 at 2:31 PM Claus Ibsen  wrote:

> On Tue, Jan 18, 2022 at 12:39 AM Marat Gubaidullin
>  wrote:
> >
> > 1. I could omit kebab cased properties in generator while we have both.
> > 2. When read YAML Karavan "camelize" properties and DSL. Internal Karavan
> > Camel Definitions are in camel case. So output YAML is also camel case.
> >
>
> Yeah we can do that and for Camel 3.15 have both camelCase and
> kebab-case in the yaml-dsl.
> Where kebab-case is deprecated.
>

I'm not very sure we can support both kebab anc camel case in
camel-yaml-dsl.json, (as
example,. there may be an issue with required properties) however we may
think to just
deprecate the kebab case in the json schema but we can keep support in the
yaml loader.


> This gives us that "wriggle room" to let kamelets, camel-k and others
> migrate to camelCase.
> Then in Camel 3.16 og 3.17 we can drop kebab and when we are fully
> migrated.
>
>
>
> > On Mon., Jan. 17, 2022, 09:49 Claus Ibsen  wrote:
> >
> > > On Mon, Jan 17, 2022 at 3:17 PM Marat Gubaidullin
> > >  wrote:
> > > >
> > > > Hello Claus,
> > > >
> > > > 1. There is a typo (gzipDeflator instead of gzipDeflater) in the data
> > > > format name
> > > >
> > >
> https://github.com/apache/camel/blob/4829e4b7c9fec2ea785411a1ccad65339e080520/core/camel-core-model/src/main/java/org/apache/camel/model/dataformat/DataFormatsDefinition.java#L57
> > > >
> > > > 2. I have fetched, built and still have data format names (and
> almost all
> > > > other properties) in kabab case in camel-yaml-dsl.json
> > > >
> > >
> > > One problem with having both camelCase and kebab-case in the
> > > camel-yaml-dsl.json is that you would have double properties for
> > > everything.
> > > Then in the tooling you would need to filter out the duplicated kebab
> > > based properties.
> > >
> > > Or we switch over to camelCase only. For the existing kamelets then we
> > > need to update those, but they are almost all in camelCase anyway.
> > > There is a few EIPs like set-header and set-property they are using,
> > > which should be setHeader and setProperty.
> > > So the migration is easy.
> > >
> > >
> > > >
> > > > On Mon, Jan 17, 2022 at 2:51 AM Claus Ibsen 
> > > wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > Just a heads up that I have squashed and merged this to the main
> > > branch.
> > > > >
> > > > > On Sun, Jan 16, 2022 at 3:12 PM Claus Ibsen  >
> > > wrote:
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > Ticket: https://issues.apache.org/jira/browse/CAMEL-17499
> > > > > >
> > > > > > The data formats have over the time become inconsistent in the
> model
> > > > > > and their names and also name vs camel-xxx JAR name etc.
> > > > > >
> > > > > > So after the 3.14 LTS release and where we drop JDK8 then we are
> > > doing
> > > > > > some house cleaning.
> > > > > > We also have some components to be marked as deprecated and to be
> > > > > removed later.
> > > > > >
> > > > > > The data format renaming is a more complex "thing" as we have a
> bunch
> > > > > > of source code generated files based on those names.
> > > > > >
> > > > > > So a rename of eg zipfile to zipFile (to use camel case) that
> causes
> > > > > > the generated files to keep the existing file name because the
> lower
> > > > > > case name existed. So to "fix" this a commit is needed to delete
> the
> > > > > > first, and then another to regenerate the files.
> > > > > >
> > > > > > So for all of this work I did this today on a quiet day but
> there is
> > > > > > about 50 commits in total as there are many regens in this line
> of
> > > > > > spirit to make it all work.
> > > > > >
> > > > > > I am not sure if a git quash would work?
> > > > > >
> > > > > > I pushed the code to a branch
> > > > > > https://github.com/apache/camel/tree/dataformat-rename
> > > > > >
> > > > > > And a bit PR (we can try to squash this one)
> > > > > > https://github.com/apache/camel/pull/6760
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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
>

Re: [HEADS UP] - Renaming inconsistent data format names in model

[Claus Ibsen]

On Tue, Jan 18, 2022 at 12:39 AM Marat Gubaidullin
 wrote:
>
> 1. I could omit kebab cased properties in generator while we have both.
> 2. When read YAML Karavan "camelize" properties and DSL. Internal Karavan
> Camel Definitions are in camel case. So output YAML is also camel case.
>

Yeah we can do that and for Camel 3.15 have both camelCase and
kebab-case in the yaml-dsl.
Where kebab-case is deprecated.

This gives us that "wriggle room" to let kamelets, camel-k and others
migrate to camelCase.
Then in Camel 3.16 og 3.17 we can drop kebab and when we are fully migrated.



> On Mon., Jan. 17, 2022, 09:49 Claus Ibsen  wrote:
>
> > On Mon, Jan 17, 2022 at 3:17 PM Marat Gubaidullin
> >  wrote:
> > >
> > > Hello Claus,
> > >
> > > 1. There is a typo (gzipDeflator instead of gzipDeflater) in the data
> > > format name
> > >
> > https://github.com/apache/camel/blob/4829e4b7c9fec2ea785411a1ccad65339e080520/core/camel-core-model/src/main/java/org/apache/camel/model/dataformat/DataFormatsDefinition.java#L57
> > >
> > > 2. I have fetched, built and still have data format names (and almost all
> > > other properties) in kabab case in camel-yaml-dsl.json
> > >
> >
> > One problem with having both camelCase and kebab-case in the
> > camel-yaml-dsl.json is that you would have double properties for
> > everything.
> > Then in the tooling you would need to filter out the duplicated kebab
> > based properties.
> >
> > Or we switch over to camelCase only. For the existing kamelets then we
> > need to update those, but they are almost all in camelCase anyway.
> > There is a few EIPs like set-header and set-property they are using,
> > which should be setHeader and setProperty.
> > So the migration is easy.
> >
> >
> > >
> > > On Mon, Jan 17, 2022 at 2:51 AM Claus Ibsen 
> > wrote:
> > >
> > > > Hi
> > > >
> > > > Just a heads up that I have squashed and merged this to the main
> > branch.
> > > >
> > > > On Sun, Jan 16, 2022 at 3:12 PM Claus Ibsen 
> > wrote:
> > > > >
> > > > > Hi
> > > > >
> > > > > Ticket: https://issues.apache.org/jira/browse/CAMEL-17499
> > > > >
> > > > > The data formats have over the time become inconsistent in the model
> > > > > and their names and also name vs camel-xxx JAR name etc.
> > > > >
> > > > > So after the 3.14 LTS release and where we drop JDK8 then we are
> > doing
> > > > > some house cleaning.
> > > > > We also have some components to be marked as deprecated and to be
> > > > removed later.
> > > > >
> > > > > The data format renaming is a more complex "thing" as we have a bunch
> > > > > of source code generated files based on those names.
> > > > >
> > > > > So a rename of eg zipfile to zipFile (to use camel case) that causes
> > > > > the generated files to keep the existing file name because the lower
> > > > > case name existed. So to "fix" this a commit is needed to delete the
> > > > > first, and then another to regenerate the files.
> > > > >
> > > > > So for all of this work I did this today on a quiet day but there is
> > > > > about 50 commits in total as there are many regens in this line of
> > > > > spirit to make it all work.
> > > > >
> > > > > I am not sure if a git quash would work?
> > > > >
> > > > > I pushed the code to a branch
> > > > > https://github.com/apache/camel/tree/dataformat-rename
> > > > >
> > > > > And a bit PR (we can try to squash this one)
> > > > > https://github.com/apache/camel/pull/6760
> > > > >
> > > > >
> > > > > --
> > > > > 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