[jira] [Commented] (CAMEL-19012) Remove Camel v2 documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-19012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749141#comment-17749141
 ] 

ASF GitHub Bot commented on CAMEL-19012:


essobedo merged PR #1044:
URL: https://github.com/apache/camel-website/pull/1044




> Remove Camel v2 documentation
> -
>
> Key: CAMEL-19012
> URL: https://issues.apache.org/jira/browse/CAMEL-19012
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.0.0
>
>
> Camel 2 is EOL a long time, and when we release v4 then we should consider 
> dropping v2 docs, as the website is huge and harder to maintain across many 
> versions.
> v2 has been removed from download page



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-19012) Remove Camel v2 documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-19012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749138#comment-17749138
 ] 

ASF GitHub Bot commented on CAMEL-19012:


essobedo commented on PR #1044:
URL: https://github.com/apache/camel-website/pull/1044#issuecomment-1658117995

   The errors don't seem to be related:
   ```
   ➤ YN: [build:antora  ] [build:antora-perf] [10:30:05.025] ERROR 
(asciidoctor): target of xref not found: 4.0.x@camel-kamelets:ROOT:index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] file: 
docs/modules/ROOT/pages/index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] source: 
https://github.com/apache/camel-k.git (refname: main, start path: docs)
   ➤ YN: [build:antora  ] [build:antora-perf] [10:30:11.178] ERROR 
(asciidoctor): target of xref not found: 4.0.x@camel-kamelets:ROOT:index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] file: 
docs/modules/ROOT/pages/index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] source: 
https://github.com/apache/camel-k.git (refname: release-1.10.x, start path: 
docs)
   ➤ YN: [build:antora  ] [build:antora-perf] [10:30:16.482] ERROR 
(asciidoctor): target of xref not found: 4.0.x@camel-kamelets:ROOT:index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] file: 
docs/modules/ROOT/pages/index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] source: 
https://github.com/apache/camel-k.git (refname: release-1.11.x, start path: 
docs)
   ➤ YN: [build:antora  ] [build:antora-perf] [10:30:21.780] ERROR 
(asciidoctor): target of xref not found: 4.0.x@camel-kamelets:ROOT:index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] file: 
docs/modules/ROOT/pages/index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] source: 
https://github.com/apache/camel-k.git (refname: release-1.12.x, start path: 
docs)
   ➤ YN: [build:antora  ] [build:antora-perf] 
[10:30:[27](https://github.com/apache/camel-website/actions/runs/5713327304/job/15478528911#step:4:28).302]
 ERROR (asciidoctor): target of xref not found: 4.0.x@camel-kamelets::index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] file: 
docs/modules/ROOT/pages/index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] source: 
https://github.com/apache/camel-k.git (refname: release-2.0.x, start path: docs)
   ➤ YN: [build:antora  ] [build:antora-perf] [10:30:27.308] ERROR 
(asciidoctor): target of xref not found: 4.0.x@camel-kamelets:ROOT:index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] file: 
docs/modules/ROOT/pages/index.adoc
   ➤ YN: [build:antora  ] [build:antora-perf] source: 
https://github.com/apache/camel-k.git (refname: release-2.0.x, start path: docs)
   ```




> Remove Camel v2 documentation
> -
>
> Key: CAMEL-19012
> URL: https://issues.apache.org/jira/browse/CAMEL-19012
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Assignee: Nicolas Filotto
>Priority: Major
> Fix For: 4.0.0
>
>
> Camel 2 is EOL a long time, and when we release v4 then we should consider 
> dropping v2 docs, as the website is huge and harder to maintain across many 
> versions.
> v2 has been removed from download page



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-19012) Remove Camel v2 documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-19012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749122#comment-17749122
 ] 

ASF GitHub Bot commented on CAMEL-19012:


essobedo opened a new pull request, #1044:
URL: https://github.com/apache/camel-website/pull/1044

   Fixes https://issues.apache.org/jira/browse/CAMEL-19012
   
   ## Motivation
   
   Camel 2 is EOL a long time and should be removed to speed up a bit the 
website build
   
   ## Modifications:
   
   * Removes Camel v2 documentation




> Remove Camel v2 documentation
> -
>
> Key: CAMEL-19012
> URL: https://issues.apache.org/jira/browse/CAMEL-19012
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 4.0.0
>
>
> Camel 2 is EOL a long time, and when we release v4 then we should consider 
> dropping v2 docs, as the website is huge and harder to maintain across many 
> versions.
> v2 has been removed from download page



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-19011) update release notes to point users to use camel-bom / camel-spring-boot-bom

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-19011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684634#comment-17684634
 ] 

ASF GitHub Bot commented on CAMEL-19011:


davsclaus merged PR #975:
URL: https://github.com/apache/camel-website/pull/975




> update release notes to point users to use camel-bom / camel-spring-boot-bom
> 
>
> Key: CAMEL-19011
> URL: https://issues.apache.org/jira/browse/CAMEL-19011
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 4.0-M2, 4.0
>
>
> https://camel.apache.org/releases/release-4.0.0-M1/
> This one still refers to the old camel-spring-boot-dependencies but we should 
> prefer to cleaner and simpler camel-spring-boot-bom
> eg you import spring-boot-bom and then camel-spring-boot-bom afterwards
> https://github.com/apache/camel-spring-boot-examples/blob/main/spring-boot/pom.xml#L41



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-19011) update release notes to point users to use camel-bom / camel-spring-boot-bom

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-19011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684578#comment-17684578
 ] 

ASF GitHub Bot commented on CAMEL-19011:


github-actions[bot] commented on PR #975:
URL: https://github.com/apache/camel-website/pull/975#issuecomment-1418874899

    Preview is available at https://pr-975--camel.netlify.app




> update release notes to point users to use camel-bom / camel-spring-boot-bom
> 
>
> Key: CAMEL-19011
> URL: https://issues.apache.org/jira/browse/CAMEL-19011
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 4.0-M2, 4.0
>
>
> https://camel.apache.org/releases/release-4.0.0-M1/
> This one still refers to the old camel-spring-boot-dependencies but we should 
> prefer to cleaner and simpler camel-spring-boot-bom
> eg you import spring-boot-bom and then camel-spring-boot-bom afterwards
> https://github.com/apache/camel-spring-boot-examples/blob/main/spring-boot/pom.xml#L41



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-19011) update release notes to point users to use camel-bom / camel-spring-boot-bom

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-19011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684535#comment-17684535
 ] 

ASF GitHub Bot commented on CAMEL-19011:


github-actions[bot] commented on PR #975:
URL: https://github.com/apache/camel-website/pull/975#issuecomment-1418771608

    Preview is available at https://pr-975--camel.netlify.app




> update release notes to point users to use camel-bom / camel-spring-boot-bom
> 
>
> Key: CAMEL-19011
> URL: https://issues.apache.org/jira/browse/CAMEL-19011
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 4.0-M2, 4.0
>
>
> https://camel.apache.org/releases/release-4.0.0-M1/
> This one still refers to the old camel-spring-boot-dependencies but we should 
> prefer to cleaner and simpler camel-spring-boot-bom
> eg you import spring-boot-bom and then camel-spring-boot-bom afterwards
> https://github.com/apache/camel-spring-boot-examples/blob/main/spring-boot/pom.xml#L41



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-19011) update release notes to point users to use camel-bom / camel-spring-boot-bom

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-19011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684503#comment-17684503
 ] 

ASF GitHub Bot commented on CAMEL-19011:


davsclaus opened a new pull request, #975:
URL: https://github.com/apache/camel-website/pull/975

   …amel-spring-boot-bom




> update release notes to point users to use camel-bom / camel-spring-boot-bom
> 
>
> Key: CAMEL-19011
> URL: https://issues.apache.org/jira/browse/CAMEL-19011
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 4.0-M2
>
>
> https://camel.apache.org/releases/release-4.0.0-M1/
> This one still refers to the old camel-spring-boot-dependencies but we should 
> prefer to cleaner and simpler camel-spring-boot-bom
> eg you import spring-boot-bom and then camel-spring-boot-bom afterwards
> https://github.com/apache/camel-spring-boot-examples/blob/main/spring-boot/pom.xml#L41



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643493#comment-17643493
 ] 

ASF GitHub Bot commented on CAMEL-18786:


orpiske merged PR #929:
URL: https://github.com/apache/camel-website/pull/929




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643487#comment-17643487
 ] 

ASF GitHub Bot commented on CAMEL-18786:


github-actions[bot] commented on PR #929:
URL: https://github.com/apache/camel-website/pull/929#issuecomment-1337875148

    Preview is available at https://pr-929--camel.netlify.app




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642484#comment-17642484
 ] 

ASF GitHub Bot commented on CAMEL-18786:


orpiske commented on PR #929:
URL: https://github.com/apache/camel-website/pull/929#issuecomment-1335175926

   > @orpiske one more thing, the inline styles you have in 
