You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2021/11/10 16:28:14 UTC
[GitHub] [camel-website] djencks opened a new pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
djencks opened a new pull request #667:
URL: https://github.com/apache/camel-website/pull/667
See #666.
Website changes to:
- improve util
- update Antora to 3.0.0-beta.1 and Antora extensions to latest
- Use @djencks/aggregate-collector to avoid symlinks and copying in camel-spring-boot and camel-kafka-connector
- Use @djencks/asciidoctor-antora-indexer indexPage to generate camel-kafka-connector generated pages.
Subsidiary PRs will be listed below.
The playbook will need to be updated once those PRs are 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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
djencks commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-967161738
> On Nov 12, 2021, at 12:40 AM, Zoran Regvart ***@***.***> wrote:
>
>
> @zregvart approved this pull request.
>
> I like what this is doing, I'm a bit worried about bundling several changes that could be done independently.
> Simplest example is the change in c8d2a43 <https://github.com/apache/camel-website/commit/c8d2a43a8e27815c0cc469b60e6a800a0a906021>, that we can merge regardless of other changes in this PR.
>
I definitely could separate things into more focused sets of PRs, although it’s more work for me. For this one I was hoping having it in a separate commit would be adequate. It goes with the 2 main camel PRs: we’ll need one for 3.13.0 also I think. What happened is that Dan Allen pointed out on the Antora Zulip how to use inline anchors in table cells and I found that it dramatically speeded up the website build. Eventually I reordered the commits so this one came first.
> Or bits of the playbook change here <https://github.com/apache/camel-website/pull/667/commits/a65e06b75c0d64478bfe7a18e5aa067b1ba5ee71#diff-0e8a7c2f91f241f59cc684e048c14593122447d39c4b8bfa6953cb5e91151aa2R100-R102>.
>
oops, that was an experiment that crept in. That should be in a PR that actually lets us use the result, I’ll take it out.
> For this change <https://github.com/apache/camel-website/pull/667/commits/684fb0cb0a6237cf4366bfe1cafb7f36ee28f8b2> I think we're okay to merge it, but I think we need a discussion about issues like that to come up with a contract as to what versions of the documentation we keep around and for how long or what do we do with the content linking when we drop a version.
>
>
Absolutely. As the commit comment points out, this is a temporary solution that will definitely break.
I think that one approach would be a policy that pages should never disappear from documentation: they can get individual redirects to a new location (via page-aliases on the page at the new location) or at least some “this page doesn’t exist anymore for this reason” notification. Then links such as this problematic one can go to the no-version page and get redirected to the latest published version.
> Bits in 8f32bab (#667) <https://github.com/apache/camel-website/pull/667/commits/8f32babbbba671fc85b375443b0318f63617fce8> I'd move to support directory (personal preference, not really important).
>
>
I don’t understand what you mean, can you explain further?
> In general, and if I understand this correctly, I think this solves a problem that we have in a very good way, and should make it easier on us to maintain the documentation.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <https://github.com/apache/camel-website/pull/667#pullrequestreview-804530163>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELDXTAZPKS72JKETL5VZTULTHHFANCNFSM5HYKMJNQ>.
>
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks commented on pull request #667: partly resolves 666: Introduce aggregate collector and page generation for camel-kafka-connector
Posted by GitBox <gi...@apache.org>.
djencks commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-967772167
The spring boot PRs haven't been reviewed/approved yet so I committed the parts that have been and will open another PR to finish up.
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
djencks commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966625414
I suspect the linux-only deadlinks is an example of something in .yarn/cache that is architecture specific.
I tried running yarn install with no network access and it seems to work fine. For me it is quicker than building the Antora UI.
Something that is taking orders of magnitude more time (minutes not seconds), although on GitHub, is running —check-cache on each PR. What sequence of non-malicious actions could result in a problem detected by —check-cache?
We could investigate generating the used playbook from a template with interpolation of git location. This might also provide a way to generate a playbook for a local build: I’ll have more to say about this on the dev list soon.
> On Nov 11, 2021, at 12:18 PM, Zoran Regvart ***@***.***> wrote:
>
>
> We used to point to git repositories at ASF, not at GitHub, I can't remember why that changed, inertia I guess - it seems it was to optimize GitHub Actions <https://github.com/apache/camel-website/commit/a00742b43f3685449d9e31fda480d95279fba32e>. At some point in the past we did have an offline build, in the sense that it only used ASF infrastructure. We even built pull requests on ci-builds.a.o until we were asked not to do that because of security and capacity reasons.
>
> Note that unplugged mechanism is just a way for Yarn to deal with dependencies that don't use resolve API or a post-install script needs to modify the package. In theory a ZIP file in .yarn/cache could also contain an architecture specific binary. See unplugged package <https://yarnpkg.com/advanced/lexicon/#unplugged-package>.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <https://github.com/apache/camel-website/pull/667#issuecomment-966596588>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELDXV4GGR5XFBX4BTG7TLULQQHXANCNFSM5HYKMJNQ>.
>
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] github-actions[bot] commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-965892069
🚀 Preview is available at https://pr-667--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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] zregvart commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
zregvart commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966084940
We need to be careful about binaries in the cache, we could end up with MacOS binaries (Mach-O) in the cache instead of Linux (ELF). Best rebuild the cache within the Docker container, there is a `Dockerfile` in the root of the repository that you can use. The same is used on ci-builds.a.o. Something like this:
```
$ docker build -t camel-website .
$ docker run --rm -it -v $(pwd):/work:Z --entrypoint bash --workdir /work camel-website
$ yarn workspaces foreach install
```
The `Z` might not be required/work on a Mac, it's about SELinux labeling, and be careful about permissions on the `.yarn` directory, they might end up being owned by root.
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] github-actions[bot] commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966494611
🚀 Preview is available at https://pr-667--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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
djencks commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-965564425
Related changes:
https://github.com/apache/camel/pull/6417
https://github.com/apache/camel/pull/6418
https://github.com/apache/camel-spring-boot/pull/405
https://github.com/apache/camel-spring-boot/pull/406
The following three PRs require attention due to:
Direct modification of generated spring-boot.json: needs to be replaced by some version of 924b1d688123f0ea5052ca3b091dd3c9dfdc9759
https://github.com/apache/camel-spring-boot/pull/407
https://github.com/apache/camel-spring-boot/pull/408
https://github.com/apache/camel-spring-boot/pull/409
https://github.com/apache/camel-kafka-connector/pull/1286
https://github.com/apache/camel-kafka-connector/pull/1287
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] zregvart commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
zregvart commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-967348052
>> Bits in [8f32bab](https://github.com/apache/camel-website/commit/8f32babbbba671fc85b375443b0318f63617fce8) (#667) <[8f32bab](https://github.com/apache/camel-website/pull/667/commits/8f32babbbba671fc85b375443b0318f63617fce8)> I'd move to support directory (personal preference, not really important).
>
> I don’t understand what you mean, can you explain further?
There is a directory called [support](https://github.com/apache/camel-website/tree/main/support) where we could keep all supporting files. But like I said, it's not that important.
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
djencks commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966448315
What is your goal here? Is it that the jenkins build should be able to run without running yarn install? And anyone else (e.g. me with my mac) will probably have to run yarn install in order to build the website locally?
I think your suggestion of running yarn install isn’t sufficient since it doesn’t run dedupe: my update:dependencies script will probably be sufficient.
I ran the first two lines of your script and then yarn update:dependencies from my PR and got a lot of .yarn/unplugged changes: now running yarn build-all outside docker fails. There are no .yarn/cache changes and running yarn check:dependencies succeeds. After both operations there are a few uncommitted changes in .yarn/unplugged.
Then, restarting the docker container and running yarn check:dependencies in it succeeds and produces what looks like (git status) the same list of changed .yarn/unplugged files.
Since yarn doesn’t report errors I’m running echo $? to find the exit code.
This is the first time I’ve succeeded using docker, but I don’t think that running this locally is going to produce the desired results for anyone running on a new mac ARM based laptop.
Conceptually I think we need the GitHub PR check to generate an additional PR when running yarn check:dependencies succeeds but leaves uncommitted changes.
Alternatively perhaps the jenkins job could run yarn install —immutable —immutable-cache.
Meanwhile I’ve written a script to do this and committed the results.
> On Nov 11, 2021, at 12:22 AM, Zoran Regvart ***@***.***> wrote:
>
>
> We need to be careful about binaries in the cache, we could end up with MacOS binaries (Mach-O) in the cache instead of Linux (ELF). Best rebuild the cache within the Docker container, there is a Dockerfile in the root of the repository that you can use. The same is used on ci-builds.a.o. Something like this:
>
> $ docker build -t camel-website .
> $ docker run --rm -it -v $(pwd):/work:Z --entrypoint bash --workdir /work camel-website
> $ yarn workspaces foreach install
> The Z might not be required/work on a Mac, it's about SELinux labeling, and be careful about permissions on the .yarn directory, they might end up being owned by root.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <https://github.com/apache/camel-website/pull/667#issuecomment-966084940>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELDXX6QO2OIEWYTV76ZSDULN4MPANCNFSM5HYKMJNQ>.
>
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
djencks commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966653008
I see what you mean. Let's discuss all this further elsewhere, I'd like to find out if there are any problems with the actual intent/main content of this set of PRs and merge 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.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] github-actions[bot] commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-967764014
🚀 Preview is available at https://pr-667--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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] github-actions[bot] commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-967728492
🚀 Preview is available at https://pr-667--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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks merged pull request #667: partly resolves 666: Introduce aggregate collector and page generation for camel-kafka-connector
Posted by GitBox <gi...@apache.org>.
djencks merged pull request #667:
URL: https://github.com/apache/camel-website/pull/667
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] zregvart commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
zregvart commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966578998
> What is your goal here?
The intent is to have the most reliable and the fastest build of the website possible on ci-builds.a.o. The performance is perhaps not immediately obvious, apart from getting the changes quickly published, the limiting factor of ci-builds.a.o is that it has only a few agents available to build websites, so any job that takes up too much time prevents other projects utilizing ci-builds.a.o to build their website. If we access the network from ci-builds.a.o this endangers both the performance and reliability of the build. Caching dependencies and having a nearly offline build at ci-builds.a.o is the aspired goal. How yarn is trying to do that and the argumentation for it can be seen on [Zero-Installs](https://next.yarnpkg.com/features/zero-installs).
Docker is a Linux technology (for the most part), so when running Docker on any architecture you're running a Linux process inside a Linux (virtual) machine. I don't know if Docker has support for ARM, and if it does it might still opt to run only Docker itself as ARM and containers as x86. Container images are architecture dependent, and [node image](https://hub.docker.com/_/node) does have an ARM variant, so depending on what Docker chooses to support on the M1 Macs, whether it will run as ARM native and run ARM containers, or with whichever means (Rosetta) end up running x86 containers -- yes the cache might vary.
After writing that I went to the Docker website and found [this](https://docs.docker.com/desktop/mac/apple-silicon/), which says that the Apple Silicon version of Docker Desktop can run both ARM and x86 containers. x86 containers can be run using `--platform linux/amd64` parameter.
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
djencks commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-965575820
The camel-kafka-connector PRs need a little more attention. The json files contain duplicate information: enum values are listed as json elements and also rendered into the description. The util description renderer uses the json elements to render a list of enum values. Therefore I would like to remove the hardcoded rendering into the json description.
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] djencks commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
djencks commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966591001
By its nature, the Antora build has to have major network access to GitHub to get the content.
I can’t really tell, but it looks like rebuilding unplugged for a different architecture doesn’t use any or significant network access. Certainly the rebuild time is unnoticeable compared to the Antora build time.
Having the caches set up properly seems like a really good thing to me, but making the unplugged stuff need to be linux x86 seems to me to be more complex than it’s worth. However, the scripts I came up with make it possible for me to set this up before commit, at the cost of having a really big problem dealing with the .yarn/unplugged during local development. I don’t think running a local build in docker is practical, both because of the OOM errors I’m experiencing (see zulip) and because I can’t access the local checkouts. It might be possible to fix these but I think requiring a local build to be done in docker is a ridiculous constraint.
So, I’m willing to deal with the complexity of the .yarn/unplugged but just barely and under protest. I really don’t think it’s worth it.
> On Nov 11, 2021, at 11:49 AM, Zoran Regvart ***@***.***> wrote:
>
>
> What is your goal here?
>
> The intent is to have the most reliable and the fastest build of the website possible on ci-builds.a.o. The performance is perhaps not immediately obvious, apart from getting the changes quickly published, the limiting factor of ci-builds.a.o is that it has only a few agents available to build websites, so any job that takes up too much time prevents other projects utilizing ci-builds.a.o to build their website. If we access the network from ci-builds.a.o this endangers both the performance and reliability of the build. Caching dependencies and having a nearly offline build at ci-builds.a.o is the aspired goal. How yarn is trying to do that and the argumentation for it can be seen on Zero-Installs <https://next.yarnpkg.com/features/zero-installs>.
>
> Docker is a Linux technology (for the most part), so when running Docker on any architecture you're running a Linux process inside a Linux (virtual) machine. I don't know if Docker has support for ARM, and if it does it might still opt to run only Docker itself as ARM and containers as x86. Container images are architecture dependent, and node image <https://hub.docker.com/_/node> does have an ARM variant, so depending on what Docker chooses to support on the M1 Macs, whether it will run as ARM native and run ARM containers, or with whichever means (Rosetta) end up running x86 containers -- yes the cache might vary.
>
> After writing that I went to the Docker website and found this <https://docs.docker.com/desktop/mac/apple-silicon/>, which says that the Apple Silicon version of Docker Desktop can run both ARM and x86 containers. x86 containers can be run using --platform linux/amd64 parameter.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <https://github.com/apache/camel-website/pull/667#issuecomment-966578998>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELDXTD36KIR6KBWISIDWLULQM4RANCNFSM5HYKMJNQ>.
>
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] zregvart commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
zregvart commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966596588
We used to point to git repositories at ASF, not at GitHub, I can't remember why that changed, ~~inertia I guess~~ - it seems it was to [optimize GitHub Actions](https://github.com/apache/camel-website/commit/a00742b43f3685449d9e31fda480d95279fba32e). At some point in the past we did have an offline build, in the sense that it only used ASF infrastructure. We even built pull requests on ci-builds.a.o until we were asked not to do that because of security and capacity reasons.
Note that unplugged mechanism is just a way for Yarn to deal with dependencies that don't use `resolve` API or a post-install script needs to modify the package. In theory a ZIP file in .yarn/cache could also contain an architecture specific binary. See [unplugged package](https://yarnpkg.com/advanced/lexicon/#unplugged-package).
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-website] zregvart commented on pull request #667: Resolves #666: (Do not merge yet) Main aggregate collector/page generation
Posted by GitBox <gi...@apache.org>.
zregvart commented on pull request #667:
URL: https://github.com/apache/camel-website/pull/667#issuecomment-966630957
> What sequence of non-malicious actions could result in a problem detected by —check-cache?
Malicious ones are the ones I'm worried about, see the note in the last example [here](https://yarnpkg.com/cli/install#usage). I'd like to prevent running a tampered dependency on ci-builds.a.o.
--
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-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org