Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
On Fri, Jul 26, 2019 at 5:22 AM Willem Jiang wrote: > > +1 for the upgrading the component name. > Here are my quick question about the documentation. There may be some > changes between Camel 3 and Camel 2. > How can we warning the user the name is changed? > In the migration guide where we have all those details > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Jul 25, 2019 at 6:34 PM Claus Ibsen wrote: > > > > On Thu, Jul 25, 2019 at 12:24 PM Tadayoshi Sato > > wrote: > > > > > > +1 > > > > > > Maybe it's also good time to review other components that have similar > > > variants. > > > > > > > Yeah we have > > > > - camel-quartz2 > > - camel-netty4 > > - camel-netty4-http > > - camel-mongodb3 > > - camel-mina2 > > - camel-hdfs2 > > - camel-rxjava2 > > - camel-sjms2 > > > > > > > > > On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger > > > wrote: > > > > > > > +1 > > > > > > > > On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > > > > > claus.ib...@gmail.com> > > > > > ha scritto: > > > > > > > > > > > Hi > > > > > > > > > > > > So what has been bothering Camel 2.x users is that when they use > > > > > > http > > > > > > they would likely use the camel-http4 component and then they should > > > > > > use http4 as the component name. The old camel-http component is > > > > > > deprecated as the http client it uses is EOL for many many years. > > > > > > > > > > > > So with Camel 3 on the way we have deleted the old camel-http > > > > > > component and the camel-http4 component now has both http and http4 > > > > > > as > > > > > > component names. > > > > > > > > > > > > I think we should rename the camel-http4 back to camel-http and then > > > > > > favour using http as the component name, and then deprecate http4 > > > > > > (or > > > > > > even remove it). > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > > > > > > > -- > > > > > > Claus Ibsen > > > > > > - > > > > > > http://davsclaus.com @davsclaus > > > > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > > > > > > > > > > > > > > > -- > > Claus Ibsen > > - > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 for the upgrading the component name. Here are my quick question about the documentation. There may be some changes between Camel 3 and Camel 2. How can we warning the user the name is changed? Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Jul 25, 2019 at 6:34 PM Claus Ibsen wrote: > > On Thu, Jul 25, 2019 at 12:24 PM Tadayoshi Sato > wrote: > > > > +1 > > > > Maybe it's also good time to review other components that have similar > > variants. > > > > Yeah we have > > - camel-quartz2 > - camel-netty4 > - camel-netty4-http > - camel-mongodb3 > - camel-mina2 > - camel-hdfs2 > - camel-rxjava2 > - camel-sjms2 > > > > > On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger > > wrote: > > > > > +1 > > > > > > On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino > > > wrote: > > > > > > > +1 > > > > > > > > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > > > > claus.ib...@gmail.com> > > > > ha scritto: > > > > > > > > > Hi > > > > > > > > > > So what has been bothering Camel 2.x users is that when they use http > > > > > they would likely use the camel-http4 component and then they should > > > > > use http4 as the component name. The old camel-http component is > > > > > deprecated as the http client it uses is EOL for many many years. > > > > > > > > > > So with Camel 3 on the way we have deleted the old camel-http > > > > > component and the camel-http4 component now has both http and http4 as > > > > > component names. > > > > > > > > > > I think we should rename the camel-http4 back to camel-http and then > > > > > favour using http as the component name, and then deprecate http4 (or > > > > > even remove it). > > > > > > > > > > Any thoughts? > > > > > > > > > > > > > > > -- > > > > > Claus Ibsen > > > > > - > > > > > http://davsclaus.com @davsclaus > > > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > > > > > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
[GitHub] [camel-website] Nayananga opened a new pull request #62: microdata added about twitter account and few more additional details
Nayananga opened a new pull request #62: microdata added about twitter account and few more additional details URL: https://github.com/apache/camel-website/pull/62 I added a twitter account link and a little description about the camel from google search. please let me know if there any correction needed. 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 With regards, Apache Git Services
Release Apache Camel K 1.0.0-M1 and Runtime 1.0.0
Hello all: This is a combined vote to release Apache Camel K 1.0.0-M1 and Apache Camel K Runtime 1.0.0. Apache Camel K Runtime versions follow a different convention (without milestones) and won't necessarily match main Camel K versions in the future. Runtime staging repository: https://repository.apache.org/content/repositories/orgapachecamel-1145 Runtime Tag: https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-parent-1.0.0 Camel K staging repository: https://dist.apache.org/repos/dist/dev/camel/camel-k/1.0.0-M1/ Camel K Tag: https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/1.0.0-M1 Staging container image repository: https://hub.docker.com/r/camelk/camel-k/tags It's possible to install all staging artifacts with a single command: kamel install --operator-image=camelk/camel-k:1.0.0-M1 --maven-repository= https://repository.apache.org/content/repositories/orgapachecamel-1145 Please test this release candidate and cast your vote. [ ] +1 Release the binary as Apache Camel K 1.0.0-M1 and Apache Camel K Runtime 1.0.0 [ ] -1 Veto the release (provide specific comments) The vote is open for at least 72 hours. Thanks, Nicola Ferraro
[GitHub] [camel-website] zregvart merged pull request #61: antora footer edited
zregvart merged pull request #61: antora footer edited URL: https://github.com/apache/camel-website/pull/61 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 With regards, Apache Git Services
[GitHub] [camel-website] Nayananga opened a new pull request #61: antora footer edited
Nayananga opened a new pull request #61: antora footer edited URL: https://github.com/apache/camel-website/pull/61 I added camel hugo footer into antora camel theme footer 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 With regards, Apache Git Services
Re: [DISCUSS] Meta model
Le jeu. 25 juil. 2019 à 20:28, Zoran Regvart a écrit : > Hi Guillaume, > since we're all piling up on you :) One more thing I'd like you to > consider :) > > I find Velocity templates a bit brittle and hard to maintain, would > you consider a Java code generator to create the Java source code? > Lol ! I usually find those harder to use for the use cases we have and when you want tight control over the written code. I'd rather move all the smart things into a helper class and keep velocity with almost only simple iterations on variables. You can compare the code used to generate the endpoint DSL: https://github.com/apache/camel/blob/master/tooling/maven/camel-package-maven-plugin/src/main/java/org/apache/camel/maven/packaging/EndpointDslMojo.java https://github.com/gnodet/camel/blob/model/core/camel-core/src/generator/resources/endpoint.vm If you really want the main executed code to be java, I'd rather use a simple java writer rather than a java code generator. That may be because of the way I'm working, but I usually work with the generated source code when I need to change something it, and when I'm happy, I'm changing the generator to reflect those changes, and this is usually way easier when you're working on a template which actually looks like the output. > > I've found JavaPoet[1] pretty nifty in this regard. I've used it for > the OpenAPI to Rest DSL code generator we have[2]. > > Thanks :) > > zoran > > [1] https://github.com/square/javapoet > [2] > https://github.com/apache/camel/tree/master/tooling/swagger-rest-dsl-generator/src/main/java/org/apache/camel/generator/swagger > > On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet wrote: > > > > Hey everyone ! > > > > The last weeks, I've spend quite some time working on a camel metamodel. > > The idea is to invert the way things are built in camel so instead of > > generating the metamodel from the classes, the metamodel would be > > maintained manually and used to generate a bunch of things. > > > > This would bring the following benefits: > > - the metamodel would necessarily be up to date > > - generate the model classes (XyzDefinition classes) with an > homogeneous > > fluent api (similar to the new endpoint DSL) > > - get rid of some round tripping between java -> json -> java, copying > > json files everywhere , so great simplification of the build process > > - the DSL allows type-safe + property placeholders / references > everywhere > > - generate xml readers / parsers without relying on JAXB > > - brings extensibility of the DSL as it would be much easier to create > > DSLs based on other languages from the metamodel (yaml for example) > > > > I've pushed a branch that shows my experiments. It's not fully working > > yet, but it gives a good idea. It's available at > > https://github.com/gnodet/camel/tree/model > > I'm progressing a bit slowly as there are lots of step by step > adjustements > > to do in order to keep compatibility of the DSL. > > > > Currently the model is generated from the json files, but the idea is to > > reverse this process and have the metamodel the real primary input for > all > > generation. > > The model currently looks like: > > https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 > > > > The current JAXB model will need to be moved into a separate module so > that > > it can be kept for compatibility without interfering with the new > generated > > java DSL. > > > > So, still quite some work left, but I wanted to bring it to the community > > sooner rather than later, especially before I go on PTO for a few weeks > > where I'll be mostly offline. > > Happy to discuss anything or provide more infos. > > > > Cheers, > > Guillaume Nodet > > > > -- > Zoran Regvart > -- Guillaume Nodet
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 Regards JB Le 25 juil. 2019 à 20:31, à 20:31, Zoran Regvart a écrit: >+1 I'm so delighted that we'll consider/are doing this :) I do think >that Camel as a framework should take on the responsibility to hide >these details from the user, user wants to invoke HTTP endpoints, the >user doesn't care which version of HTTP Components/Netty/Jetty... is >under the hood. > >zoran > >On Thu, Jul 25, 2019 at 11:48 AM Claus Ibsen >wrote: >> >> Hi >> >> So what has been bothering Camel 2.x users is that when they use http >> they would likely use the camel-http4 component and then they should >> use http4 as the component name. The old camel-http component is >> deprecated as the http client it uses is EOL for many many years. >> >> So with Camel 3 on the way we have deleted the old camel-http >> component and the camel-http4 component now has both http and http4 >as >> component names. >> >> I think we should rename the camel-http4 back to camel-http and then >> favour using http as the component name, and then deprecate http4 (or >> even remove it). >> >> Any thoughts? >> >> >> -- >> Claus Ibsen >> - >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 > > > >-- >Zoran Regvart
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 Thanks! － Freeman(Yue) Fang Red Hat, Inc. > On Jul 25, 2019, at 5:48 AM, Claus Ibsen wrote: > > Hi > > So what has been bothering Camel 2.x users is that when they use http > they would likely use the camel-http4 component and then they should > use http4 as the component name. The old camel-http component is > deprecated as the http client it uses is EOL for many many years. > > So with Camel 3 on the way we have deleted the old camel-http > component and the camel-http4 component now has both http and http4 as > component names. > > I think we should rename the camel-http4 back to camel-http and then > favour using http as the component name, and then deprecate http4 (or > even remove it). > > Any thoughts? > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] Meta model
Hi Model driven makes sense. I like velocity but I understand Zoran's comment. Maybe we can imagine some pluggable: pojo describing model and binding. Regards JB Le 25 juil. 2019 à 20:28, à 20:28, Zoran Regvart a écrit: >Hi Guillaume, >since we're all piling up on you :) One more thing I'd like you to >consider :) > >I find Velocity templates a bit brittle and hard to maintain, would >you consider a Java code generator to create the Java source code? > >I've found JavaPoet[1] pretty nifty in this regard. I've used it for >the OpenAPI to Rest DSL code generator we have[2]. > >Thanks :) > >zoran > >[1] https://github.com/square/javapoet >[2] >https://github.com/apache/camel/tree/master/tooling/swagger-rest-dsl-generator/src/main/java/org/apache/camel/generator/swagger > >On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet >wrote: >> >> Hey everyone ! >> >> The last weeks, I've spend quite some time working on a camel >metamodel. >> The idea is to invert the way things are built in camel so instead of >> generating the metamodel from the classes, the metamodel would be >> maintained manually and used to generate a bunch of things. >> >> This would bring the following benefits: >> - the metamodel would necessarily be up to date >> - generate the model classes (XyzDefinition classes) with an >homogeneous >> fluent api (similar to the new endpoint DSL) >> - get rid of some round tripping between java -> json -> java, >copying >> json files everywhere , so great simplification of the build process >> - the DSL allows type-safe + property placeholders / references >everywhere >> - generate xml readers / parsers without relying on JAXB >> - brings extensibility of the DSL as it would be much easier to >create >> DSLs based on other languages from the metamodel (yaml for example) >> >> I've pushed a branch that shows my experiments. It's not fully >working >> yet, but it gives a good idea. It's available at >> https://github.com/gnodet/camel/tree/model >> I'm progressing a bit slowly as there are lots of step by step >adjustements >> to do in order to keep compatibility of the DSL. >> >> Currently the model is generated from the json files, but the idea is >to >> reverse this process and have the metamodel the real primary input >for all >> generation. >> The model currently looks like: >> https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 >> >> The current JAXB model will need to be moved into a separate module >so that >> it can be kept for compatibility without interfering with the new >generated >> java DSL. >> >> So, still quite some work left, but I wanted to bring it to the >community >> sooner rather than later, especially before I go on PTO for a few >weeks >> where I'll be mostly offline. >> Happy to discuss anything or provide more infos. >> >> Cheers, >> Guillaume Nodet > > > >-- >Zoran Regvart
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 I'm so delighted that we'll consider/are doing this :) I do think that Camel as a framework should take on the responsibility to hide these details from the user, user wants to invoke HTTP endpoints, the user doesn't care which version of HTTP Components/Netty/Jetty... is under the hood. zoran On Thu, Jul 25, 2019 at 11:48 AM Claus Ibsen wrote: > > Hi > > So what has been bothering Camel 2.x users is that when they use http > they would likely use the camel-http4 component and then they should > use http4 as the component name. The old camel-http component is > deprecated as the http client it uses is EOL for many many years. > > So with Camel 3 on the way we have deleted the old camel-http > component and the camel-http4 component now has both http and http4 as > component names. > > I think we should rename the camel-http4 back to camel-http and then > favour using http as the component name, and then deprecate http4 (or > even remove it). > > Any thoughts? > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Zoran Regvart
Re: [DISCUSS] Meta model
Hi Guillaume, since we're all piling up on you :) One more thing I'd like you to consider :) I find Velocity templates a bit brittle and hard to maintain, would you consider a Java code generator to create the Java source code? I've found JavaPoet[1] pretty nifty in this regard. I've used it for the OpenAPI to Rest DSL code generator we have[2]. Thanks :) zoran [1] https://github.com/square/javapoet [2] https://github.com/apache/camel/tree/master/tooling/swagger-rest-dsl-generator/src/main/java/org/apache/camel/generator/swagger On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet wrote: > > Hey everyone ! > > The last weeks, I've spend quite some time working on a camel metamodel. > The idea is to invert the way things are built in camel so instead of > generating the metamodel from the classes, the metamodel would be > maintained manually and used to generate a bunch of things. > > This would bring the following benefits: > - the metamodel would necessarily be up to date > - generate the model classes (XyzDefinition classes) with an homogeneous > fluent api (similar to the new endpoint DSL) > - get rid of some round tripping between java -> json -> java, copying > json files everywhere , so great simplification of the build process > - the DSL allows type-safe + property placeholders / references everywhere > - generate xml readers / parsers without relying on JAXB > - brings extensibility of the DSL as it would be much easier to create > DSLs based on other languages from the metamodel (yaml for example) > > I've pushed a branch that shows my experiments. It's not fully working > yet, but it gives a good idea. It's available at > https://github.com/gnodet/camel/tree/model > I'm progressing a bit slowly as there are lots of step by step adjustements > to do in order to keep compatibility of the DSL. > > Currently the model is generated from the json files, but the idea is to > reverse this process and have the metamodel the real primary input for all > generation. > The model currently looks like: > https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 > > The current JAXB model will need to be moved into a separate module so that > it can be kept for compatibility without interfering with the new generated > java DSL. > > So, still quite some work left, but I wanted to bring it to the community > sooner rather than later, especially before I go on PTO for a few weeks > where I'll be mostly offline. > Happy to discuss anything or provide more infos. > > Cheers, > Guillaume Nodet -- Zoran Regvart
[GitHub] [camel-website] Nayananga opened a new pull request #60: added microdata to antora footer.hbs
Nayananga opened a new pull request #60: added microdata to antora footer.hbs URL: https://github.com/apache/camel-website/pull/60 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 With regards, Apache Git Services
[GitHub] [camel-website] zregvart merged pull request #60: added microdata to antora footer.hbs
zregvart merged pull request #60: added microdata to antora footer.hbs URL: https://github.com/apache/camel-website/pull/60 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] asf-ci commented on issue #95: Omit the artifactId in release tags
asf-ci commented on issue #95: Omit the artifactId in release tags URL: https://github.com/apache/camel-quarkus/pull/95#issuecomment-515062507 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/camel-quarkus-pr/49/ 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] lburgazzoli merged pull request #77: Move test packages to org.apache.camel
lburgazzoli merged pull request #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] ppalaga commented on issue #96: Make CamelRuntime smart to decide deferInitPhase
ppalaga commented on issue #96: Make CamelRuntime smart to decide deferInitPhase URL: https://github.com/apache/camel-quarkus/issues/96#issuecomment-515052957 @gnodet noted in a call that this is not going to get resolved with Camel 3.0.0. We agreed to keep using the manual `deferInitPhase` in the mean time, eventually switching its default to `true` because it more likely to give what the users expect. 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] ppalaga opened a new issue #96: Make CamelRuntime smart to decide deferInitPhase
ppalaga opened a new issue #96: Make CamelRuntime smart to decide deferInitPhase
URL: https://github.com/apache/camel-quarkus/issues/96
Currently, `deferInitPhase` true or false needs to be decided by the
application developer depending on whether she wants to pass different config
values to the app at runtime. However, the CamelRuntime could potentially be
made smart enough to decide based on the available config values. E.g.
`{{env:AWS_ACCESS_KEY}}` is a clear indicator of a runtime value.
cc @gnodet
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
With regards,
Apache Git Services
[GitHub] [camel-quarkus] asf-ci commented on issue #77: Move test packages to org.apache.camel
asf-ci commented on issue #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#issuecomment-515039994 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/camel-quarkus-pr/48/ 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 With regards, Apache Git Services
[GitHub] [camel-k] oscerd merged pull request #879: Fix make clean for tests and remove binary file from repo
oscerd merged pull request #879: Fix make clean for tests and remove binary file from repo URL: https://github.com/apache/camel-k/pull/879 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] oscerd merged pull request #94: Fix typo s/AWs_REGION/AWS_REGION/
oscerd merged pull request #94: Fix typo s/AWs_REGION/AWS_REGION/ URL: https://github.com/apache/camel-quarkus/pull/94 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] oscerd commented on issue #94: Fix typo s/AWs_REGION/AWS_REGION/
oscerd commented on issue #94: Fix typo s/AWs_REGION/AWS_REGION/ URL: https://github.com/apache/camel-quarkus/pull/94#issuecomment-515028672 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] lburgazzoli commented on issue #77: Move test packages to org.apache.camel
lburgazzoli commented on issue #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#issuecomment-515028570 @ppalaga 0.20.0 is expected to be released in 5 days (week-end included) and after that release the snapshot profile won't be active by default as already stated above. We need to be sure the code compile against the latest quarkus bits to avoid last minute bugs that would delay a first official release even further. Unfortunately srcdeps stick with a specific commit and won't give us an option to spot such problems. 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] ppalaga opened a new pull request #95: Omit the artifactId in release tags
ppalaga opened a new pull request #95: Omit the artifactId in release tags URL: https://github.com/apache/camel-quarkus/pull/95 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] ppalaga commented on issue #77: Move test packages to org.apache.camel
ppalaga commented on issue #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#issuecomment-515025458 > added snapshot profile active by default for the moment as there were some changes in quarkus like moving to GraalVM 19.1.1 that have introduced some regressions, will disable this profile after quarkus 0.20.0 If there is any chance to re-think this proposal for the sake of build reproducibility and portability please consider using srcdeps instead of Maven SNAPSHOTs. I have sent a PR against your branch: https://github.com/lburgazzoli/apache-camel-quarkus/pull/1 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] lburgazzoli commented on a change in pull request #77: Move test packages to org.apache.camel
lburgazzoli commented on a change in pull request #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#discussion_r307270283 ## File path: integration-tests/aws/src/main/java/org/apache/camel/quarkus/component/aws/CamelRoute.java ## @@ -14,7 +14,7 @@ * See the License for the specific language governing permissions and * limitations under the License. */ -package io.quarkus.it.camel.aws; +package org.apache.camel.quarkus.component.aws; Review comment: That's partially true as we do not have any unit test for the native image side of things 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 With regards, Apache Git Services
[GitHub] [camel-k] dmvolod opened a new pull request #879: Fix make clean for tests and remove binary file from repo
dmvolod opened a new pull request #879: Fix make clean for tests and remove binary file from repo URL: https://github.com/apache/camel-k/pull/879 @nicolaferraro , i will wounder, if testing binary file in repo requires for some reasons 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] ppalaga commented on a change in pull request #77: Move test packages to org.apache.camel
ppalaga commented on a change in pull request #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#discussion_r307269097 ## File path: integration-tests/aws/src/main/java/org/apache/camel/quarkus/component/aws/CamelRoute.java ## @@ -14,7 +14,7 @@ * See the License for the specific language governing permissions and * limitations under the License. */ -package io.quarkus.it.camel.aws; +package org.apache.camel.quarkus.component.aws; Review comment: > be able to access package private methods/classes for testing purpose Yes, that's normal and OK for unit tests. OTOH integration tests should simulate how our end users use camel quarkus. We should not assume that they access non-public APIs. 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] lburgazzoli commented on a change in pull request #77: Move test packages to org.apache.camel
lburgazzoli commented on a change in pull request #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#discussion_r307265972 ## File path: integration-tests/aws/src/main/java/org/apache/camel/quarkus/component/aws/CamelRoute.java ## @@ -14,7 +14,7 @@ * See the License for the specific language governing permissions and * limitations under the License. */ -package io.quarkus.it.camel.aws; +package org.apache.camel.quarkus.component.aws; Review comment: The reason I do usually keep the same name is to be able to access package private methods/classes for testing purpose, I can change it but I propose to do it later 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] asf-ci commented on issue #94: Fix typo s/AWs_REGION/AWS_REGION/
asf-ci commented on issue #94: Fix typo s/AWs_REGION/AWS_REGION/ URL: https://github.com/apache/camel-quarkus/pull/94#issuecomment-515020645 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/camel-quarkus-pr/47/ 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 With regards, Apache Git Services
Re: [DISCUSS] Meta model
Couple of questions: - how does this play with external components ? - what about annotations we have now i.e. for endpoints ? I found particularity useful that types, enum values and so one are taken from the java code --- Luca Burgazzoli On Thu, Jul 25, 2019 at 12:04 PM Claus Ibsen wrote: > Hi > > Btw a follow up question. > > Would we be able to get to a point where all the model classes > (xxxDefinition and helpers etc) can be dropped at runtime, eg for > camel-quarkus optimization? > And also the refiers as they are the builder from model -> processor. > > Well what you experiment with is surely a great step in that direction too. > > > > On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet wrote: > > > > Hey everyone ! > > > > The last weeks, I've spend quite some time working on a camel metamodel. > > The idea is to invert the way things are built in camel so instead of > > generating the metamodel from the classes, the metamodel would be > > maintained manually and used to generate a bunch of things. > > > > This would bring the following benefits: > > - the metamodel would necessarily be up to date > > - generate the model classes (XyzDefinition classes) with an > homogeneous > > fluent api (similar to the new endpoint DSL) > > - get rid of some round tripping between java -> json -> java, copying > > json files everywhere , so great simplification of the build process > > - the DSL allows type-safe + property placeholders / references > everywhere > > - generate xml readers / parsers without relying on JAXB > > - brings extensibility of the DSL as it would be much easier to create > > DSLs based on other languages from the metamodel (yaml for example) > > > > I've pushed a branch that shows my experiments. It's not fully working > > yet, but it gives a good idea. It's available at > > https://github.com/gnodet/camel/tree/model > > I'm progressing a bit slowly as there are lots of step by step > adjustements > > to do in order to keep compatibility of the DSL. > > > > Currently the model is generated from the json files, but the idea is to > > reverse this process and have the metamodel the real primary input for > all > > generation. > > The model currently looks like: > > https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 > > > > The current JAXB model will need to be moved into a separate module so > that > > it can be kept for compatibility without interfering with the new > generated > > java DSL. > > > > So, still quite some work left, but I wanted to bring it to the community > > sooner rather than later, especially before I go on PTO for a few weeks > > where I'll be mostly offline. > > Happy to discuss anything or provide more infos. > > > > Cheers, > > Guillaume Nodet > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 --- Luca Burgazzoli On Thu, Jul 25, 2019 at 1:58 PM Francois Papon wrote: > Agree, it make sense! > > regards, > > François > fpa...@apache.org > > Le 25/07/2019 à 12:23, Tadayoshi Sato a écrit : > > +1 > > > > Maybe it's also good time to review other components that have similar > > variants. > > > > On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger > > wrote: > > > >> +1 > >> > >> On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino > >> wrote: > >> > >>> +1 > >>> > >>> Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > >>> claus.ib...@gmail.com> > >>> ha scritto: > >>> > Hi > > So what has been bothering Camel 2.x users is that when they use http > they would likely use the camel-http4 component and then they should > use http4 as the component name. The old camel-http component is > deprecated as the http client it uses is EOL for many many years. > > So with Camel 3 on the way we have deleted the old camel-http > component and the camel-http4 component now has both http and http4 as > component names. > > I think we should rename the camel-http4 back to camel-http and then > favour using http as the component name, and then deprecate http4 (or > even remove it). > > Any thoughts? > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > >
[GitHub] [camel-quarkus] ppalaga commented on a change in pull request #77: Move test packages to org.apache.camel
ppalaga commented on a change in pull request #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#discussion_r307258925 ## File path: integration-tests/aws/src/main/java/org/apache/camel/quarkus/component/aws/CamelRoute.java ## @@ -14,7 +14,7 @@ * See the License for the specific language governing permissions and * limitations under the License. */ -package io.quarkus.it.camel.aws; +package org.apache.camel.quarkus.component.aws; Review comment: I vote for keeping `it` somewhere in the integration test package names. `org.apache.camel.quarkus.component.aws.it` or `org.apache.camel.quarkus.it.component.aws` or some other variant. This is to avoid any potential naming clashes with the the platform code. 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 With regards, Apache Git Services
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
Agree, it make sense! regards, François fpa...@apache.org Le 25/07/2019 à 12:23, Tadayoshi Sato a écrit : > +1 > > Maybe it's also good time to review other components that have similar > variants. > > On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger > wrote: > >> +1 >> >> On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino >> wrote: >> >>> +1 >>> >>> Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < >>> claus.ib...@gmail.com> >>> ha scritto: >>> Hi So what has been bothering Camel 2.x users is that when they use http they would likely use the camel-http4 component and then they should use http4 as the component name. The old camel-http component is deprecated as the http client it uses is EOL for many many years. So with Camel 3 on the way we have deleted the old camel-http component and the camel-http4 component now has both http and http4 as component names. I think we should rename the camel-http4 back to camel-http and then favour using http as the component name, and then deprecate http4 (or even remove it). Any thoughts? -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
[GitHub] [camel-k] dmvolod commented on issue #863: operator-sdk build fails on latest master with 'make images-dev'
dmvolod commented on issue #863: operator-sdk build fails on latest master with 'make images-dev' URL: https://github.com/apache/camel-k/issues/863#issuecomment-515014867 https://github.com/operator-framework/operator-sdk/issues/1738 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 With regards, Apache Git Services
Re: [VOTE] Release Apache Camel Quarkus 0.0.2
Here the correct staging repository: https://repository.apache.org/content/repositories/orgapachecamel-1144/ -- Andrea Cosentino -- Apache Camel PMC Chair Apache Karaf Committer Apache Servicemix PMC Member Email: ancosen1...@yahoo.com Twitter: @oscerd2 Github: oscerd On Thursday, July 25, 2019, 1:54:29 PM GMT+2, Andrea Cosentino wrote: Hello all: This is a vote to release Apache Camel Quarkus 0.0.2 This is the first release of the camel-quarkus project which contains the first extensions for running Camel on Quarkus. Staging repository: Index of /repositories/orgapachecamel-1144 Tag: https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=refs/tags/camel-quarkus-parent-0.0.2 Source release package: https://repository.apache.org/content/repositories/orgapachecamel-1144/org/apache/camel/quarkus/camel-quarkus-parent/0.0.2/camel-quarkus-parent-0.0.2-source-release.zip Please test this release candidate and cast your vote. [ ] +1 Release the binary as Apache Camel Quarkus 0.0.2 [ ] -1 Veto the release (provide specific comments) The vote is open for at least 72 hours. Thanks, Andrea P.S: The 0.0.1 release failed, so instead of rollback everything, since we are at early stage, we released 0.0.2 as first release.
[VOTE] Release Apache Camel Quarkus 0.0.2
Hello all: This is a vote to release Apache Camel Quarkus 0.0.2 This is the first release of the camel-quarkus project which contains the first extensions for running Camel on Quarkus. Staging repository: Index of /repositories/orgapachecamel-1144 Tag: https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=refs/tags/camel-quarkus-parent-0.0.2 Source release package: https://repository.apache.org/content/repositories/orgapachecamel-1144/org/apache/camel/quarkus/camel-quarkus-parent/0.0.2/camel-quarkus-parent-0.0.2-source-release.zip Please test this release candidate and cast your vote. [ ] +1 Release the binary as Apache Camel Quarkus 0.0.2 [ ] -1 Veto the release (provide specific comments) The vote is open for at least 72 hours. Thanks, Andrea P.S: The 0.0.1 release failed, so instead of rollback everything, since we are at early stage, we released 0.0.2 as first release.
[GitHub] [camel-k] ipolyzos commented on issue #869: make images fail on resolve of camel-k-maven-plugin
ipolyzos commented on issue #869: make images fail on resolve of camel-k-maven-plugin URL: https://github.com/apache/camel-k/issues/869#issuecomment-515006116 I can confirm that this issue is not present in a fresh copy. Please see the log below: > > ---> e17c53f10082 > Step 6/7 : ADD build/_output/bin/camel-k /usr/local/bin/camel-k > ---> fbae7e310acf > Step 7/7 : ADD build/_output/bin/builder /usr/local/bin/camel-k-builder > ---> b89050cbfaa8 > Successfully built b89050cbfaa8 > Successfully tagged apache/camel-k:1.0.0-M1-SNAPSHOT > INFO[0021] Operator build complete. @dmvolod 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 With regards, Apache Git Services
[GitHub] [camel-k] ipolyzos closed issue #869: make images fail on resolve of camel-k-maven-plugin
ipolyzos closed issue #869: make images fail on resolve of camel-k-maven-plugin URL: https://github.com/apache/camel-k/issues/869 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] ppalaga opened a new pull request #94: Fix typo s/AWs_REGION/AWS_REGION/
ppalaga opened a new pull request #94: Fix typo s/AWs_REGION/AWS_REGION/ URL: https://github.com/apache/camel-quarkus/pull/94 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 With regards, Apache Git Services
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
I logged a ticket to rename the other components, then we have a clean start for Camel 3 https://issues.apache.org/jira/browse/CAMEL-13792 On Thu, Jul 25, 2019 at 12:33 PM Claus Ibsen wrote: > > On Thu, Jul 25, 2019 at 12:24 PM Tadayoshi Sato > wrote: > > > > +1 > > > > Maybe it's also good time to review other components that have similar > > variants. > > > > Yeah we have > > - camel-quartz2 > - camel-netty4 > - camel-netty4-http > - camel-mongodb3 > - camel-mina2 > - camel-hdfs2 > - camel-rxjava2 > - camel-sjms2 > > > > > On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger > > wrote: > > > > > +1 > > > > > > On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino > > > wrote: > > > > > > > +1 > > > > > > > > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > > > > claus.ib...@gmail.com> > > > > ha scritto: > > > > > > > > > Hi > > > > > > > > > > So what has been bothering Camel 2.x users is that when they use http > > > > > they would likely use the camel-http4 component and then they should > > > > > use http4 as the component name. The old camel-http component is > > > > > deprecated as the http client it uses is EOL for many many years. > > > > > > > > > > So with Camel 3 on the way we have deleted the old camel-http > > > > > component and the camel-http4 component now has both http and http4 as > > > > > component names. > > > > > > > > > > I think we should rename the camel-http4 back to camel-http and then > > > > > favour using http as the component name, and then deprecate http4 (or > > > > > even remove it). > > > > > > > > > > Any thoughts? > > > > > > > > > > > > > > > -- > > > > > Claus Ibsen > > > > > - > > > > > http://davsclaus.com @davsclaus > > > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > > > > > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
[GitHub] [camel-k] nicolaferraro opened a new issue #878: Release Camel K 1.0.0 M1 and related Camel K Runtime
nicolaferraro opened a new issue #878: Release Camel K 1.0.0 M1 and related Camel K Runtime URL: https://github.com/apache/camel-k/issues/878 Release notes: - tbd 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] asf-ci commented on issue #93: Added failIfNoTest option in surefire configuration
asf-ci commented on issue #93: Added failIfNoTest option in surefire configuration URL: https://github.com/apache/camel-quarkus/pull/93#issuecomment-514997528 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/camel-quarkus-pr/46/ 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 With regards, Apache Git Services
[GitHub] [camel-k] ipolyzos edited a comment on issue #869: make images fail on resolve of camel-k-maven-plugin
ipolyzos edited a comment on issue #869: make images fail on resolve of camel-k-maven-plugin URL: https://github.com/apache/camel-k/issues/869#issuecomment-514993933 $ operator-sdk version git:(master|… operator-sdk version: v0.9.0, commit: 560208dc998de497bbf59fea1b63426aec430934 $ git pull Already up to date. 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 With regards, Apache Git Services
[GitHub] [camel-k] ipolyzos commented on issue #869: make images fail on resolve of camel-k-maven-plugin
ipolyzos commented on issue #869: make images fail on resolve of camel-k-maven-plugin URL: https://github.com/apache/camel-k/issues/869#issuecomment-514993933 $ operator-sdk version git:(master|… operator-sdk version: v0.9.0, commit: 560208dc998de497bbf59fea1b63426aec430934 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 With regards, Apache Git Services
Re: [HEADS UP] - Message API - deprecate OUT
Hi I am starting to work on this and will send a PR On Wed, Jul 24, 2019 at 1:44 PM Claus Ibsen wrote: > > Hi > > JIRA ticket: > https://issues.apache.org/jira/browse/CAMEL-13788 > > > So on the Camel Message API we have from Camel 1.0 an IN and OUT > message that was based on the JBI and SOAP-WS specs. > > > We have from time to time in the past debated about this API and what > to do for major new releases.What we have settled a bit on is to > favour using getMessage instead of getIn or getOut. So that is why you > have that today with > > getIn > getOut > > And recently introduced is > getMessage > > Which basically is a safe way to use that can deal with the IN vs OUT idiom. > > So I think its time to take the next step and deprecate OUT so we give > Camel end users and component developers and Camel itself amble time > to adjust our code and move to use getMessage instead. > > The getIn vs getOut has also caused a bit confusion what to use, and > despite having both javadoc and a FAQ it stills stumbles on Camel end > users > http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html > > Any thoughts? > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
On Thu, Jul 25, 2019 at 12:24 PM Tadayoshi Sato wrote: > > +1 > > Maybe it's also good time to review other components that have similar > variants. > Yeah we have - camel-quartz2 - camel-netty4 - camel-netty4-http - camel-mongodb3 - camel-mina2 - camel-hdfs2 - camel-rxjava2 - camel-sjms2 > On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger > wrote: > > > +1 > > > > On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino > > wrote: > > > > > +1 > > > > > > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > > > claus.ib...@gmail.com> > > > ha scritto: > > > > > > > Hi > > > > > > > > So what has been bothering Camel 2.x users is that when they use http > > > > they would likely use the camel-http4 component and then they should > > > > use http4 as the component name. The old camel-http component is > > > > deprecated as the http client it uses is EOL for many many years. > > > > > > > > So with Camel 3 on the way we have deleted the old camel-http > > > > component and the camel-http4 component now has both http and http4 as > > > > component names. > > > > > > > > I think we should rename the camel-http4 back to camel-http and then > > > > favour using http as the component name, and then deprecate http4 (or > > > > even remove it). > > > > > > > > Any thoughts? > > > > > > > > > > > > -- > > > > Claus Ibsen > > > > - > > > > http://davsclaus.com @davsclaus > > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
elasticsearch in Camel 3 exixts only as elasticsearch-rest scheme. Il giorno gio 25 lug 2019 alle ore 12:31 Dmitry Volodin ha scritto: > +1 > > And +1 to good idea from Tadayoshi as we have a set of the versions based > components, like elastcisearch, jetty, quartz, etc. > -- > Best regards, > Dmitry Volodin > > > чт, 25 июл. 2019 г. в 13:24, Tadayoshi Sato : > > > +1 > > > > Maybe it's also good time to review other components that have similar > > variants. > > > > On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger > > wrote: > > > > > +1 > > > > > > On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino > > > wrote: > > > > > > > +1 > > > > > > > > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > > > > claus.ib...@gmail.com> > > > > ha scritto: > > > > > > > > > Hi > > > > > > > > > > So what has been bothering Camel 2.x users is that when they use > http > > > > > they would likely use the camel-http4 component and then they > should > > > > > use http4 as the component name. The old camel-http component is > > > > > deprecated as the http client it uses is EOL for many many years. > > > > > > > > > > So with Camel 3 on the way we have deleted the old camel-http > > > > > component and the camel-http4 component now has both http and http4 > > as > > > > > component names. > > > > > > > > > > I think we should rename the camel-http4 back to camel-http and > then > > > > > favour using http as the component name, and then deprecate http4 > (or > > > > > even remove it). > > > > > > > > > > Any thoughts? > > > > > > > > > > > > > > > -- > > > > > Claus Ibsen > > > > > - > > > > > http://davsclaus.com @davsclaus > > > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > > > > > > >
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 And +1 to good idea from Tadayoshi as we have a set of the versions based components, like elastcisearch, jetty, quartz, etc. -- Best regards, Dmitry Volodin чт, 25 июл. 2019 г. в 13:24, Tadayoshi Sato : > +1 > > Maybe it's also good time to review other components that have similar > variants. > > On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger > wrote: > > > +1 > > > > On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino > > wrote: > > > > > +1 > > > > > > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > > > claus.ib...@gmail.com> > > > ha scritto: > > > > > > > Hi > > > > > > > > So what has been bothering Camel 2.x users is that when they use http > > > > they would likely use the camel-http4 component and then they should > > > > use http4 as the component name. The old camel-http component is > > > > deprecated as the http client it uses is EOL for many many years. > > > > > > > > So with Camel 3 on the way we have deleted the old camel-http > > > > component and the camel-http4 component now has both http and http4 > as > > > > component names. > > > > > > > > I think we should rename the camel-http4 back to camel-http and then > > > > favour using http as the component name, and then deprecate http4 (or > > > > even remove it). > > > > > > > > Any thoughts? > > > > > > > > > > > > -- > > > > Claus Ibsen > > > > - > > > > http://davsclaus.com @davsclaus > > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > >
[GitHub] [camel-k] dmvolod commented on issue #869: make images fail on resolve of camel-k-maven-plugin
dmvolod commented on issue #869: make images fail on resolve of camel-k-maven-plugin URL: https://github.com/apache/camel-k/issues/869#issuecomment-514989322 Also please pull latest commits from upstream as some changes related to build process were made 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 With regards, Apache Git Services
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 Maybe it's also good time to review other components that have similar variants. On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger wrote: > +1 > > On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino > wrote: > > > +1 > > > > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > > claus.ib...@gmail.com> > > ha scritto: > > > > > Hi > > > > > > So what has been bothering Camel 2.x users is that when they use http > > > they would likely use the camel-http4 component and then they should > > > use http4 as the component name. The old camel-http component is > > > deprecated as the http client it uses is EOL for many many years. > > > > > > So with Camel 3 on the way we have deleted the old camel-http > > > component and the camel-http4 component now has both http and http4 as > > > component names. > > > > > > I think we should rename the camel-http4 back to camel-http and then > > > favour using http as the component name, and then deprecate http4 (or > > > even remove it). > > > > > > Any thoughts? > > > > > > > > > -- > > > Claus Ibsen > > > - > > > http://davsclaus.com @davsclaus > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > >
[GitHub] [camel-quarkus] asf-ci commented on issue #92: chore(build): move release profile to camel-quarkus-parent
asf-ci commented on issue #92: chore(build): move release profile to camel-quarkus-parent URL: https://github.com/apache/camel-quarkus/pull/92#issuecomment-514989062 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/camel-quarkus-pr/45/ 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 With regards, Apache Git Services
[GitHub] [camel-k] dmvolod commented on issue #869: make images fail on resolve of camel-k-maven-plugin
dmvolod commented on issue #869: make images fail on resolve of camel-k-maven-plugin URL: https://github.com/apache/camel-k/issues/869#issuecomment-514988905 @ipolyzos what is your operator-sdk version? 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 With regards, Apache Git Services
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino wrote: > +1 > > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen < > claus.ib...@gmail.com> > ha scritto: > > > Hi > > > > So what has been bothering Camel 2.x users is that when they use http > > they would likely use the camel-http4 component and then they should > > use http4 as the component name. The old camel-http component is > > deprecated as the http client it uses is EOL for many many years. > > > > So with Camel 3 on the way we have deleted the old camel-http > > component and the camel-http4 component now has both http and http4 as > > component names. > > > > I think we should rename the camel-http4 back to camel-http and then > > favour using http as the component name, and then deprecate http4 (or > > even remove it). > > > > Any thoughts? > > > > > > -- > > Claus Ibsen > > - > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > >
Re: [DISCUSS] Meta model
Hi Btw a follow up question. Would we be able to get to a point where all the model classes (xxxDefinition and helpers etc) can be dropped at runtime, eg for camel-quarkus optimization? And also the refiers as they are the builder from model -> processor. Well what you experiment with is surely a great step in that direction too. On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet wrote: > > Hey everyone ! > > The last weeks, I've spend quite some time working on a camel metamodel. > The idea is to invert the way things are built in camel so instead of > generating the metamodel from the classes, the metamodel would be > maintained manually and used to generate a bunch of things. > > This would bring the following benefits: > - the metamodel would necessarily be up to date > - generate the model classes (XyzDefinition classes) with an homogeneous > fluent api (similar to the new endpoint DSL) > - get rid of some round tripping between java -> json -> java, copying > json files everywhere , so great simplification of the build process > - the DSL allows type-safe + property placeholders / references everywhere > - generate xml readers / parsers without relying on JAXB > - brings extensibility of the DSL as it would be much easier to create > DSLs based on other languages from the metamodel (yaml for example) > > I've pushed a branch that shows my experiments. It's not fully working > yet, but it gives a good idea. It's available at > https://github.com/gnodet/camel/tree/model > I'm progressing a bit slowly as there are lots of step by step adjustements > to do in order to keep compatibility of the DSL. > > Currently the model is generated from the json files, but the idea is to > reverse this process and have the metamodel the real primary input for all > generation. > The model currently looks like: > https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 > > The current JAXB model will need to be moved into a separate module so that > it can be kept for compatibility without interfering with the new generated > java DSL. > > So, still quite some work left, but I wanted to bring it to the community > sooner rather than later, especially before I go on PTO for a few weeks > where I'll be mostly offline. > Happy to discuss anything or provide more infos. > > Cheers, > Guillaume Nodet -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen ha scritto: > Hi > > So what has been bothering Camel 2.x users is that when they use http > they would likely use the camel-http4 component and then they should > use http4 as the component name. The old camel-http component is > deprecated as the http client it uses is EOL for many many years. > > So with Camel 3 on the way we have deleted the old camel-http > component and the camel-http4 component now has both http and http4 as > component names. > > I think we should rename the camel-http4 back to camel-http and then > favour using http as the component name, and then deprecate http4 (or > even remove it). > > Any thoughts? > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
Re: [DISCUSS] Meta model
On Thu, Jul 25, 2019 at 11:28 AM Guillaume Nodet wrote: > > Le jeu. 25 juil. 2019 à 10:47, Claus Ibsen a écrit : > > > Hi > > > > Good to see more experiments, but as others have said in this mail > > thread, its too overwhelming to dive into and understand. > > > > Yes, I definitely get that, especially as it's still work in progress. > > On the java dsl side, the goal is to be 100% compatible, i.e. i'm trying to > generate the DSL without changing all the tests in camel-core. > However, this opens new possibilities, mainly about having a consistent way > to inject references and use property placeholders, especially in places > where this was not possible. > Ah okay so you are doing the same generating as endpoint dsl, where an option that is eg a integer, you generate a builder for both - integer - string Where the latter can be used for property placeholders. > > > > So what I can see is that the model is now more "coded" in velocity vm > > and xml xslt files, than what we had before with the java model > > classes with JAXB annotations. > Okay so with these vm and xslt files then they seem a bit hardcore. I am a little worried how we can maintain this. But I can see they do the "hard" work of code generating from the metamodel. > > > > Also I fail to see how it would understand if we add a new EIP today - > > how would you go about doing that? > > > > So if the xml metamodel becomes the real input (see below), then the > developer would have to modify the metamodel to add an element to it (a > processor, language, dataformat, or maybe a property on an existing > element). > You'd build the camel-metamodel, then build camel-core which re-generates > all the data structures. At this point, the property will be added to the > java code, so the next step is to actually create or modify the reifier and > the runtime bits to actually use it. > Okay that is a fairly easy process. > > > > > I do like that if we can have a lighter XML parser that is stax based than > > JAXB. > > And also if we can generate the XML XSD without JAXB at all. > > > > Yes. > > > > And the meta-model that you link to is a XML file which seems like an > > aggregation of what we have today in camel-catalog in the various json > > files. > > > > Yes, though this is temporary in my mind. I think the main input should > be the xml metamodel which would be "manually" maintained. From this file, > we should generate everything that we need, including the json files for > the catalog. > Ah okay so we have this single xml file. Well frankly this file seems reasonable straightforward to understand and edit. The only point is that for endpoints such jms etc, that has many options and whatnot. Then we have a build tool that generate and update the XML file with all these endpoints? And the same for components, eg we have component level options also. And speaking of that, we may also consider a fluent builder DSL for that too - like we have for endpoint DSL. > > > As you are going on PTO for a while I think we should maybe keep this > > in mind that this work will not get completed or finished in the near > > future. > > We may consider getting the last other stuff done and get M5 out the > > door as the last milestone, and then close down on RC builds. > > > > Then this meta-model can maybe be introduced in "steps" for 3.1, 3.2 > > etc. to give it more time to be more stable and maintainable. > > > > > > > > On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet wrote: > > > > > > Hey everyone ! > > > > > > The last weeks, I've spend quite some time working on a camel metamodel. > > > The idea is to invert the way things are built in camel so instead of > > > generating the metamodel from the classes, the metamodel would be > > > maintained manually and used to generate a bunch of things. > > > > > > This would bring the following benefits: > > > - the metamodel would necessarily be up to date > > > - generate the model classes (XyzDefinition classes) with an > > homogeneous > > > fluent api (similar to the new endpoint DSL) > > > - get rid of some round tripping between java -> json -> java, copying > > > json files everywhere , so great simplification of the build process > > > - the DSL allows type-safe + property placeholders / references > > everywhere > > > - generate xml readers / parsers without relying on JAXB > > > - brings extensibility of the DSL as it would be much easier to create > > > DSLs based on other languages from the metamodel (yaml for example) > > > > > > I've pushed a branch that shows my experiments. It's not fully working > > > yet, but it gives a good idea. It's available at > > > https://github.com/gnodet/camel/tree/model > > > I'm progressing a bit slowly as there are lots of step by step > > adjustements > > > to do in order to keep compatibility of the DSL. > > > > > > Currently the model is generated from the json files, but the idea is to > > > reverse this process and have the
[GitHub] [camel-k] ipolyzos edited a comment on issue #869: make images fail on resolve of camel-k-maven-plugin
ipolyzos edited a comment on issue #869: make images fail on resolve of
camel-k-maven-plugin
URL: https://github.com/apache/camel-k/issues/869#issuecomment-514979902
A new issue later on the compilation of _pkg/trait/knative.go_ stops from
completing the images-dev build please see the log below
> [INFO]
> [INFO] BUILD SUCCESS
> [INFO]
> [INFO] Total time: 2.670 s
> [INFO] Finished at: 2019-07-25T10:54:47+01:00
> [INFO]
> mkdir -p build/_maven_output
> mkdir -p build/_output/bin
> cp builder build/_output/bin
> operator-sdk build docker.io/apache/camel-k:1.0.0-M1-SNAPSHOT
> /# github.com/apache/camel-k/pkg/trait
> pkg/trait/knative.go:301:52: cannot use *status.RouteStatusFields.Address
(type "knative.dev/pkg/apis/duck/v1alpha1".Addressable) as type
"github.com/knative/pkg/apis/duck/v1alpha1".Addressable in argument to
buildServiceDefinition
> pkg/trait/knative.go:309:16: addressable.URL undefined (type
"github.com/knative/pkg/apis/duck/v1alpha1".Addressable has no field or method
URL)
> pkg/trait/knative.go:310:88: addressable.URL undefined (type
"github.com/knative/pkg/apis/duck/v1alpha1".Addressable has no field or method
URL)
> pkg/trait/knative_service.go:209:7: cannot use
"github.com/knative/serving/pkg/apis/serving/v1beta1".RevisionSpec literal
(type "github.com/knative/serving/pkg/apis/serving/v1beta1".RevisionSpec) as
type "knative.dev/serving/pkg/apis/serving/v1beta1".RevisionSpec in field value
> Error: failed to build operator binary: (failed to exec []string{"go",
"build", "-o", "/home/ipolyzos/repositories/camel-k/build/_output/bin/camel-k",
"-gcflags", "all=-trimpath=/home/ipolyzos/repositories", "-asmflags",
"all=-trimpath=/home/ipolyzos/repositories", "-mod=vendor",
"github.com/apache/camel-k/cmd/manager"}: exit status 2)
> Usage:
> operator-sdk build [flags]
>
> Flags:
> --go-build-args string Extra Go build arguments as one string
such as "-ldflags -X=main.xyz=abc"
> -h, --help help for build
> --image-build-args string Extra image build arguments as one
string such as "--build-arg https_proxy=$https_proxy"
> --image-builder string Tool to build OCI images. One of:
[docker, podman, buildah] (default "docker")
>
> Global Flags:
> --verbose Enable verbose logging
>
> make: *** [Makefile:170: images-dev] Error 1
>
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
With regards,
Apache Git Services
[GitHub] [camel-k] ipolyzos commented on issue #869: make images fail on resolve of camel-k-maven-plugin
ipolyzos commented on issue #869: make images fail on resolve of
camel-k-maven-plugin
URL: https://github.com/apache/camel-k/issues/869#issuecomment-514979902
A new issue later on the compilation of _pkg/trait/knative.go_ stops from
completing the images-dev build please see the log below
> [INFO]
> [INFO] BUILD SUCCESS
> [INFO]
> [INFO] Total time: 2.670 s
> [INFO] Finished at: 2019-07-25T10:54:47+01:00
> [INFO]
> mkdir -p build/_maven_output
> mkdir -p build/_output/bin
> cp builder build/_output/bin
> operator-sdk build docker.io/apache/camel-k:1.0.0-M1-SNAPSHOT
> # github.com/apache/camel-k/pkg/trait
> pkg/trait/knative.go:301:52: cannot use *status.RouteStatusFields.Address
(type "knative.dev/pkg/apis/duck/v1alpha1".Addressable) as type
"github.com/knative/pkg/apis/duck/v1alpha1".Addressable in argument to
buildServiceDefinition
> pkg/trait/knative.go:309:16: addressable.URL undefined (type
"github.com/knative/pkg/apis/duck/v1alpha1".Addressable has no field or method
URL)
> pkg/trait/knative.go:310:88: addressable.URL undefined (type
"github.com/knative/pkg/apis/duck/v1alpha1".Addressable has no field or method
URL)
> pkg/trait/knative_service.go:209:7: cannot use
"github.com/knative/serving/pkg/apis/serving/v1beta1".RevisionSpec literal
(type "github.com/knative/serving/pkg/apis/serving/v1beta1".RevisionSpec) as
type "knative.dev/serving/pkg/apis/serving/v1beta1".RevisionSpec in field value
> Error: failed to build operator binary: (failed to exec []string{"go",
"build", "-o", "/home/ipolyzos/repositories/camel-k/build/_output/bin/camel-k",
"-gcflags", "all=-trimpath=/home/ipolyzos/repositories", "-asmflags",
"all=-trimpath=/home/ipolyzos/repositories", "-mod=vendor",
"github.com/apache/camel-k/cmd/manager"}: exit status 2)
> Usage:
> operator-sdk build [flags]
>
> Flags:
> --go-build-args string Extra Go build arguments as one string
such as "-ldflags -X=main.xyz=abc"
> -h, --help help for build
> --image-build-args string Extra image build arguments as one
string such as "--build-arg https_proxy=$https_proxy"
> --image-builder string Tool to build OCI images. One of:
[docker, podman, buildah] (default "docker")
>
> Global Flags:
> --verbose Enable verbose logging
>
> make: *** [Makefile:170: images-dev] Error 1
>
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
With regards,
Apache Git Services
[GitHub] [camel-k] ipolyzos opened a new issue #869: make images fail on resolve of camel-k-maven-plugin
ipolyzos opened a new issue #869: make images fail on resolve of camel-k-maven-plugin URL: https://github.com/apache/camel-k/issues/869 ``` $ make images``` fails on the latest master due to unable to resolve maven artifact. Please see the error message below for more > [INFO] < org.apache.camel.k:camel-k-catalog-generator > > [INFO] Building camel-k-catalog-generator 1.0.0 > [INFO] [ jar ]- > [INFO] > [INFO] --- maven-dependency-plugin:3.1.1:copy-dependencies (default-cli) @ camel-k-catalog-generator --- > [INFO] > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.1.1:copy-dependencies (default-cli) on project camel-k-catalog-generator: Error resolving project artifact: Could not find artifact org.apache > .camel.k:camel-k-maven-plugin:pom:1.0.0-20190723.194340-25 for project org.apache.camel.k:camel-k-maven-plugin:maven-plugin:1.0.0-SNAPSHOT -> [Help 1] > [ERROR] You can also refer to the following link for the full log output https://pastebin.com/hxsiu5TR 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 With regards, Apache Git Services
[GitHub] [camel-k] dmvolod commented on issue #863: operator-sdk build fails on latest master with 'make images-dev'
dmvolod commented on issue #863: operator-sdk build fails on latest master with 'make images-dev' URL: https://github.com/apache/camel-k/issues/863#issuecomment-514979096 @aldettinger, I'm fine with build right now. Please pull latest master from upstream. 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 With regards, Apache Git Services
[GitHub] [camel-k] aldettinger commented on issue #863: operator-sdk build fails on latest master with 'make images-dev'
aldettinger commented on issue #863: operator-sdk build fails on latest master with 'make images-dev' URL: https://github.com/apache/camel-k/issues/863#issuecomment-514979509 It may be another issue then, I'll investigate that. Many thanks @dmvolod . 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 With regards, Apache Git Services
Re: [DISCUSS] Meta model
Your point is really interesting. However, I think one of the main problem right now is that the metamodel information is spread in the whole source tree (some bits in camel-core, and lots in the various components). This leads to a lot of hacks and round trips in the build system (copying json files from various locations, etc...). Getting out of sync is already somehow a problem with dataformats and languages, where the XyzDefinition are mapped to the actual dataformat / language properties using introspection. This is even more the case in Camel 3 with the new endpoint DSL which basically does the same thing (though it was already done using uri parameters). I think if we have the metamodel from the beginning of the build, we should be able to validate that the properties do exist in the final java classes (components, endpoints, dataformats and languages). The only way to have all the information from the java code and have a clean build would be to generate the DSL (java + xml) after all components / langauges / dataformats would have been built, i.e. build camel-core at the end, so that we could use the real java classes and use them. However, I'm not sure that this woud be a good idea, given the length of the build... Le jeu. 25 juil. 2019 à 11:11, Zoran Regvart a écrit : > Hi Guillaume & Cameleers, > I like that there's an effort to make the code more maintainable. I do > however feel that the source of truth is best kept in the Java code, > and perhaps this new model can be generated from that. I understand > the need for having a single strictly typed source of truth. > > Could we have the flow somehow like Java -> (XML?) meta model -> code > generation of XML readers/writers and DSL? > > I have an inkling that we could even generate the meta model in Java > and code generate from there without the model being in XML format, we > are kinda, while awkwardly, doing it right now. > > I fear that unless we add more strict checking that if the XML meta > model is the source of truth that we'll easily diverge from the Java > code. For example, if we remove a property from the endpoint we need > tooling that'll fail the build if the meta model is not updated and > the property is removed there as well. > > > zoran > > On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet wrote: > > > > Hey everyone ! > > > > The last weeks, I've spend quite some time working on a camel metamodel. > > The idea is to invert the way things are built in camel so instead of > > generating the metamodel from the classes, the metamodel would be > > maintained manually and used to generate a bunch of things. > > > > This would bring the following benefits: > > - the metamodel would necessarily be up to date > > - generate the model classes (XyzDefinition classes) with an > homogeneous > > fluent api (similar to the new endpoint DSL) > > - get rid of some round tripping between java -> json -> java, copying > > json files everywhere , so great simplification of the build process > > - the DSL allows type-safe + property placeholders / references > everywhere > > - generate xml readers / parsers without relying on JAXB > > - brings extensibility of the DSL as it would be much easier to create > > DSLs based on other languages from the metamodel (yaml for example) > > > > I've pushed a branch that shows my experiments. It's not fully working > > yet, but it gives a good idea. It's available at > > https://github.com/gnodet/camel/tree/model > > I'm progressing a bit slowly as there are lots of step by step > adjustements > > to do in order to keep compatibility of the DSL. > > > > Currently the model is generated from the json files, but the idea is to > > reverse this process and have the metamodel the real primary input for > all > > generation. > > The model currently looks like: > > https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 > > > > The current JAXB model will need to be moved into a separate module so > that > > it can be kept for compatibility without interfering with the new > generated > > java DSL. > > > > So, still quite some work left, but I wanted to bring it to the community > > sooner rather than later, especially before I go on PTO for a few weeks > > where I'll be mostly offline. > > Happy to discuss anything or provide more infos. > > > > Cheers, > > Guillaume Nodet > > > > -- > Zoran Regvart > -- Guillaume Nodet
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 It's always difficult to tell people why they have to use http4 during demos ;) Nicola On Thu, Jul 25, 2019 at 11:48 AM Claus Ibsen wrote: > Hi > > So what has been bothering Camel 2.x users is that when they use http > they would likely use the camel-http4 component and then they should > use http4 as the component name. The old camel-http component is > deprecated as the http client it uses is EOL for many many years. > > So with Camel 3 on the way we have deleted the old camel-http > component and the camel-http4 component now has both http and http4 as > component names. > > I think we should rename the camel-http4 back to camel-http and then > favour using http as the component name, and then deprecate http4 (or > even remove it). > > Any thoughts? > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http
+1 Sounds good ! Le jeu. 25 juil. 2019 à 11:48, Claus Ibsen a écrit : > Hi > > So what has been bothering Camel 2.x users is that when they use http > they would likely use the camel-http4 component and then they should > use http4 as the component name. The old camel-http component is > deprecated as the http client it uses is EOL for many many years. > > So with Camel 3 on the way we have deleted the old camel-http > component and the camel-http4 component now has both http and http4 as > component names. > > I think we should rename the camel-http4 back to camel-http and then > favour using http as the component name, and then deprecate http4 (or > even remove it). > > Any thoughts? > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > -- Guillaume Nodet
[HEADS UP] - camel3 - camel-http4 renaming to camel-http
Hi So what has been bothering Camel 2.x users is that when they use http they would likely use the camel-http4 component and then they should use http4 as the component name. The old camel-http component is deprecated as the http client it uses is EOL for many many years. So with Camel 3 on the way we have deleted the old camel-http component and the camel-http4 component now has both http and http4 as component names. I think we should rename the camel-http4 back to camel-http and then favour using http as the component name, and then deprecate http4 (or even remove it). Any thoughts? -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
[GitHub] [camel-k] astefanutti commented on issue #863: operator-sdk build fails on latest master with 'make images-dev'
astefanutti commented on issue #863: operator-sdk build fails on latest master with 'make images-dev' URL: https://github.com/apache/camel-k/issues/863#issuecomment-514960396 @dmvolod thanks a lot for your valuable inputs on this. Let us know the outcome of the discussion upstream. 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 With regards, Apache Git Services
[GitHub] [camel-k] astefanutti closed issue #863: operator-sdk build fails on latest master with 'make images-dev'
astefanutti closed issue #863: operator-sdk build fails on latest master with 'make images-dev' URL: https://github.com/apache/camel-k/issues/863 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 With regards, Apache Git Services
[GitHub] [camel-k] astefanutti commented on issue #863: operator-sdk build fails on latest master with 'make images-dev'
astefanutti commented on issue #863: operator-sdk build fails on latest master with 'make images-dev' URL: https://github.com/apache/camel-k/issues/863#issuecomment-514959948 Let me close this as it should be fixed with #872. Feel free to re-open if that is not the case. 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 With regards, Apache Git Services
[GitHub] [camel-k] nicolaferraro merged pull request #877: chore(js): fix examples, use arrow function for lambda style processor
nicolaferraro merged pull request #877: chore(js): fix examples, use arrow function for lambda style processor URL: https://github.com/apache/camel-k/pull/877 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 With regards, Apache Git Services
[GitHub] [camel-k] nicolaferraro merged pull request #872: Remove Dep files
nicolaferraro merged pull request #872: Remove Dep files URL: https://github.com/apache/camel-k/pull/872 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 With regards, Apache Git Services
[GitHub] [camel-k] lburgazzoli merged pull request #871: chore(build): remove go mod vendor from travis build
lburgazzoli merged pull request #871: chore(build): remove go mod vendor from travis build URL: https://github.com/apache/camel-k/pull/871 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 With regards, Apache Git Services
Re: [DISCUSS] Meta model
Hi Good to see more experiments, but as others have said in this mail thread, its too overwhelming to dive into and understand. So what I can see is that the model is now more "coded" in velocity vm and xml xslt files, than what we had before with the java model classes with JAXB annotations. Also I fail to see how it would understand if we add a new EIP today - how would you go about doing that? I do like that if we can have a lighter XML parser that is stax based than JAXB. And also if we can generate the XML XSD without JAXB at all. And the meta-model that you link to is a XML file which seems like an aggregation of what we have today in camel-catalog in the various json files. As you are going on PTO for a while I think we should maybe keep this in mind that this work will not get completed or finished in the near future. We may consider getting the last other stuff done and get M5 out the door as the last milestone, and then close down on RC builds. Then this meta-model can maybe be introduced in "steps" for 3.1, 3.2 etc. to give it more time to be more stable and maintainable. On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet wrote: > > Hey everyone ! > > The last weeks, I've spend quite some time working on a camel metamodel. > The idea is to invert the way things are built in camel so instead of > generating the metamodel from the classes, the metamodel would be > maintained manually and used to generate a bunch of things. > > This would bring the following benefits: > - the metamodel would necessarily be up to date > - generate the model classes (XyzDefinition classes) with an homogeneous > fluent api (similar to the new endpoint DSL) > - get rid of some round tripping between java -> json -> java, copying > json files everywhere , so great simplification of the build process > - the DSL allows type-safe + property placeholders / references everywhere > - generate xml readers / parsers without relying on JAXB > - brings extensibility of the DSL as it would be much easier to create > DSLs based on other languages from the metamodel (yaml for example) > > I've pushed a branch that shows my experiments. It's not fully working > yet, but it gives a good idea. It's available at > https://github.com/gnodet/camel/tree/model > I'm progressing a bit slowly as there are lots of step by step adjustements > to do in order to keep compatibility of the DSL. > > Currently the model is generated from the json files, but the idea is to > reverse this process and have the metamodel the real primary input for all > generation. > The model currently looks like: > https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 > > The current JAXB model will need to be moved into a separate module so that > it can be kept for compatibility without interfering with the new generated > java DSL. > > So, still quite some work left, but I wanted to bring it to the community > sooner rather than later, especially before I go on PTO for a few weeks > where I'll be mostly offline. > Happy to discuss anything or provide more infos. > > Cheers, > Guillaume Nodet -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
[GitHub] [camel-quarkus] lburgazzoli commented on issue #77: Move test packages to org.apache.camel
lburgazzoli commented on issue #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#issuecomment-514956354 @ppalaga added snapshot profile active by default for the moment as there were some changes in quarkus like moving to GraalVM 19.1.1 that have introduced some regressions, will disable this profile after quarkus 0.20.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 With regards, Apache Git Services
[GitHub] [camel-k] nicolaferraro closed issue #832: GC trait fails on some installations
nicolaferraro closed issue #832: GC trait fails on some installations URL: https://github.com/apache/camel-k/issues/832 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 With regards, Apache Git Services
[GitHub] [camel-k] nicolaferraro merged pull request #876: fix(GC): Skip 503 errors when scanning for resources to be GCed
nicolaferraro merged pull request #876: fix(GC): Skip 503 errors when scanning for resources to be GCed URL: https://github.com/apache/camel-k/pull/876 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 With regards, Apache Git Services
[GitHub] [camel-k-runtime] lburgazzoli merged pull request #116: Lambda processor doesn't work with JS routes
lburgazzoli merged pull request #116: Lambda processor doesn't work with JS routes URL: https://github.com/apache/camel-k-runtime/pull/116 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 With regards, Apache Git Services
[GitHub] [camel-k-runtime] lburgazzoli closed issue #115: Lambda processor doesn't work with JS routes
lburgazzoli closed issue #115: Lambda processor doesn't work with JS routes URL: https://github.com/apache/camel-k-runtime/issues/115 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 With regards, Apache Git Services
[GitHub] [camel-website] zregvart merged pull request #58: added microdata to hugo footer.html
zregvart merged pull request #58: added microdata to hugo footer.html URL: https://github.com/apache/camel-website/pull/58 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 With regards, Apache Git Services
[GitHub] [camel-k] lburgazzoli commented on issue #874: chore(js): remove processor for js examples because of a bug in graaljs
lburgazzoli commented on issue #874: chore(js): remove processor for js examples because of a bug in graaljs URL: https://github.com/apache/camel-k/pull/874#issuecomment-514950847 Will be fixed by https://github.com/apache/camel-k-runtime/pull/116 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 With regards, Apache Git Services
[GitHub] [camel-k] lburgazzoli closed pull request #874: chore(js): remove processor for js examples because of a bug in graaljs
lburgazzoli closed pull request #874: chore(js): remove processor for js examples because of a bug in graaljs URL: https://github.com/apache/camel-k/pull/874 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 With regards, Apache Git Services
[GitHub] [camel-k-runtime] lburgazzoli opened a new pull request #116: Lambda processor doesn't work with JS routes
lburgazzoli opened a new pull request #116: Lambda processor doesn't work with JS routes URL: https://github.com/apache/camel-k-runtime/pull/116 Fixes #115 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 With regards, Apache Git Services
Re: [DISCUSS] Meta model
Hi, yes some examples to describe these new features would be great. There are tones of changes which is a bit hard to follow at this stage (at least for me) On Wed, Jul 24, 2019 at 4:17 PM Andrea Cosentino wrote: > Yeah, a concrete example of what has been done could be useful to better > understand > > Il mer 24 lug 2019, 17:11 Luca Burgazzoli ha > scritto: > > > I Guillaume, > > > > I think it is a little bit hard to figure out what's happening looking at > > the code changes as it is quite a huge list of changed file :) > > Maybe having some concrete examples or an examples of what things will > look > > like could help to have a better understanding and giove more options to > > suggest enhancements or raising concerns. > > > > > > --- > > Luca Burgazzoli > > > > > > On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet > wrote: > > > > > Hey everyone ! > > > > > > The last weeks, I've spend quite some time working on a camel > metamodel. > > > The idea is to invert the way things are built in camel so instead of > > > generating the metamodel from the classes, the metamodel would be > > > maintained manually and used to generate a bunch of things. > > > > > > This would bring the following benefits: > > > - the metamodel would necessarily be up to date > > > - generate the model classes (XyzDefinition classes) with an > > homogeneous > > > fluent api (similar to the new endpoint DSL) > > > - get rid of some round tripping between java -> json -> java, > copying > > > json files everywhere , so great simplification of the build process > > > - the DSL allows type-safe + property placeholders / references > > > everywhere > > > - generate xml readers / parsers without relying on JAXB > > > - brings extensibility of the DSL as it would be much easier to > create > > > DSLs based on other languages from the metamodel (yaml for example) > > > > > > I've pushed a branch that shows my experiments. It's not fully working > > > yet, but it gives a good idea. It's available at > > > https://github.com/gnodet/camel/tree/model > > > I'm progressing a bit slowly as there are lots of step by step > > adjustements > > > to do in order to keep compatibility of the DSL. > > > > > > Currently the model is generated from the json files, but the idea is > to > > > reverse this process and have the metamodel the real primary input for > > all > > > generation. > > > The model currently looks like: > > > https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 > > > > > > The current JAXB model will need to be moved into a separate module so > > that > > > it can be kept for compatibility without interfering with the new > > generated > > > java DSL. > > > > > > So, still quite some work left, but I wanted to bring it to the > community > > > sooner rather than later, especially before I go on PTO for a few weeks > > > where I'll be mostly offline. > > > Happy to discuss anything or provide more infos. > > > > > > Cheers, > > > Guillaume Nodet > > > > > >
[GitHub] [camel-quarkus] asf-ci commented on issue #77: Move test packages to org.apache.camel
asf-ci commented on issue #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#issuecomment-514930884 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/camel-quarkus-pr/44/ 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 With regards, Apache Git Services
[GitHub] [camel-k-runtime] lburgazzoli commented on issue #115: Lambda processor doesn't work with JS routes
lburgazzoli commented on issue #115: Lambda processor doesn't work with JS routes URL: https://github.com/apache/camel-k-runtime/issues/115#issuecomment-514929709 relates to https://github.com/oracle/graal/issues/1247 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 With regards, Apache Git Services
[GitHub] [camel-k] lburgazzoli closed issue #873: Lambda processor doesn't work with JS routes
lburgazzoli closed issue #873: Lambda processor doesn't work with JS routes URL: https://github.com/apache/camel-k/issues/873 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 With regards, Apache Git Services
[GitHub] [camel-k-runtime] tadayosi opened a new issue #115: Lambda processor doesn't work with JS routes
tadayosi opened a new issue #115: Lambda processor doesn't work with JS routes
URL: https://github.com/apache/camel-k-runtime/issues/115
Copied from apache/camel-k#873
With Camel K Client 1.0.0-M1-SNAPSHOT, `examples/routes.js` doesn't work as
follows:
```
$ kamel run --dev examples/routes.js
[...]
[1] 2019-07-25 02:36:45.686 WARN [Camel (camel-k) thread #2 - timer://js]
TimerConsumer - Error processing exchange.
Exchange[ID-routes-5ccdc6b89-jl2c9-1564022203707-0-5]. Caused by:
[java.lang.ClassCastException - java.lang.Object cannot be cast to
com.oracle.truffle.polyglot.PolyglotLanguageContext]
[1] java.lang.ClassCastException: java.lang.Object cannot be cast to
com.oracle.truffle.polyglot.PolyglotLanguageContext
[1] at
com.oracle.truffle.polyglot.PolyglotLanguage$ContextProfile.profile(PolyglotLanguage.java:383)
~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] at
com.oracle.truffle.polyglot.HostToGuestRootNode.profileContext(HostToGuestRootNode.java:113)
~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] at
com.oracle.truffle.polyglot.HostToGuestRootNode.execute(HostToGuestRootNode.java:72)
~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] at
com.oracle.truffle.api.impl.DefaultCallTarget.call(DefaultCallTarget.java:102)
~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] at
com.oracle.truffle.polyglot.FunctionProxyHandler.invoke(HostInteropReflect.java:454)
~[org.graalvm.truffle.truffle-api-19.0.2.jar:?]
[1] at com.sun.proxy.$Proxy28.process(Unknown Source) ~[?:?]
[1] at
org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:63)
~[org.apache.camel.camel-support-3.0.0-M4.jar:3.0.0-M4]
[1] at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryState.run(RedeliveryErrorHandler.java:480)
~[org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:185)
[org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] at
org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:59)
[org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] at org.apache.camel.processor.Pipeline.process(Pipeline.java:87)
[org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:222)
[org.apache.camel.camel-base-3.0.0-M4.jar:3.0.0-M4]
[1] at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:193)
[org.apache.camel.camel-timer-3.0.0-M4.jar:3.0.0-M4]
[1] at
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:75)
[org.apache.camel.camel-timer-3.0.0-M4.jar:3.0.0-M4]
[1] at java.util.TimerThread.mainLoop(Timer.java:555) [?:1.8.0_191]
[1] at java.util.TimerThread.run(Timer.java:505) [?:1.8.0_191]
[1] Caused by: com.oracle.truffle.api.TruffleStackTrace$LazyStackTrace
```
The error comes from this part. Removing `.process(proc)` makes the route
work.
```
function proc(e) {
e.getIn().setHeader('RandomValue', Math.floor((Math.random() * 100) + 1))
}
[...]
.process(proc)
```
See also: apache/camel-k#589
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
With regards,
Apache Git Services
[GitHub] [camel-k] tadayosi commented on issue #873: Lambda processor doesn't work with JS routes
tadayosi commented on issue #873: Lambda processor doesn't work with JS routes URL: https://github.com/apache/camel-k/issues/873#issuecomment-514928684 @lburgazzoli Oh, sure, will do from next time. 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 With regards, Apache Git Services
[GitHub] [camel-k] nicolaferraro opened a new issue #875: Kamel reset should delete build
nicolaferraro opened a new issue #875: Kamel reset should delete build URL: https://github.com/apache/camel-k/issues/875 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 With regards, Apache Git Services
[GitHub] [camel-k-runtime] lburgazzoli merged pull request #114: chore(js): add test for rest dsl/definition
lburgazzoli merged pull request #114: chore(js): add test for rest dsl/definition URL: https://github.com/apache/camel-k-runtime/pull/114 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] asf-ci commented on issue #77: Move test packages to org.apache.camel
asf-ci commented on issue #77: Move test packages to org.apache.camel URL: https://github.com/apache/camel-quarkus/pull/77#issuecomment-514917743 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/camel-quarkus-pr/43/ 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 With regards, Apache Git Services
[GitHub] [camel-k] dmvolod commented on issue #863: operator-sdk build fails on latest master with 'make images-dev'
dmvolod commented on issue #863: operator-sdk build fails on latest master with 'make images-dev' URL: https://github.com/apache/camel-k/issues/863#issuecomment-514915207 @lburgazzoli , @astefanutti thanks. I will report the issue and discuss it in operator-sdk upstream. 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] oscerd merged pull request #90: chore(it): cleanup it poms
oscerd merged pull request #90: chore(it): cleanup it poms URL: https://github.com/apache/camel-quarkus/pull/90 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 With regards, Apache Git Services
[GitHub] [camel-quarkus] asf-ci commented on issue #90: chore(it): cleanup it poms
asf-ci commented on issue #90: chore(it): cleanup it poms URL: https://github.com/apache/camel-quarkus/pull/90#issuecomment-514914175 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/camel-quarkus-pr/42/ 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 With regards, Apache Git Services