`contents-table.html` the will not work on the production site, we explicitly 
disable inline CSS and JavaScript via 
[CSP](https://github.com/apache/camel-website/blob/034de87cf0f5ad866951f5d03af5e85d6c13d49a/static/.htaccess#L1384).
 To test the website in a production-like environment build with 
`CAMEL_ENV=production` and [run Apache HTTPD 
locally](https://github.com/apache/camel-website/blob/main/support/README.md#running-apache-http).
   
   Thanks. It's looking like I might need to move those to the website repo and 
reference them there somehow. I'll investigate this more closely. Thanks for 
pointing this.




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642482#comment-17642482
 ] 

ASF GitHub Bot commented on CAMEL-18786:


zregvart commented on PR #929:
URL: https://github.com/apache/camel-website/pull/929#issuecomment-1335172468

   @orpiske one more thing, the inline styles you have in `contents-table.html` 
the will not work on the production site, we explicitly disable inline CSS and 
JavaScript via 
[CSP](https://github.com/apache/camel-website/blob/034de87cf0f5ad866951f5d03af5e85d6c13d49a/static/.htaccess#L1384).
 To test the website in a production-like environment build with 
`CAMEL_ENV=production` and [run Apache HTTPD 
locally](https://github.com/apache/camel-website/blob/main/support/README.md#running-apache-http).




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642473#comment-17642473
 ] 

ASF GitHub Bot commented on CAMEL-18786:


orpiske commented on PR #929:
URL: https://github.com/apache/camel-website/pull/929#issuecomment-1335157872

   > There is a typo on this line:
   > 
   > 
https://github.com/apache/camel/blob/ea35b3ee5c554bb56f7434267661b4ede723df01/docs/main/modules/ROOT/attachments/contents-table.html#L60
   > 
   > ` 
   > If you want to run all the checks locally run with `CAMEL_ENV=production` 
[environment 
variable](https://github.com/apache/camel-website#camel_env-environment-variable).
   
   Awesome! Thanks for pointing the error and sharing the info about the 
checks. I'll make sure to include that into my workflow.
   
   > 
   > In general I don't think it is a good idea to have HTML outside of the 
website repository, things are prone to breaking that way. The layouts that 
generate the HTML need to be in the website directory.
   
   I agree that it would be better to avoid HTML. Unfortunately I couldn't get 
it to look precisely the way I wanted. 
   
   In the future I will refactor this to move that page to the website. So we 
avoid these anti-patterns and don't create problems for the future.
   
   




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642468#comment-17642468
 ] 

ASF GitHub Bot commented on CAMEL-18786:


zregvart commented on PR #929:
URL: https://github.com/apache/camel-website/pull/929#issuecomment-1335150365

   There is a typo on this line:
   
   
https://github.com/apache/camel/blob/ea35b3ee5c554bb56f7434267661b4ede723df01/docs/main/modules/ROOT/attachments/contents-table.html#L60
   
   `https://github.com/apache/camel-website#camel_env-environment-variable).
   
   In general I don't think it is a good idea to have HTML outside of the 
website repository, things are prone to breaking that way. The layouts that 
generate the HTML need to be in the website directory.




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642467#comment-17642467
 ] 

ASF GitHub Bot commented on CAMEL-18786:


orpiske commented on PR #929:
URL: https://github.com/apache/camel-website/pull/929#issuecomment-1335145420

   @zregvart @djencks hey guys, any idea what might be the problem here? The 
build is failing with:
   
   ```
   ➤ YN: [build:minify  ] [09:56:21] Error in plugin "gulp-htmlmin"
   ```
   
   I didn't get those errors locally, so I am not sure what might be the 
problem. 
   
   If you have any pointers, that would be helpful. Thanks!!!




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642077#comment-17642077
 ] 

ASF GitHub Bot commented on CAMEL-18786:


orpiske commented on PR #929:
URL: https://github.com/apache/camel-website/pull/929#issuecomment-1334135458

   The preview and more details are available on the linked PR. 




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642053#comment-17642053
 ] 

ASF GitHub Bot commented on CAMEL-18786:


orpiske commented on PR #929:
URL: https://github.com/apache/camel-website/pull/929#issuecomment-1334086914

   This depends on apache/camel#8821.




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-18786) documentation: reorganize Camel Core documentation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642051#comment-17642051
 ] 

ASF GitHub Bot commented on CAMEL-18786:


orpiske opened a new pull request, #929:
URL: https://github.com/apache/camel-website/pull/929

   These changes allow the Camel Core project to create a new page to
   reorganize, categorize and separate the project documentation according
   to the audience.
   
   The behavior of a few of the static pages is changed to accommodate
   that.




> documentation: reorganize Camel Core documentation
> --
>
> Key: CAMEL-18786
> URL: https://issues.apache.org/jira/browse/CAMEL-18786
> Project: Camel
>  Issue Type: Task
>  Components: documentation
>Reporter: Otavio Rodolfo Piske
>Assignee: Otavio Rodolfo Piske
>Priority: Major
>
> The community has complained for a long time that our documentation is hard 
> to follow, outdated and disorganized. 
> This task is to document the effort to clean it up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476742#comment-17476742
 ] 

ASF GitHub Bot commented on CAMEL-17154:


davsclaus merged pull request #757:
URL: https://github.com/apache/camel-website/pull/757


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476682#comment-17476682
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #757:
URL: https://github.com/apache/camel-website/pull/757#issuecomment-1013740032


   Whew, this build finally shows the graphic.  Ok, I'm done with this one now.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476681#comment-17476681
 ] 

ASF GitHub Bot commented on CAMEL-17154:


github-actions[bot] commented on pull request #757:
URL: https://github.com/apache/camel-website/pull/757#issuecomment-1013738613


    Preview is available at https://pr-757--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476664#comment-17476664
 ] 

ASF GitHub Bot commented on CAMEL-17154:


github-actions[bot] commented on pull request #757:
URL: https://github.com/apache/camel-website/pull/757#issuecomment-1013719077


    Preview is available at https://pr-757--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476650#comment-17476650
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #757:
URL: https://github.com/apache/camel-website/pull/757#issuecomment-1013704658


   Last time, the preview showed the link perfectly well, but the image was not 
working in the real deployment.  With this preview, the link is not showing.  
How is this so hard to do?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476648#comment-17476648
 ] 

ASF GitHub Bot commented on CAMEL-17154:


github-actions[bot] commented on pull request #757:
URL: https://github.com/apache/camel-website/pull/757#issuecomment-1013703483


    Preview is available at https://pr-757--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476623#comment-17476623
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 opened a new pull request #757:
URL: https://github.com/apache/camel-website/pull/757


   After looking at other blog posts, and how they embed images, I decided to 
link to the Dynamic Router EIP gif at 
components/eips/_images/eip/DynamicRouter.gif, as recommended by @djencks 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476544#comment-17476544
 ] 

ASF GitHub Bot commented on CAMEL-17154:


davsclaus merged pull request #756:
URL: https://github.com/apache/camel-website/pull/756


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476447#comment-17476447
 ] 

ASF GitHub Bot commented on CAMEL-17154:


github-actions[bot] commented on pull request #756:
URL: https://github.com/apache/camel-website/pull/756#issuecomment-1013500252


    Preview is available at https://pr-756--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476421#comment-17476421
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 opened a new pull request #756:
URL: https://github.com/apache/camel-website/pull/756


   I messed up the external image link syntax, and fixed it in this merge 
request.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian Jira

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476270#comment-17476270
 ] 

ASF GitHub Bot commented on CAMEL-17154:


zregvart merged pull request #753:
URL: https://github.com/apache/camel-website/pull/753


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476258#comment-17476258
 ] 

ASF GitHub Bot commented on CAMEL-17154:


github-actions[bot] commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013269805


    Preview is available at https://pr-753--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476252#comment-17476252
 ] 

ASF GitHub Bot commented on CAMEL-17154:


zregvart commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013263176


   GitHub workflow seems to have hanged at the very end. Checks look good now. 
Let's give it a bit and see if we need to retry to get a preview or we can 
merge and touch-up on after it gets published?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476094#comment-17476094
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013061486


   @zregvart let me fix the link that I missed.  One moment...


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by Atlassian 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476084#comment-17476084
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013049492


   > @Steve973 no worries, not much work at all. I'll create a separate PR for 
the changes in the POM though, I think that'll get the blog post merged faster. 
I am going to force-push to your branch so just be aware of that.
   
   Thank you, again, for your help.  I am a new contributor here, so I am 
trying to learn how your team does things.  If it comes to a point where you 
need me to fix whatever I did wrong, just let me know.  I am at work now, where 
my local time is just before 7am at the time of this comment, so I might not be 
able to do much for approximately another 7 - 8 hours.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476065#comment-17476065
 ] 

ASF GitHub Bot commented on CAMEL-17154:


zregvart commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013007658


   @Steve973 no worries, not much work at all. I'll create a separate PR for 
the changes in the POM though, I think that'll get the blog post merged faster. 
I am going to force-push to your branch so just be aware of that.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476064#comment-17476064
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 edited a comment on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013004793


   > @Steve973 there seems to be something wrong with the merge resolution and 
now we have changes in files that are not related to the blog post. I'll rebase 
this and hopefully that'll fix it. It will change your own branch, but 
hopefully for the last time before we merge.
   
   @zregvart That reminds me that I fixed the maven build, so those changes in 
the pom.xml are undoubtedly some unrelated changes.  I woke for work this 
morning, saw that I had left "draft:true" in the blog post, so I wanted to make 
that quick change and re-commit.  In the future, I will switch branches when I 
do any experimenting.  I apologize for creating more work for you, although I 
appreciate it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476062#comment-17476062
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013004793


   > @Steve973 there seems to be something wrong with the merge resolution and 
now we have changes in files that are not related to the blog post. I'll rebase 
this and hopefully that'll fix it. It will change your own branch, but 
hopefully for the last time before we merge.
   
   @zregvart That reminds me that I fixed the maven build, so those changes in 
the pom.xml are undoubtedly some unrelated changes.  I woke for work this 
morning, saw that I had left "draft:true" in the blog post, so I wanted to make 
that quick change and re-commit.  In the future, I will switch branches when I 
do any experimenting.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476059#comment-17476059
 ] 

ASF GitHub Bot commented on CAMEL-17154:


zregvart commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1013002063


   @Steve973 there seems to be something wrong with the merge resolution and 
now we have changes in files that are not related to the blog post. I'll rebase 
this and hopefully that'll fix it. It will change your own branch, but 
hopefully for the last time before we merge.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476041#comment-17476041
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1012937775


   Oh, I do remember that I was supposed to remove the draft line, now that
   you mention it. Thank you!
   
   On Fri, Jan 14, 2022, 12:52 AM djencks ***@***.***> wrote:
   
   > I built it locally and don't see any problems from the time in the date,
   > but the draft:true appears to prevent it being published.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you authored the thread.Message ID:
   > ***@***.***>
   >
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475957#comment-17475957
 ] 

ASF GitHub Bot commented on CAMEL-17154:


djencks commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1012796275


   I built it locally and don't see any problems from the time in the date, but 
the `draft:true` appears to prevent it being published.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475936#comment-17475936
 ] 

ASF GitHub Bot commented on CAMEL-17154:


davsclaus edited a comment on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1012778712


   You need to adjust the date, look at. the others they dont have time in the 
date, also make sure it is updated to today, eg 2022-01-14, otherwise you 
cannot see the blog entry in the preview


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475934#comment-17475934
 ] 

ASF GitHub Bot commented on CAMEL-17154:


davsclaus commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1012778712


   You need to adjust the date, look at. the others they dont have time in the 
date, also make sure it is updated to today, eg 2022-01-14


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475870#comment-17475870
 ] 

ASF GitHub Bot commented on CAMEL-17154:


github-actions[bot] commented on pull request #753:
URL: https://github.com/apache/camel-website/pull/753#issuecomment-1012636413


    Preview is available at https://pr-753--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * The rules will exist while a participant is subscribed, and only fur the 
> duration of runtime – each time the Camel Context starts up, participants 
> will have to register.



--
This message was sent by 

[jira] [Commented] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475691#comment-17475691
 ] 

ASF GitHub Bot commented on CAMEL-17154:


Steve973 opened a new pull request #753:
URL: https://github.com/apache/camel-website/pull/753


   I added the blog post, but I could not build the website due to many errors, 
even after installing node and yarn.  I modified links to match those of other 
blog entries, but I am not using xrefs.  Please have a look, or help me to 
build this myself, because I do not want to further break the build.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create alternate dynamic router implementation that allows registration
> ---
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, eip
>Affects Versions: Future
>Reporter: Steve Storck
>Assignee: Steve Storck
>Priority: Minor
>  Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.md
>
>
> Since the current Dynamic Router processor is missing the implementation of 
> some key concepts (including a control channel, and recipient registration), 
> I need an alternate implementation of Dynamic Router that more closely 
> implements the Dynamic Router enterprise integration pattern so that I can 
> use this implementation in the cases where the original Dynamic Router would 
> be less appropriate.
> If we look at the EIP at 
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see 
> that the key concepts are:
>  * Control Channel: A Dynamic Router implementation should provide a control 
> channel, by which potential recipients can provide their rules that indicate 
> if they can process a message.  The current implementation does not seem to 
> have any notion of a control channel.  It appears that the current 
> implementation interprets the Control Channel as a way for messages to be 
> continuously re-circulated back through the Dynamic Router.
>  * Recipient Registration: A Dynamic Router implementation should accept 
> special registration messages via the Control Channel, at run-time, to allow 
> a potential recipient to announce its presence and to provide the conditions 
> under which it can handle a message.  While nothing precludes the user of the 
> Dynamic Router from implementing this, themselves, there is nothing in the 
> current implementation to provide this.
>  * Dynamic Rule Base: The Dynamic Router stores the registration information 
> for each participant in a rule base that is not fixed, or static.  This is 
> the same as the previous point: any rule base is created as a decision tree 
> at compile time, or the user must create their own Dynamic Rule Base 
> mechanism.
>  * Real-time Rules Evaluation and Routing: When a message arrives, the 
> Dynamic Router evaluates all rules that are currently in the Dynamic Rule 
> Base, and then routes the message to the recipient whose rules are fulfilled. 
>  Because of the two previous points, this is left up to the user to implement.
>  * No Dynamic Router Dependency on Recipients: Recipients do not need to care 
> about the Dynamic Router, and they do not need to care about evaluating 
> rules.  If they are able to process the message, the message will be sent to 
> the recipient.
> I propose to create a "Dynamic Router EIP component" with the key features 
> that it is missing, and to allow control over more of its operation:
>  * Add a Control Channel on which recipients will provide their registration 
> information, or on which they will unregister.
>  * Add a Dynamic Rule Base where the recipients' registration information 
> will be maintained.
>  * Since the EIP description does not mention any re-circulation behavior, it 
> will not provide that feature.  Users can route a response back to the 
> dynamic router if they need to.
>  * The first recipient with rules that all match the exchange will be 
> selected, and the exchange will be routed to its destination URI.
>  * The registration message will include a recipient ID, a simple or complex 
> Camel Predicate that evaluates to true or false, and the recipient's 
> Endpoint, where messages that pass its rules evaluation will be sent.
>  * Recipients will be able to unsubscribe at any time.  Likewise, they can 
> also subscribe at any time.
>  * 

[jira] [Commented] (CAMEL-17404) [Docs][camel-karaf]Generate components table with Antora

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467766#comment-17467766
 ] 

ASF GitHub Bot commented on CAMEL-17404:


djencks commented on pull request #745:
URL: https://github.com/apache/camel-website/pull/745#issuecomment-1003849023


   Preview looks good, PRs merged, closing


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Docs][camel-karaf]Generate components table with Antora
> 
>
> Key: CAMEL-17404
> URL: https://issues.apache.org/jira/browse/CAMEL-17404
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-karaf
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> I propose removing the java code generating the tables on the components page 
> and replacing it with Antora generation.  This involves:
> - generating the .json files for components into the catalog src directory, 
> and committing them. Generation is fairly easy, but at the moment committing 
> is a manual process.  On main, changes should end up in the auto-generated 
> PR, but on other branches no such mechanism is in place, resulting in at 
> least two branches having uncommitted changes after builds (before my 
> changes).
> - removing the mojo to generate the table contents
> - adding a little javascript to help with the table entries
> - using the indexer extension to generate the tables from the .json files.
> In my PRs, I've changed the tables a little bit:
> - the feature name is in it's own column, named "feature" rather than being 
> in parentheses after the extension name (I had no idea what it meant)
> - the syntax string is removed.  I can't see how it can be useful in the 
> table, but it if is it's easy enough to add.  I would expect that much more 
> information about the extension would be needed to use it in karaf, just like 
> in Spring.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17404) [Docs][camel-karaf]Generate components table with Antora

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467765#comment-17467765
 ] 

ASF GitHub Bot commented on CAMEL-17404:


djencks closed pull request #745:
URL: https://github.com/apache/camel-website/pull/745


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Docs][camel-karaf]Generate components table with Antora
> 
>
> Key: CAMEL-17404
> URL: https://issues.apache.org/jira/browse/CAMEL-17404
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-karaf
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> I propose removing the java code generating the tables on the components page 
> and replacing it with Antora generation.  This involves:
> - generating the .json files for components into the catalog src directory, 
> and committing them. Generation is fairly easy, but at the moment committing 
> is a manual process.  On main, changes should end up in the auto-generated 
> PR, but on other branches no such mechanism is in place, resulting in at 
> least two branches having uncommitted changes after builds (before my 
> changes).
> - removing the mojo to generate the table contents
> - adding a little javascript to help with the table entries
> - using the indexer extension to generate the tables from the .json files.
> In my PRs, I've changed the tables a little bit:
> - the feature name is in it's own column, named "feature" rather than being 
> in parentheses after the extension name (I had no idea what it meant)
> - the syntax string is removed.  I can't see how it can be useful in the 
> table, but it if is it's easy enough to add.  I would expect that much more 
> information about the extension would be needed to use it in karaf, just like 
> in Spring.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17404) [Docs][camel-karaf]Generate components table with Antora

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467755#comment-17467755
 ] 

ASF GitHub Bot commented on CAMEL-17404:


github-actions[bot] commented on pull request #745:
URL: https://github.com/apache/camel-website/pull/745#issuecomment-1003840847


    Preview is available at https://pr-745--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Docs][camel-karaf]Generate components table with Antora
> 
>
> Key: CAMEL-17404
> URL: https://issues.apache.org/jira/browse/CAMEL-17404
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-karaf
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> I propose removing the java code generating the tables on the components page 
> and replacing it with Antora generation.  This involves:
> - generating the .json files for components into the catalog src directory, 
> and committing them. Generation is fairly easy, but at the moment committing 
> is a manual process.  On main, changes should end up in the auto-generated 
> PR, but on other branches no such mechanism is in place, resulting in at 
> least two branches having uncommitted changes after builds (before my 
> changes).
> - removing the mojo to generate the table contents
> - adding a little javascript to help with the table entries
> - using the indexer extension to generate the tables from the .json files.
> In my PRs, I've changed the tables a little bit:
> - the feature name is in it's own column, named "feature" rather than being 
> in parentheses after the extension name (I had no idea what it meant)
> - the syntax string is removed.  I can't see how it can be useful in the 
> table, but it if is it's easy enough to add.  I would expect that much more 
> information about the extension would be needed to use it in karaf, just like 
> in Spring.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17404) [Docs][camel-karaf]Generate components table with Antora

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467561#comment-17467561
 ] 

ASF GitHub Bot commented on CAMEL-17404:


djencks opened a new pull request #745:
URL: https://github.com/apache/camel-website/pull/745


   Preview of changes for 
https://issues.apache.org/jira/projects/CAMEL/issues/CAMEL-17404


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Docs][camel-karaf]Generate components table with Antora
> 
>
> Key: CAMEL-17404
> URL: https://issues.apache.org/jira/browse/CAMEL-17404
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-karaf
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> I propose removing the java code generating the tables on the components page 
> and replacing it with Antora generation.  This involves:
> - generating the .json files for components into the catalog src directory, 
> and committing them. Generation is fairly easy, but at the moment committing 
> is a manual process.  On main, changes should end up in the auto-generated 
> PR, but on other branches no such mechanism is in place, resulting in at 
> least two branches having uncommitted changes after builds (before my 
> changes).
> - removing the mojo to generate the table contents
> - adding a little javascript to help with the table entries
> - using the indexer extension to generate the tables from the .json files.
> In my PRs, I've changed the tables a little bit:
> - the feature name is in it's own column, named "feature" rather than being 
> in parentheses after the extension name (I had no idea what it meant)
> - the syntax string is removed.  I can't see how it can be useful in the 
> table, but it if is it's easy enough to add.  I would expect that much more 
> information about the extension would be needed to use it in karaf, just like 
> in Spring.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-13704) Add github pull request template for PR instruction

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-13704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433222#comment-17433222
 ] 

ASF GitHub Bot commented on CAMEL-13704:


zregvart merged pull request #650:
URL: https://github.com/apache/camel-website/pull/650


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add github pull request template for PR instruction
> ---
>
> Key: CAMEL-13704
> URL: https://issues.apache.org/jira/browse/CAMEL-13704
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Willem Jiang
>Priority: Major
>  Labels: help-wanted
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> It's standard procedure to accept the big contribution with iCLA granted in 
> ASF.
> We should list this information when the contributor send the PR by 
> specifying a PR template for github.  It could be annoying for the 
> experienced contributors, but it could save us some time for the new 
> contributors. 
> Here is a draft I have, please add comment for it.
> {code}
>  - [ ] Make sure there is a [JIRA 
> issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change 
> (usually before you start working on it).  Trivial changes like typos do not 
> require a JIRA issue.  Your pull request should address just this issue, 
> without pulling in other changes.
>  - [ ] Each commit in the pull request should have a meaningful subject line 
> and body.
>  - [ ] Format the pull request title like `[CAMEL-XXX] Fixes bug in 
> camel-file component`, where you replace `CAMEL-XXX` with the appropriate 
> JIRA issue.
>  - [ ] Write a pull request description that is detailed enough to understand 
> what the pull request does, how, and why.
>  - [ ] Run `mvn clean install` in your module to make sure basic checks pass. 
> A more thorough check will be performed on your pull request automatically.
>  - [ ] If this contribution is large, please file an Apache [Individual 
> Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-13704) Add github pull request template for PR instruction

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-13704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433221#comment-17433221
 ] 

ASF GitHub Bot commented on CAMEL-13704:


zregvart commented on pull request #650:
URL: https://github.com/apache/camel-website/pull/650#issuecomment-950092417


   Thank you


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add github pull request template for PR instruction
> ---
>
> Key: CAMEL-13704
> URL: https://issues.apache.org/jira/browse/CAMEL-13704
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Willem Jiang
>Priority: Major
>  Labels: help-wanted
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> It's standard procedure to accept the big contribution with iCLA granted in 
> ASF.
> We should list this information when the contributor send the PR by 
> specifying a PR template for github.  It could be annoying for the 
> experienced contributors, but it could save us some time for the new 
> contributors. 
> Here is a draft I have, please add comment for it.
> {code}
>  - [ ] Make sure there is a [JIRA 
> issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change 
> (usually before you start working on it).  Trivial changes like typos do not 
> require a JIRA issue.  Your pull request should address just this issue, 
> without pulling in other changes.
>  - [ ] Each commit in the pull request should have a meaningful subject line 
> and body.
>  - [ ] Format the pull request title like `[CAMEL-XXX] Fixes bug in 
> camel-file component`, where you replace `CAMEL-XXX` with the appropriate 
> JIRA issue.
>  - [ ] Write a pull request description that is detailed enough to understand 
> what the pull request does, how, and why.
>  - [ ] Run `mvn clean install` in your module to make sure basic checks pass. 
> A more thorough check will be performed on your pull request automatically.
>  - [ ] If this contribution is large, please file an Apache [Individual 
> Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-13704) Add github pull request template for PR instruction

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-13704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433219#comment-17433219
 ] 

ASF GitHub Bot commented on CAMEL-13704:


manaswinidas opened a new pull request #650:
URL: https://github.com/apache/camel-website/pull/650


   JIRA issue: https://issues.apache.org/jira/browse/CAMEL-13704


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add github pull request template for PR instruction
> ---
>
> Key: CAMEL-13704
> URL: https://issues.apache.org/jira/browse/CAMEL-13704
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Willem Jiang
>Priority: Major
>  Labels: help-wanted
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> It's standard procedure to accept the big contribution with iCLA granted in 
> ASF.
> We should list this information when the contributor send the PR by 
> specifying a PR template for github.  It could be annoying for the 
> experienced contributors, but it could save us some time for the new 
> contributors. 
> Here is a draft I have, please add comment for it.
> {code}
>  - [ ] Make sure there is a [JIRA 
> issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change 
> (usually before you start working on it).  Trivial changes like typos do not 
> require a JIRA issue.  Your pull request should address just this issue, 
> without pulling in other changes.
>  - [ ] Each commit in the pull request should have a meaningful subject line 
> and body.
>  - [ ] Format the pull request title like `[CAMEL-XXX] Fixes bug in 
> camel-file component`, where you replace `CAMEL-XXX` with the appropriate 
> JIRA issue.
>  - [ ] Write a pull request description that is detailed enough to understand 
> what the pull request does, how, and why.
>  - [ ] Run `mvn clean install` in your module to make sure basic checks pass. 
> A more thorough check will be performed on your pull request automatically.
>  - [ ] If this contribution is large, please file an Apache [Individual 
> Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16992) [Website] Various version related changes

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419273#comment-17419273
 ] 

ASF GitHub Bot commented on CAMEL-16992:


djencks merged pull request #628:
URL: https://github.com/apache/camel-website/pull/628


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Website] Various version related changes
> -
>
> Key: CAMEL-16992
> URL: https://issues.apache.org/jira/browse/CAMEL-16992
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> This includes several version related changes to the website:
>  * Drop 3.4.x as it is EOL/unmaintained.  This involves camel, spring-boot, 
> and camel-karat.
>  * Mark the 'latest' camel version as prerelease and set the display-version 
> to "3.12.0 (Prerelease)"
> * Encourage xrefs to go to the correct version by moving the "eip-vc" 
> attribute to the user-manual component descriptor (the only component it 
> should be used from) and removing all uses of it and 'latest@component' from 
> the components component in the main, 3.11.x, and 3.7.x branches of camel.
> 
> After the first round of PRs for main, camel-3.11.x, camel-3.7.x, camel-2.x 
> and camel-website I realized there are still some problems with links to 
> `latest@component` from the user-manual and 2.x. We should not link to 
> unreleased doc versions, so these should link to (currently) 3.11.x.  Now 
> that 'latest' is marked prerelease, leaving out the version in the xref will 
> result in this behavior.  Since this will make the eip-vc attribute just 
> `components` I'm going to replace uses of {eip-vc} with its value.  This will 
> affect main user-manual and camel-2.x.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16992) [Website] Various version related changes

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418846#comment-17418846
 ] 

ASF GitHub Bot commented on CAMEL-16992:


github-actions[bot] commented on pull request #628:
URL: https://github.com/apache/camel-website/pull/628#issuecomment-925354388


    Preview is available at https://pr-628--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Website] Various version related changes
> -
>
> Key: CAMEL-16992
> URL: https://issues.apache.org/jira/browse/CAMEL-16992
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> This includes several version related changes to the website:
>  * Drop 3.4.x as it is EOL/unmaintained.  This involves camel, spring-boot, 
> and camel-karat.
>  * Mark the 'latest' camel version as prerelease and set the display-version 
> to "3.12.0 (Prerelease)"
> * Encourage xrefs to go to the correct version by moving the "eip-vc" 
> attribute to the user-manual component descriptor (the only component it 
> should be used from) and removing all uses of it and 'latest@component' from 
> the components component in the main, 3.11.x, and 3.7.x branches of camel.
> 
> After the first round of PRs for main, camel-3.11.x, camel-3.7.x, camel-2.x 
> and camel-website I realized there are still some problems with links to 
> `latest@component` from the user-manual and 2.x. We should not link to 
> unreleased doc versions, so these should link to (currently) 3.11.x.  Now 
> that 'latest' is marked prerelease, leaving out the version in the xref will 
> result in this behavior.  Since this will make the eip-vc attribute just 
> `components` I'm going to replace uses of {eip-vc} with its value.  This will 
> affect main user-manual and camel-2.x.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16992) [Website] Various version related changes

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418405#comment-17418405
 ] 

ASF GitHub Bot commented on CAMEL-16992:


github-actions[bot] commented on pull request #628:
URL: https://github.com/apache/camel-website/pull/628#issuecomment-924578574


    Preview is available at https://pr-628--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Website] Various version related changes
> -
>
> Key: CAMEL-16992
> URL: https://issues.apache.org/jira/browse/CAMEL-16992
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> This includes several version related changes to the website:
>  * Drop 3.4.x as it is EOL/unmaintained.  This involves camel, spring-boot, 
> and camel-karat.
>  * Mark the 'latest' camel version as prerelease and set the display-version 
> to "3.12.0 (Prerelease)"
> * Encourage xrefs to go to the correct version by moving the "eip-vc" 
> attribute to the user-manual component descriptor (the only component it 
> should be used from) and removing all uses of it and 'latest@component' from 
> the components component in the main, 3.11.x, and 3.7.x branches of camel.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16992) [Website] Various version related changes

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418394#comment-17418394
 ] 

ASF GitHub Bot commented on CAMEL-16992:


djencks opened a new pull request #628:
URL: https://github.com/apache/camel-website/pull/628


   This builds against the other PR branches for this issue and 
   - drops version 3.4.x (EOL) (affects camel, camel-spring-boot, camel-karaf)
   - removes attribute eip-vc (moved to user-manual component descriptor)
   - sets logging level to warn, since info is too noisy and provides little 
useful information.
   
   After the other PR branches are merged this can be updated to point to the 
official camel/camel repo, and merged.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Website] Various version related changes
> -
>
> Key: CAMEL-16992
> URL: https://issues.apache.org/jira/browse/CAMEL-16992
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> This includes several version related changes to the website:
>  * Drop 3.4.x as it is EOL/unmaintained.  This involves camel, spring-boot, 
> and camel-karat.
>  * Mark the 'latest' camel version as prerelease and set the display-version 
> to "3.12.0 (Prerelease)"
> * Encourage xrefs to go to the correct version by moving the "eip-vc" 
> attribute to the user-manual component descriptor (the only component it 
> should be used from) and removing all uses of it and 'latest@component' from 
> the components component in the main, 3.11.x, and 3.7.x branches of camel.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16576) Merge duplicate adoc and md files related to community topics

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341885#comment-17341885
 ] 

ASF GitHub Bot commented on CAMEL-16576:


github-actions[bot] commented on pull request #573:
URL: https://github.com/apache/camel-website/pull/573#issuecomment-836648452


    Preview is available at https://pr-573--camel.netlify.app


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Merge duplicate adoc and md files related to community topics
> -
>
> Key: CAMEL-16576
> URL: https://issues.apache.org/jira/browse/CAMEL-16576
> Project: Camel
>  Issue Type: Task
>  Components: website
>Affects Versions: 3.9.0
>Reporter: Karen Lease
>Priority: Minor
>  Labels: website
> Attachments: analysis_and_proposal.txt
>
>
> In the User Manual, most of the files in the "Community" section (Mailing 
> Lists, Support, Team, User Stories, as well as Books in the "Resources & 
> Guides" section, exist as .adoc files in the camel project but also as .md 
> files in camel-website/content/community. Some links in the website reference 
> adoc files and others reference md files.
> Both sets of files have changes so the content is not always consistent.Only 
> one set of files should be maintained and the other ones should be removed.
> After discussion with [~zregvart] it has been decided to remove the .adoc 
> files and keep the .md files.
> The Community section in the user manual navigation panel and index page will 
> be removed.
> The /CONTRIBUTING.md in the GitHub Camel repository contains almost the same 
> content as the contributing.adoc file in the User Manual. The main 
> contributing content will be put in the camel-website/content/community 
> section. The CONTRIBUTING.md file at the repository root will be contain only 
> the guidelines for actually making a contribution and it will link to the 
> Community contributing.md file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16576) Merge duplicate adoc and md files related to community topics

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341875#comment-17341875
 ] 

ASF GitHub Bot commented on CAMEL-16576:


zregvart merged pull request #573:
URL: https://github.com/apache/camel-website/pull/573


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Merge duplicate adoc and md files related to community topics
> -
>
> Key: CAMEL-16576
> URL: https://issues.apache.org/jira/browse/CAMEL-16576
> Project: Camel
>  Issue Type: Task
>  Components: website
>Affects Versions: 3.9.0
>Reporter: Karen Lease
>Priority: Minor
>  Labels: website
> Attachments: analysis_and_proposal.txt
>
>
> In the User Manual, most of the files in the "Community" section (Mailing 
> Lists, Support, Team, User Stories, as well as Books in the "Resources & 
> Guides" section, exist as .adoc files in the camel project but also as .md 
> files in camel-website/content/community. Some links in the website reference 
> adoc files and others reference md files.
> Both sets of files have changes so the content is not always consistent.Only 
> one set of files should be maintained and the other ones should be removed.
> After discussion with [~zregvart] it has been decided to remove the .adoc 
> files and keep the .md files.
> The Community section in the user manual navigation panel and index page will 
> be removed.
> The /CONTRIBUTING.md in the GitHub Camel repository contains almost the same 
> content as the contributing.adoc file in the User Manual. The main 
> contributing content will be put in the camel-website/content/community 
> section. The CONTRIBUTING.md file at the repository root will be contain only 
> the guidelines for actually making a contribution and it will link to the 
> Community contributing.md file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16576) Merge duplicate adoc and md files related to community topics

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341524#comment-17341524
 ] 

ASF GitHub Bot commented on CAMEL-16576:


klease opened a new pull request #573:
URL: https://github.com/apache/camel-website/pull/573


   The Community section of the Camel user manual contained .adoc pages which 
duplicated content in the Community section of the website. They've been 
removed and extra changes made there have been merged to the pages in the 
Community section.
   There are also changes in the camel repository itself which need to be 
merged at the same time as these.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Merge duplicate adoc and md files related to community topics
> -
>
> Key: CAMEL-16576
> URL: https://issues.apache.org/jira/browse/CAMEL-16576
> Project: Camel
>  Issue Type: Task
>  Components: website
>Affects Versions: 3.9.0
>Reporter: Karen Lease
>Priority: Minor
>  Labels: website
> Attachments: analysis_and_proposal.txt
>
>
> In the User Manual, most of the files in the "Community" section (Mailing 
> Lists, Support, Team, User Stories, as well as Books in the "Resources & 
> Guides" section, exist as .adoc files in the camel project but also as .md 
> files in camel-website/content/community. Some links in the website reference 
> adoc files and others reference md files.
> Both sets of files have changes so the content is not always consistent.Only 
> one set of files should be maintained and the other ones should be removed.
> After discussion with [~zregvart] it has been decided to remove the .adoc 
> files and keep the .md files.
> The Community section in the user manual navigation panel and index page will 
> be removed.
> The /CONTRIBUTING.md in the GitHub Camel repository contains almost the same 
> content as the contributing.adoc file in the User Manual. The main 
> contributing content will be put in the camel-website/content/community 
> section. The CONTRIBUTING.md file at the repository root will be contain only 
> the guidelines for actually making a contribution and it will link to the 
> Community contributing.md file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16204) Broken download links for Camel Quarkus 1.5.0

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284565#comment-17284565
 ] 

ASF GitHub Bot commented on CAMEL-16204:


github-actions[bot] commented on pull request #538:
URL: https://github.com/apache/camel-website/pull/538#issuecomment-778986778


    Preview for c2992e409d822a5a6d80d67a9008121f9e7cf27f is available at 
https://pr-538--camel.netlify.app



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Broken download links for Camel Quarkus 1.5.0
> -
>
> Key: CAMEL-16204
> URL: https://issues.apache.org/jira/browse/CAMEL-16204
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Sebb
>Assignee: Andrea Cosentino
>Priority: Minor
>
> As the subject says.
> Looks like the download page has still not been updated for Quarkus 1.6.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16204) Broken download links for Camel Quarkus 1.5.0

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284562#comment-17284562
 ] 

ASF GitHub Bot commented on CAMEL-16204:


oscerd commented on a change in pull request #538:
URL: https://github.com/apache/camel-website/pull/538#discussion_r575965360



##
File path: content/releases/q/release-1.6.0.md
##
@@ -0,0 +1,11 @@
+---
+url: "/releases/q-1.5.0/"

Review comment:
   Thanks, fixed.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Broken download links for Camel Quarkus 1.5.0
> -
>
> Key: CAMEL-16204
> URL: https://issues.apache.org/jira/browse/CAMEL-16204
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Sebb
>Assignee: Andrea Cosentino
>Priority: Minor
>
> As the subject says.
> Looks like the download page has still not been updated for Quarkus 1.6.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16204) Broken download links for Camel Quarkus 1.5.0

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284560#comment-17284560
 ] 

ASF GitHub Bot commented on CAMEL-16204:


davsclaus commented on a change in pull request #538:
URL: https://github.com/apache/camel-website/pull/538#discussion_r575964790



##
File path: content/releases/q/release-1.6.0.md
##
@@ -0,0 +1,11 @@
+---
+url: "/releases/q-1.5.0/"

Review comment:
   Is this url correct, should it not be 1.6.0 ?





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Broken download links for Camel Quarkus 1.5.0
> -
>
> Key: CAMEL-16204
> URL: https://issues.apache.org/jira/browse/CAMEL-16204
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Sebb
>Assignee: Andrea Cosentino
>Priority: Minor
>
> As the subject says.
> Looks like the download page has still not been updated for Quarkus 1.6.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16204) Broken download links for Camel Quarkus 1.5.0

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284555#comment-17284555
 ] 

ASF GitHub Bot commented on CAMEL-16204:


oscerd merged pull request #538:
URL: https://github.com/apache/camel-website/pull/538


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Broken download links for Camel Quarkus 1.5.0
> -
>
> Key: CAMEL-16204
> URL: https://issues.apache.org/jira/browse/CAMEL-16204
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Sebb
>Assignee: Andrea Cosentino
>Priority: Minor
>
> As the subject says.
> Looks like the download page has still not been updated for Quarkus 1.6.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16204) Broken download links for Camel Quarkus 1.5.0

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284554#comment-17284554
 ] 

ASF GitHub Bot commented on CAMEL-16204:


oscerd opened a new pull request #538:
URL: https://github.com/apache/camel-website/pull/538


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Broken download links for Camel Quarkus 1.5.0
> -
>
> Key: CAMEL-16204
> URL: https://issues.apache.org/jira/browse/CAMEL-16204
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Sebb
>Assignee: Andrea Cosentino
>Priority: Minor
>
> As the subject says.
> Looks like the download page has still not been updated for Quarkus 1.6.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16038) Remove binary releases

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265205#comment-17265205
 ] 

ASF GitHub Bot commented on CAMEL-16038:


zregvart merged pull request #528:
URL: https://github.com/apache/camel-website/pull/528


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Remove binary releases
> --
>
> Key: CAMEL-16038
> URL: https://issues.apache.org/jira/browse/CAMEL-16038
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
>
> As 
> [discussed|https://lists.apache.org/thread.html/r2b9a9a4d2946608832f68b6144ed35fb7896ed83d7e3b0213202acf4%40%3Cdev.camel.apache.org%3E]
>  on user/dev mailing list, there is little use of the Camel binary release. 
> For this we'll do:
>  # Remove "Binary zip" and "Binary tar.gz" rows from the table in 
> [https://camel.apache.org/download/] and individual releases (e.g. 
> [https://camel.apache.org/releases/release-3.4.5/#camel])
>  # Remove binary releases from ASF distribution (e.g. {{*.tar.gz*}} and non 
> {{-src}} {{*.zip}} 
> [https://dist.apache.org/repos/dist/release/camel/apache-camel/3.7.0/])
>  # Remove binary assembly
> We will continue to have binary releases for tools that can be downloaded and 
> used directly as such, for example {{kamel}} CLI, or future {{karamel}} CLI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16038) Remove binary releases

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265201#comment-17265201
 ] 

ASF GitHub Bot commented on CAMEL-16038:


github-actions[bot] commented on pull request #528:
URL: https://github.com/apache/camel-website/pull/528#issuecomment-760452163


    Preview for fbb71997819383ec0323ce2716eebf46cffae988 is available at 
https://pr-528--camel.netlify.app



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Remove binary releases
> --
>
> Key: CAMEL-16038
> URL: https://issues.apache.org/jira/browse/CAMEL-16038
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
>
> As 
> [discussed|https://lists.apache.org/thread.html/r2b9a9a4d2946608832f68b6144ed35fb7896ed83d7e3b0213202acf4%40%3Cdev.camel.apache.org%3E]
>  on user/dev mailing list, there is little use of the Camel binary release. 
> For this we'll do:
>  # Remove "Binary zip" and "Binary tar.gz" rows from the table in 
> [https://camel.apache.org/download/] and individual releases (e.g. 
> [https://camel.apache.org/releases/release-3.4.5/#camel])
>  # Remove binary releases from ASF distribution (e.g. {{*.tar.gz*}} and non 
> {{-src}} {{*.zip}} 
> [https://dist.apache.org/repos/dist/release/camel/apache-camel/3.7.0/])
>  # Remove binary assembly
> We will continue to have binary releases for tools that can be downloaded and 
> used directly as such, for example {{kamel}} CLI, or future {{karamel}} CLI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-16038) Remove binary releases

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265163#comment-17265163
 ] 

ASF GitHub Bot commented on CAMEL-16038:


zregvart opened a new pull request #528:
URL: https://github.com/apache/camel-website/pull/528


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Remove binary releases
> --
>
> Key: CAMEL-16038
> URL: https://issues.apache.org/jira/browse/CAMEL-16038
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
>
> As 
> [discussed|https://lists.apache.org/thread.html/r2b9a9a4d2946608832f68b6144ed35fb7896ed83d7e3b0213202acf4%40%3Cdev.camel.apache.org%3E]
>  on user/dev mailing list, there is little use of the Camel binary release. 
> For this we'll do:
>  # Remove "Binary zip" and "Binary tar.gz" rows from the table in 
> [https://camel.apache.org/download/] and individual releases (e.g. 
> [https://camel.apache.org/releases/release-3.4.5/#camel])
>  # Remove binary releases from ASF distribution (e.g. {{*.tar.gz*}} and non 
> {{-src}} {{*.zip}} 
> [https://dist.apache.org/repos/dist/release/camel/apache-camel/3.7.0/])
>  # Remove binary assembly
> We will continue to have binary releases for tools that can be downloaded and 
> used directly as such, for example {{kamel}} CLI, or future {{karamel}} CLI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15994) Broken links for 0.7.0 Kafka connector

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256130#comment-17256130
 ] 

ASF GitHub Bot commented on CAMEL-15994:


oscerd merged pull request #524:
URL: https://github.com/apache/camel-website/pull/524


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Broken links for 0.7.0 Kafka connector
> --
>
> Key: CAMEL-15994
> URL: https://issues.apache.org/jira/browse/CAMEL-15994
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Sebb
>Assignee: Andrea Cosentino
>Priority: Minor
>
> The links at https://camel.apache.org/download/#camel-kafka-connector are all 
> broken.
> The files apache-camel-kafka-connector-0.7.0-src.zip* do not exist; they 
> appear to be called:
> camel-kafka-connector-0.7.0-src.zip* instead.
> Please fix the page!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15994) Broken links for 0.7.0 Kafka connector

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256128#comment-17256128
 ] 

ASF GitHub Bot commented on CAMEL-15994:


github-actions[bot] commented on pull request #524:
URL: https://github.com/apache/camel-website/pull/524#issuecomment-752207977


    Preview for e822ae9f7bd14d11f77a11b96a21b5f42dafa8d9 is available at 
https://pr-524--camel.netlify.app



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Broken links for 0.7.0 Kafka connector
> --
>
> Key: CAMEL-15994
> URL: https://issues.apache.org/jira/browse/CAMEL-15994
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Sebb
>Assignee: Andrea Cosentino
>Priority: Minor
>
> The links at https://camel.apache.org/download/#camel-kafka-connector are all 
> broken.
> The files apache-camel-kafka-connector-0.7.0-src.zip* do not exist; they 
> appear to be called:
> camel-kafka-connector-0.7.0-src.zip* instead.
> Please fix the page!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15994) Broken links for 0.7.0 Kafka connector

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256108#comment-17256108
 ] 

ASF GitHub Bot commented on CAMEL-15994:


oscerd opened a new pull request #524:
URL: https://github.com/apache/camel-website/pull/524


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Broken links for 0.7.0 Kafka connector
> --
>
> Key: CAMEL-15994
> URL: https://issues.apache.org/jira/browse/CAMEL-15994
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Sebb
>Assignee: Andrea Cosentino
>Priority: Minor
>
> The links at https://camel.apache.org/download/#camel-kafka-connector are all 
> broken.
> The files apache-camel-kafka-connector-0.7.0-src.zip* do not exist; they 
> appear to be called:
> camel-kafka-connector-0.7.0-src.zip* instead.
> Please fix the page!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15948) camel-website - Quarkus examples are empty

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252698#comment-17252698
 ] 

ASF GitHub Bot commented on CAMEL-15948:


zregvart merged pull request #513:
URL: https://github.com/apache/camel-website/pull/513


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> camel-website - Quarkus examples are empty
> --
>
> Key: CAMEL-15948
> URL: https://issues.apache.org/jira/browse/CAMEL-15948
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Claus Ibsen
>Assignee: Peter Palaga
>Priority: Major
> Fix For: 3.8.0
>
>
> The table is empty at
> https://camel.apache.org/camel-quarkus/latest/user-guide/examples.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15948) camel-website - Quarkus examples are empty

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251993#comment-17251993
 ] 

ASF GitHub Bot commented on CAMEL-15948:


zregvart opened a new pull request #513:
URL: https://github.com/apache/camel-website/pull/513


   This adds the `@djencks/asciidoctor-jsonpath` dependency and a `exclude`
   helper to the theme so we can exclude `Camel Quarkus Examples` component
   from the navigation.
   
   This relies on https://github.com/apache/camel-quarkus-examples/pull/14 and 
https://github.com/apache/camel-quarkus/pull/2087



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> camel-website - Quarkus examples are empty
> --
>
> Key: CAMEL-15948
> URL: https://issues.apache.org/jira/browse/CAMEL-15948
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Claus Ibsen
>Assignee: Peter Palaga
>Priority: Major
> Fix For: 3.8.0
>
>
> The table is empty at
> https://camel.apache.org/camel-quarkus/latest/user-guide/examples.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15929) camel-website - Project names in bottom left menu

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246710#comment-17246710
 ] 

ASF GitHub Bot commented on CAMEL-15929:


zregvart merged pull request #506:
URL: https://github.com/apache/camel-website/pull/506


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> camel-website - Project names in bottom left menu
> -
>
> Key: CAMEL-15929
> URL: https://issues.apache.org/jira/browse/CAMEL-15929
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Claus Ibsen
>Assignee: Zoran Regvart
>Priority: Major
> Attachments: Screenshot 2020-12-09 at 11.23.04.png
>
>
> Apache Camel K -> Camel K
> Apache Camel Karaf -> Camel Karaf
> Camel Quarkus Examples -> SHOULD BE REMOVED
> Camel Spring Boot Starters -> Camel Spring Boot
> And can we order them so Camel Components are in the top?
> Camel Components



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15929) camel-website - Project names in bottom left menu

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246697#comment-17246697
 ] 

ASF GitHub Bot commented on CAMEL-15929:


zregvart opened a new pull request #506:
URL: https://github.com/apache/camel-website/pull/506


   We want the manual first, components next, and the rest of the
   sub-projects after them sorted alphabetically.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> camel-website - Project names in bottom left menu
> -
>
> Key: CAMEL-15929
> URL: https://issues.apache.org/jira/browse/CAMEL-15929
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Claus Ibsen
>Assignee: Zoran Regvart
>Priority: Major
> Attachments: Screenshot 2020-12-09 at 11.23.04.png
>
>
> Apache Camel K -> Camel K
> Apache Camel Karaf -> Camel Karaf
> Camel Quarkus Examples -> SHOULD BE REMOVED
> Camel Spring Boot Starters -> Camel Spring Boot
> And can we order them so Camel Components are in the top?
> Camel Components



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225450#comment-17225450
 ] 

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-720396826


   This passes all checks now. I'm going to merge it.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225398#comment-17225398
 ] 

ASF GitHub Bot commented on CAMEL-14682:


zregvart merged pull request #417:
URL: https://github.com/apache/camel-website/pull/417


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15774) [Website] suppress warnings for unimplemented camel-quarkus components; upgrade to Antora 3.0.0-alpha.1

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223516#comment-17223516
 ] 

ASF GitHub Bot commented on CAMEL-15774:


zregvart merged pull request #495:
URL: https://github.com/apache/camel-website/pull/495


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Website] suppress warnings for unimplemented camel-quarkus components; 
> upgrade to Antora 3.0.0-alpha.1
> ---
>
> Key: CAMEL-15774
> URL: https://issues.apache.org/jira/browse/CAMEL-15774
> Project: Camel
>  Issue Type: Bug
>  Components: website
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> With Antora 3.0.0-alpha.1, include:: instructions can suppress "asciidoctor: 
> ERROR: atlasmap-component.adoc: line 11: include target not found: ..." 
> errors by including 
> [opts=optional].  This modifies tooling to include this in the generated 
> includes for cq bits, updates the generated files correspondingly, and 
> upgrades the Antora version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15774) [Website] suppress warnings for unimplemented camel-quarkus components; upgrade to Antora 3.0.0-alpha.1

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223517#comment-17223517
 ] 

ASF GitHub Bot commented on CAMEL-15774:


zregvart commented on pull request #495:
URL: https://github.com/apache/camel-website/pull/495#issuecomment-719439534


   Thanks!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Website] suppress warnings for unimplemented camel-quarkus components; 
> upgrade to Antora 3.0.0-alpha.1
> ---
>
> Key: CAMEL-15774
> URL: https://issues.apache.org/jira/browse/CAMEL-15774
> Project: Camel
>  Issue Type: Bug
>  Components: website
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> With Antora 3.0.0-alpha.1, include:: instructions can suppress "asciidoctor: 
> ERROR: atlasmap-component.adoc: line 11: include target not found: ..." 
> errors by including 
> [opts=optional].  This modifies tooling to include this in the generated 
> includes for cq bits, updates the generated files correspondingly, and 
> upgrades the Antora version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223484#comment-17223484
 ] 

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-719386057


   Seems that versions of html-validate and link-checker were upgraded (I 
didn't really check). And that causes [validation issues on 
CI](https://ci-builds.apache.org/job/Camel/job/Camel.website/job/PR-417/40/consoleFull).
 Latest of which is with the HTML validation. I'll go ahead and fix those on 
this PR as well.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223448#comment-17223448
 ] 

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-719290993


   @djencks awesome, thanks!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15774) [Website] suppress warnings for unimplemented camel-quarkus components; upgrade to Antora 3.0.0-alpha.1

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223320#comment-17223320
 ] 

ASF GitHub Bot commented on CAMEL-15774:


djencks opened a new pull request #495:
URL: https://github.com/apache/camel-website/pull/495


   actual Antora version upgrade.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Website] suppress warnings for unimplemented camel-quarkus components; 
> upgrade to Antora 3.0.0-alpha.1
> ---
>
> Key: CAMEL-15774
> URL: https://issues.apache.org/jira/browse/CAMEL-15774
> Project: Camel
>  Issue Type: Bug
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> With Antora 3.0.0-alpha.1, include:: instructions can suppress "asciidoctor: 
> ERROR: atlasmap-component.adoc: line 11: include target not found: ..." 
> errors by including 
> [opts=optional].  This modifies tooling to include this in the generated 
> includes for cq bits, updates the generated files correspondingly, and 
> upgrades the Antora version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223258#comment-17223258
 ] 

ASF GitHub Bot commented on CAMEL-14682:


djencks edited a comment on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-719052913


   It's unnecessary to revert the xref validator version, we can change the 
filter in the indexTable macro. Issue and PRs on its way.
   See https://issues.apache.org/jira/browse/CAMEL-15773



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223245#comment-17223245
 ] 

ASF GitHub Bot commented on CAMEL-14682:


djencks commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-719052913


   It's unnecessary to revert the xref validator version, we can change the 
filter in the indexTable macro. Issue and PRs on its way.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222967#comment-17222967
 ] 

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-718834738


   Managed to get Netlify to work by forcing version Yarn version 1.22.5. Now 
some checks fail with:
   
   ```
   page not found from misc/index.html to misc/%22/privacy-policy%22
   page not found from blog/2020/10/ApacheCon-at-Home-videos/index.html to 
blog/2020/10/ApacheCon-at-Home-videos/Pupier_Aur%C3%A9lien_How_to_contribute_textual_tooling_for_Apache_Camel_in_several_IDEs.pdf
   ```
   
   Need to investigate that.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222879#comment-17222879
 ] 

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-718732507


   Unplugging highlight.js seems to have helped with this. There is still the 
issue with Netlify preview which I think can be solved by using a newer Yarn 
version there. The error is:
   
   ```
   1:43:09 PM: yarn install v1.17.0
   1:43:09 PM: error Workspaces can only be enabled in private projects.
   1:43:09 PM: info Visit https://yarnpkg.com/en/docs/cli/install for 
documentation about this command.
   1:43:09 PM: Error during Yarn install
   ```



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222787#comment-17222787
 ] 

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-718506089


   Seems that I've missed something in the theme build, this is reported [on 
CI](https://ci-builds.apache.org/job/Camel/job/Camel.website/job/PR-417/30/console):
   ```
   ➤ YN: [08:42:30] The following tasks did not complete: bundle, , 
build
   ➤ YN: [08:42:30] Did you forget to signal async completion?
   ```
   
   I'll work on getting that fixed before I merge this.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222776#comment-17222776
 ] 

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-718477932


   I think I'll force the older version of xref-validator we use on main branch 
here and update when a fix is ready (either in the asciidoctor-antora-indexer 
or in the xref-validator).



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-14682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221764#comment-17221764
 ] 

ASF GitHub Bot commented on CAMEL-14682:


djencks commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-717545925


   This is due to a recent change in the xref-validator, where nav files are 
adopted by the page family.  See 
https://gitlab.com/antora/xref-validator/-/issues/9 

   
   David Jencks
   
   > On Oct 27, 2020, at 7:40 AM, Zoran Regvart  
wrote:
   > 
   > 
   > I'm seeing unresolved xrefs:
   > 
   > Unresolved xrefs (grouped by origin):  
 
   > 
   > repo: https://github.com/apache/camel.git | branch: camel-2.x | component: 
components | version: 2.x
   >   path: docs/components/modules/dataformats/pages/index.adoc | xref: 
2.x@components:dataformats:nav.adoc
   >   path: docs/components/modules/languages/pages/index.adoc | xref: 
2.x@components:languages:nav.adoc
   >   path: docs/components/modules/others/pages/index.adoc | xref: 
2.x@components:others:nav.adoc
   >   path: docs/components/modules/ROOT/pages/index.adoc | xref: 
2.x@components:ROOT:nav.adoc
   > 
   > repo: https://github.com/apache/camel.git | branch: camel-3.4.x | 
component: components | version: 3.4.x
   >   path: docs/components/modules/dataformats/pages/index.adoc | xref: 
3.4.x@components:dataformats:nav.adoc
   >   path: docs/components/modules/languages/pages/index.adoc | xref: 
3.4.x@components:languages:nav.adoc
   >   path: docs/components/modules/others/pages/index.adoc | xref: 
3.4.x@components:others:nav.adoc
   >   path: docs/components/modules/ROOT/pages/index.adoc | xref: 
3.4.x@components:ROOT:nav.adoc
   > 
   > repo: https://github.com/apache/camel.git | branch: master | component: 
components | version: latest
   >   path: docs/components/modules/dataformats/pages/index.adoc | xref: 
latest@components:dataformats:nav.adoc
   >   path: docs/components/modules/languages/pages/index.adoc | xref: 
latest@components:languages:nav.adoc
   >   path: docs/components/modules/others/pages/index.adoc | xref: 
latest@components:others:nav.adoc
   >   path: docs/components/modules/ROOT/pages/index.adoc | xref: 
latest@components:ROOT:nav.adoc
   > 
   > antora: xref validation failed! Found 12 unresolved xrefs. See previous 
report for details.
   > —
   > You are receiving this because you are subscribed to this thread.
   > Reply to this email directly, view it on GitHub 
, or 
unsubscribe 
.
   > 
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220781#comment-17220781
 ] 

ASF GitHub Bot commented on CAMEL-15392:


zregvart commented on pull request #471:
URL: https://github.com/apache/camel-website/pull/471#issuecomment-716640940


   This is now merged thanks @aashnajena and @AemieJ. I'm sure we'll find other 
issues to improve, feel free to raise issues or create additional PRs for them.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220779#comment-17220779
 ] 

ASF GitHub Bot commented on CAMEL-15392:


zregvart merged pull request #471:
URL: https://github.com/apache/camel-website/pull/471


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218152#comment-17218152
 ] 

ASF GitHub Bot commented on CAMEL-15392:


zregvart commented on pull request #471:
URL: https://github.com/apache/camel-website/pull/471#issuecomment-713367576


   I'm rather tied up with other tasks, so I didn't have the time to look at 
this yesterday, I'll try to find some time today.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217487#comment-17217487
 ] 

ASF GitHub Bot commented on CAMEL-15392:


zregvart commented on pull request #471:
URL: https://github.com/apache/camel-website/pull/471#issuecomment-712746433


   @aashnajena thanks for the ping. I'll rebase and merge this later today.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217464#comment-17217464
 ] 

ASF GitHub Bot commented on CAMEL-15392:


aashnajena commented on pull request #471:
URL: https://github.com/apache/camel-website/pull/471#issuecomment-712724304


   @zregvart can we fix and merge this? The website still shows underlines 
under images and I think this PR fixes that as well



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15296) Create sitemap for Camel website

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202151#comment-17202151
 ] 

ASF GitHub Bot commented on CAMEL-15296:


zregvart merged pull request #462:
URL: https://github.com/apache/camel-website/pull/462


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create sitemap for Camel website
> 
>
> Key: CAMEL-15296
> URL: https://issues.apache.org/jira/browse/CAMEL-15296
> Project: Camel
>  Issue Type: New Feature
>  Components: website
>Reporter: Aashna Jena
>Priority: Minor
>  Labels: outreachy2020
> Attachments: Screenshot from 2020-08-15 02-58-11.png, Screenshot from 
> 2020-08-15 03-09-58.png, Screenshot from 2020-08-15 03-10-53.png, 
> components-sitemap.png, hugo-sitemap-with-blog-categories.png, 
> user-manual-sitemap.png
>
>
> Create a page with links to all documentation pages on the website. Automate 
> this process and organise the links category wise.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15296) Create sitemap for Camel website

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202133#comment-17202133
 ] 

ASF GitHub Bot commented on CAMEL-15296:


zregvart commented on pull request #462:
URL: https://github.com/apache/camel-website/pull/462#issuecomment-698540521


   Thanks!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create sitemap for Camel website
> 
>
> Key: CAMEL-15296
> URL: https://issues.apache.org/jira/browse/CAMEL-15296
> Project: Camel
>  Issue Type: New Feature
>  Components: website
>Reporter: Aashna Jena
>Priority: Minor
>  Labels: outreachy2020
> Attachments: Screenshot from 2020-08-15 02-58-11.png, Screenshot from 
> 2020-08-15 03-09-58.png, Screenshot from 2020-08-15 03-10-53.png, 
> components-sitemap.png, hugo-sitemap-with-blog-categories.png, 
> user-manual-sitemap.png
>
>
> Create a page with links to all documentation pages on the website. Automate 
> this process and organise the links category wise.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15296) Create sitemap for Camel website

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201738#comment-17201738
 ] 

ASF GitHub Bot commented on CAMEL-15296:


zregvart merged pull request #462:
URL: https://github.com/apache/camel-website/pull/462


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create sitemap for Camel website
> 
>
> Key: CAMEL-15296
> URL: https://issues.apache.org/jira/browse/CAMEL-15296
> Project: Camel
>  Issue Type: New Feature
>  Components: website
>Reporter: Aashna Jena
>Priority: Minor
>  Labels: outreachy2020
> Attachments: Screenshot from 2020-08-15 02-58-11.png, Screenshot from 
> 2020-08-15 03-09-58.png, Screenshot from 2020-08-15 03-10-53.png, 
> components-sitemap.png, hugo-sitemap-with-blog-categories.png, 
> user-manual-sitemap.png
>
>
> Create a page with links to all documentation pages on the website. Automate 
> this process and organise the links category wise.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15296) Create sitemap for Camel website

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201737#comment-17201737
 ] 

ASF GitHub Bot commented on CAMEL-15296:


zregvart commented on pull request #462:
URL: https://github.com/apache/camel-website/pull/462#issuecomment-698540521


   Thanks!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create sitemap for Camel website
> 
>
> Key: CAMEL-15296
> URL: https://issues.apache.org/jira/browse/CAMEL-15296
> Project: Camel
>  Issue Type: New Feature
>  Components: website
>Reporter: Aashna Jena
>Priority: Minor
>  Labels: outreachy2020
> Attachments: Screenshot from 2020-08-15 02-58-11.png, Screenshot from 
> 2020-08-15 03-09-58.png, Screenshot from 2020-08-15 03-10-53.png, 
> components-sitemap.png, hugo-sitemap-with-blog-categories.png, 
> user-manual-sitemap.png
>
>
> Create a page with links to all documentation pages on the website. Automate 
> this process and organise the links category wise.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186377#comment-17186377
 ] 

ASF GitHub Bot commented on CAMEL-15392:


aashnajena commented on a change in pull request #471:
URL: https://github.com/apache/camel-website/pull/471#discussion_r478928891



##
File path: antora-ui-camel/src/css/docs.css
##
@@ -1,154 +1,84 @@
-.docs {
-  padding: 1rem 3rem;
-}
-
-.docs p:empty {
-  display: none;
-}
-
-.section h2 {
-  text-align: center;
-  padding-bottom: 0;
-}
-
-.camel-project {
-  width: calc(100% - 3rem);
-  display: inline-flex;
-  border: 1px solid var(--color-smoke-90);
+.docs,
+.community {
+  padding: 1rem 3rem 2rem;
+  display: flex;
+  width: 80%;
   flex-direction: column;
-  align-items: center;
-  text-align: center;
-  padding: 1rem 1rem 2rem 1rem;
-  margin: 1.5rem;
-  border-radius: 10px;
 }
 
-.camel-project .section {
-  border: none;
-  padding: 0;
-}
-
-.camel-project .section.core {
-  width: 100%;
+.docs .box,
+.community .box {
+  display: flex;
+  margin: 1rem 0;
 }
 
-.camel-project .camel-documentation .links {
-  background-color: var(--color-camel-orange-light);
-  padding: 0 0.5rem;
-  border-radius: 25px;
-  color: var(--navbar-background);
+.docs .box .content,
+.community .box .content {
+  width: 70%;
 }
 
-.camel-project .camel-documentation .links a {
-  color: var(--navbar-background);
-  font-weight: bolder;
+.docs .box img,
+.community .box img {
+  margin-top: 4rem;
+  height: 8vw;
+  max-height: 6rem;
+  margin-right: 0.5rem;
 }
 
-.section {
-  display: inline-flex;
-  border: 1px solid var(--color-smoke-90);
-  width: calc(50% - 3.2rem);
-  flex-direction: column;
-  align-items: center;
+.docs .box .icon {
+  width: 30%;
   text-align: center;
-  padding: 1rem;
-  margin: 1.5rem;
-  border-radius: 10px;
-}
-
-.section > a,
-.camel-project > a {
-  background: none;
-}
-
-.section a > img,
-.camel-project a > img {
-  display: inline-block;
-  width: auto;
-  height: 5rem;
-  margin-top: 1rem;
-}
-
-.section a > img + img {
-  padding-left: 1rem;
 }
 
-.section .description {
-  padding: 1.2rem;
+.docs .box.camel-core .icon,
+.community .box .icon {
+  width: 20%;
   text-align: center;
 }
 
-.section .list {
-  display: flex;
-  flex-wrap: wrap;
-  justify-content: center;
-}
-
-.section .links {
-  display: flex;
-  flex-wrap: wrap;
-  align-items: center;
-  margin: 1.5rem 0;
-  word-break: break-word;
-  background-color: var(--color-camel-orange-light);
-  padding: 0 0.5rem;
-  border-radius: 25px;
-  color: var(--navbar-background);
-}
-
-.section .list pre {
-  padding: 0;
-  width: 0.5rem;
-  box-shadow: none;
-  overflow-x: hidden;
-  background: none;
-}
-
-.section .list .links {
-  margin: 0.5rem;
+.icon a,
+a.button-light,
+a.button-dark {
+  background-image: none;
 }
 
-.section .links img {
-  height: 1.5rem;
-  width: 2rem;
-  margin: 0.35rem 0 0 0.25rem;
-}
-
-.section .links p {
-  margin: 0;
-}
-
-.section .links .partition {
-  background: #fff;
-  height: 2.5rem;
-  width: 0.1rem;
-  margin: 0 0.5rem;
-}
-
-.section .links a {
-  color: var(--navbar-background);
-  font-weight: bolder;
+.docs .box.camel-core .content {
+  width: 80%;
 }
 
 @media screen and (max-width: 1023px) {
-  .docs {
+  .docs,
+  .community {
 padding: 0 1rem 4rem;
+width: 100%;
   }
 
-  .camel-project,
-  .section {
-width: calc(100% - 1rem);
-margin: 1.5rem -1.5rem 1.5rem 0.5rem;
+  .docs .box,
+  .community .box,
+  .docs .box .content,
+  .community .box .content,
+  .docs .box .icon,
+  .community .box .icon {

Review comment:
   Missed out on these rules earlier
   
   ```suggestion
 .community .box .icon,
 .docs .box.camel-core .content,
 .docs .box.camel-core .icon {
   ```

##
File path: antora-ui-camel/src/css/frontpage.css
##
@@ -74,30 +74,32 @@ header.frontpage p {
   line-height: 1.7rem;
 }
 
-.frontpage a.button-dark,
-.frontpage a.button-dark:hover {
+a.button,
+section.frontpage a.button {
   white-space: nowrap;
-  padding: 0.7rem 1rem;
-  background-color: var(--color-camel-orange);
-  background-image: none;
-  background-repeat: no-repeat;
-  background-position: 0;
-  color: white;
-  font-weight: bold;
   margin-right: 0.5rem;
+  background-image: none;
   border-radius: 3rem;
-  outline: none;
-  display: inline-block;
-  box-shadow: 0 4px #8e480b;
+  font-weight: bold;
+  padding: 0.4rem 1rem;

Review comment:
   My view at 1024px 100% zoom
   
   ![Screenshot 2020-08-28 at 1 48 47 
PM](https://user-images.githubusercontent.com/32356795/91538379-64172b80-e935-11ea-8f54-27f8350d24c6.png)
   





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please 

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186366#comment-17186366
 ] 

ASF GitHub Bot commented on CAMEL-15392:


AemieJ commented on pull request #471:
URL: https://github.com/apache/camel-website/pull/471#issuecomment-682391273


   @aashnajena I hear you but I respectfully disagree with you. In my opinion, 
altering a few lines of CSS and making it look structured and consistent 
through gives a neater effect to the design be it 1 or 2 images. 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186361#comment-17186361
 ] 

ASF GitHub Bot commented on CAMEL-15392:


AemieJ commented on a change in pull request #471:
URL: https://github.com/apache/camel-website/pull/471#discussion_r478917571



##
File path: antora-ui-camel/src/css/frontpage.css
##
@@ -74,30 +74,32 @@ header.frontpage p {
   line-height: 1.7rem;
 }
 
-.frontpage a.button-dark,
-.frontpage a.button-dark:hover {
+a.button,
+section.frontpage a.button {
   white-space: nowrap;
-  padding: 0.7rem 1rem;
-  background-color: var(--color-camel-orange);
-  background-image: none;
-  background-repeat: no-repeat;
-  background-position: 0;
-  color: white;
-  font-weight: bold;
   margin-right: 0.5rem;
+  background-image: none;
   border-radius: 3rem;
-  outline: none;
-  display: inline-block;
-  box-shadow: 0 4px #8e480b;
+  font-weight: bold;
+  padding: 0.4rem 1rem;

Review comment:
   This overlapping is observed for 1024px as well. 





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186360#comment-17186360
 ] 

ASF GitHub Bot commented on CAMEL-15392:


aashnajena commented on a change in pull request #471:
URL: https://github.com/apache/camel-website/pull/471#discussion_r478909001



##
File path: antora-ui-camel/src/css/frontpage.css
##
@@ -74,30 +74,32 @@ header.frontpage p {
   line-height: 1.7rem;
 }
 
-.frontpage a.button-dark,
-.frontpage a.button-dark:hover {
+a.button,
+section.frontpage a.button {
   white-space: nowrap;
-  padding: 0.7rem 1rem;
-  background-color: var(--color-camel-orange);
-  background-image: none;
-  background-repeat: no-repeat;
-  background-position: 0;
-  color: white;
-  font-weight: bold;
   margin-right: 0.5rem;
+  background-image: none;
   border-radius: 3rem;
-  outline: none;
-  display: inline-block;
-  box-shadow: 0 4px #8e480b;
+  font-weight: bold;
+  padding: 0.4rem 1rem;

Review comment:
   When exactly are you observing the overlap? I have already provided 
line-height for <1024px screens (line 355) to avoid the overlap, and I can't 
see the buttons overlapping for any screen width.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186359#comment-17186359
 ] 

ASF GitHub Bot commented on CAMEL-15392:


aashnajena commented on pull request #471:
URL: https://github.com/apache/camel-website/pull/471#issuecomment-682388217


   @AemieJ The camel core context is not aligned with the rest because there's 
only one icon present, and if we give it 30% width, it leaves a lot of blank 
space which looks bad. Since the alignments are alternating, it's not a 
noticeable flaw. 
   
   I did think about making them all left-aligned, but it looks very odd to 
have one icon for camel core and two for the rest. If we can use just one icon 
for each sub-project, the left-alignment will look good. 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15392) Provide a modified neat card layout for community & docs

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186355#comment-17186355
 ] 

ASF GitHub Bot commented on CAMEL-15392:


aashnajena commented on a change in pull request #471:
URL: https://github.com/apache/camel-website/pull/471#discussion_r478909001



##
File path: antora-ui-camel/src/css/frontpage.css
##
@@ -74,30 +74,32 @@ header.frontpage p {
   line-height: 1.7rem;
 }
 
-.frontpage a.button-dark,
-.frontpage a.button-dark:hover {
+a.button,
+section.frontpage a.button {
   white-space: nowrap;
-  padding: 0.7rem 1rem;
-  background-color: var(--color-camel-orange);
-  background-image: none;
-  background-repeat: no-repeat;
-  background-position: 0;
-  color: white;
-  font-weight: bold;
   margin-right: 0.5rem;
+  background-image: none;
   border-radius: 3rem;
-  outline: none;
-  display: inline-block;
-  box-shadow: 0 4px #8e480b;
+  font-weight: bold;
+  padding: 0.4rem 1rem;

Review comment:
   When exactly are you observing the overlap? I have already provided 
line-height for <1024px screens to avoid the overlap, and I can't see the 
buttons overlapping for any screen width.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Provide a modified neat card layout for community & docs
> 
>
> Key: CAMEL-15392
> URL: https://issues.apache.org/jira/browse/CAMEL-15392
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Aemie
>Priority: Major
> Attachments: Screenshot from 2020-08-18 02-49-07.png, Screenshot from 
> 2020-08-18 02-52-37.png, button-community-badges.png, 
> button-link-docs-sub-project.png, camel-core-button-card.png, 
> community-design-card.png, contributing-design-card.png
>
>
> The card layout design for the documentation and community page seemed plain 
> compared to the other pages of the website. Thus, included rounded background 
> over the links for the pages and rounded border over the section to provide 
> the card-like layout. This will fit with the new design for the front page. I 
> have created a PR regarding it with a minimal design approach however I came 
> up with a few more designs. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)