Re: Using Camel as backend in a new Apache "spinoff" project?

[Willem Jiang]

I used to address the camel performance issue 6 years ago, which led
me to find a use case for collecting millions of performance data as a
SaaS service.
In that case, camel leverages Kafka to persist received messages.  I
don't think the in-memory queue could address the problem.
@ Chris,  Can you share more information about your use case?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem


On Wed, Dec 7, 2022 at 11:16 PM Christofer Dutz
 wrote:
>
> Hi Zheng,
>
> We’re currently discussing multiple scenarios. In the “all in one” if would 
> definitely make sense to do that and to improve the Camel PLC4X component 
> while at it.
>
> In general, we’re thinking of an application, that starts an IoTDB server 
> embedded as well as something that pumps data into it and some sort of API 
> frontend with which industry solutions can communicate with.
>
> But it’s not even decided IF we use Camel … just wanted to ask you folks 
> here, if you think it’s a good idea and if it’s a good idea, if anyone wants 
> to join in 
>
> Chris
>
>
> From: Zheng Feng 
> Date: Wednesday, 7. December 2022 at 14:31
> To: dev@camel.apache.org 
> Subject: Re: Using Camel as backend in a new Apache "spinoff" project?
> It looks interesting and will it run a camel router with PLC4X component as
> an agent of IoTDB to collect data and send them directly to a server?
>
> On Wed, Dec 7, 2022 at 8:59 PM Christofer Dutz 
> wrote:
>
> > Hi,
> >
> > we’re currently discussing potentially using Apache Camel for building a
> > product based on Apache PLC4X, Apache IoTDB to build a Historian solution
> > for industrial use-cases.
> > We’re planning on making this less a framework, but more a product, based
> > on open-source frameworks and as soon as we have something, to bring it
> > back into Apache as a new project.
> >
> > Now I brought up the Idea of using Apache Camel as the communication layer
> > between all.
> >
> > I am admittedly a bit hesitant to introduce Kafka into the game as we aim
> > at building something we can run as installable product, adding Kafka would
> > complicate this, so I’d be happy to use something like Camel for this
> > usecase.
> >
> > What are your thoughts on this? How do camel routes perform when we’re
> > talking hundreds of thousands to millions of events a minute?
> >
> > And … anyone interested into joining this initiative? If yes, please ping
> > me off-list and I’ll add you.
> >
> >
> > Chris
> >
> >
> >

Re: Draft Camel Board Report for June 2022

[Willem Jiang]

You can edit the report here[1] before the board director reviews it today.
[1]https://whimsy.apache.org/board/agenda/2022-06-15/Camel

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Jun 7, 2022 at 7:30 PM Zoran Regvart  wrote:
>
> On Tue, Jun 7, 2022 at 11:16 AM Andrea Cosentino  wrote:
> >
> > Sorry, but I submitted it yesterday afternoon.
> >
> > I totally forgot about it.
>
> No worries, we can add it in the next report...
>
> zoran
> --
> Zoran Regvart

[ApacheCon] Please submit your proposals for the ApacheCon Asia 2022

[Willem Jiang]

Hi

As you may know ApacheCon Asia 2022 is calling for presentations[1].
Just like the ApacheConAsia 2021, we will hold an online summit
targeting the Asia time zone.
Zoran and I will be the track chair of an integration track[2] as last year,
please don't hesitate to submit your proposal before May 31st.

[1]https://apachecon.com/acasia2022/cfp.html
[2]https://apachecon.com/acasia2022/tracks/integration.html

Best Regards,

Willem Jiang

Re: [VOTE] Release Apache Camel 3.7.7 (LTS)

[Willem Jiang]

+1 （binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Dec 20, 2021 at 6:42 PM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 3.7.7 (with Apache Camel Spring
> Boot and Apache Camel Karaf), a new minor release with 7 fixes and
> improvements.
>
> This email contains the actual repository links.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350650=12311220
>
> == Apache Camel 3.7.7 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1383/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1383/org/apache/camel/apache-camel/3.7.7/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.7.7
>
> == Apache Camel Spring Boot 3.7.7 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1387/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel-spring-boot.git;a=tag;h=refs/tags/camel-spring-boot-3.7.7
>
> == Apache Camel Karaf 3.7.7 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1389/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel-karaf.git;a=tag;h=refs/tags/camel-karaf-3.7.7
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel, Camel Spring Boot and Camel
> Karaf 3.7.7
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: Submit your presentation proposals for two ApacheCons!

[Willem Jiang]

I think holding a roundtable discussion in the meeting could be a good
idea if we want to share the user experience of Camel or the latest
development of Camel.
Please ping me if you have any ideas like to share.  I can help to set
up a roundtable session like this in ApacheCon Asia 2021.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Apr 21, 2021 at 3:35 PM Zoran Regvart  wrote:
>
> Hi Cameleers,
> a little reminder, there is less than two weeks left to submit. I
> would like to encourage folk that perhaps have't presented at a
> conference to submit for any of the two upcoming ApacheCons, we're
> very welcoming to folk presenting for the first time.
>
> Also I'd like to reach out to the large Camel user base in Asia,
> please consider submitting for ApacheCon Asia and help spread the word
> about Camel there.
>
> zoran
>
> On Wed, Mar 31, 2021 at 2:07 PM Zoran Regvart  wrote:
> >
> > Hi Cameleers,
> > this year we have two virtual Apache Conferences, one ApacheCon Asia
> > (6-8 of August) and the ApacheCon @Home (21-23 of September). This is
> > an excellent opportunity to share your experience, bring up new ideas
> > and start new conversations about them. Last year's ApacheCon @Home
> > was a personal highlight for me and I hope we can make it even better
> > this year.
> >
> > Please submit your presentation proposals, the CFP is open and you
> > have little over a month. Bit more details and the links to the CFP on
> > the Camel website:
> >
> > https://camel.apache.org/blog/2021/03/ApacheCons2021/
> >
> > Please, also share this with your peers and encourage them to present
> > about that neat or quirky Camel solution or idea they had!
> >
> > zoran
> > --
> > Zoran Regvart
>
>
>
> --
> Zoran Regvart

Re: [VOTE] Release Apache Camel Quarkus 1.8.0

[Willem Jiang]

+1 （binding）

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Mar 26, 2021 at 11:49 PM Peter Palaga  wrote:
>
> Hi,
>
> This is a vote to release Apache Camel Quarkus 1.7.0.
>
> Highlights:
>
> * Camel 3.9.0
> * Quarkus 1.13.0.Final
> * Fixed issues:
>https://github.com/apache/camel-quarkus/milestone/12?closed=1
> * Known issues:
>* https://github.com/apache/camel-quarkus/issues/2207
> * All commits:
>https://github.com/apache/camel-quarkus/compare/1.7.0...1.8.0
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1306
>
> Tag: https://github.com/apache/camel-quarkus/releases/tag/1.8.0
>
> Source release package:
> https://repository.apache.org/content/repositories/orgapachecamel-1306/org/apache/camel/quarkus/camel-quarkus/1.8.0/camel-quarkus-1.8.0-src.zip
>
> As long as Camel 3.9.0 is not publicly available, you have to add its
> staging repo
> https://repository.apache.org/content/repositories/orgapachecamel-1302
> to your settings.xml to be able to test Camel Quarkus 1.8.0.
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel Quarkus 1.8.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Many thanks to all contributors!
>
> -- Peter
>

Re: [VOTE] Release Apache Camel 3.4.5 (LTS)

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Dec 20, 2020 at 3:34 PM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 3.4.5, a new patch release for
> the 3.4.x LTS branch with 25 improvements and fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348825=12311211
>
> == Apache Camel 3.4.5 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1267/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1267/org/apache/camel/apache-camel/3.4.5/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.4.5
>
> == Apache Camel Spring Boot 3.4.5 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1268/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel-spring-boot.git;a=tag;h=refs/tags/camel-spring-boot-3.4.5
>
> == Apache Camel Karaf 3.4.5 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1269/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel-karaf.git;a=tag;h=refs/tags/camel-karaf-3.4.5
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel, Camel Spring Boot and Camel
> Karaf 3.4.5
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel Quarkus 1.0.0-CR3

[Willem Jiang]

Yeah, I'm fine with that now.  Here is my +1.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jul 6, 2020 at 2:06 PM James Netherton  wrote:
>
> I merged: https://github.com/apache/camel-quarkus/pull/1458.
>
> Willem - you're now +1 for the release, right?
>
>
> On Mon, 6 Jul 2020 at 03:11, Willem Jiang  wrote:
> >
> > Done,  I just filled an issue[1] to track it and sent a PR[2] to fix it.
> >
> > [1]https://github.com/apache/camel-quarkus/pull/1455
> > [2]https://github.com/apache/camel-quarkus/pull/1458
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Jul 4, 2020 at 2:38 PM Claus Ibsen  wrote:
> > >
> > > On Sat, Jul 4, 2020 at 3:55 AM Willem Jiang  
> > > wrote:
> > > >
> > > > -1.
> > > > I just checked the source release package[1], there are some binary
> > > > files in the docs/node directory.
> > > > I checked the git repo, there is no docs/node directory.
> > > > As we are not supposed to ship the binary files in the source kit, so
> > > > I vote -1 for this release.
> > > >
> > >
> > > I checked the RC2 and it was also a binary file there.
> > > Can you create a JIRA ticket about this so it can be fixed in RC4.
> > >
> > > Lets this release go ahead - the community wans to get hands on this
> > > with the Camel 3.4 upgrade - and they frankly dont care about a node
> > > binary file.
> > >
> > >
> > >
> > > > [1]https://repository.apache.org/service/local/repositories/orgapachecamel-1224/content/org/apache/camel/quarkus/camel-quarkus/1.0.0-CR3/camel-quarkus-1.0.0-CR3-src.zip
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Fri, Jul 3, 2020 at 5:41 PM Peter Palaga  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > This is a vote to release Apache Camel Quarkus 1.0.0-CR3.
> > > > >
> > > > > Highlights (same as 1.0.0-CR1):
> > > > > * Camel 3.4.0
> > > > > * Quarkus 1.6.0.Final
> > > > > * Fixed issues: 
> > > > > https://github.com/apache/camel-quarkus/milestone/3?closed=1
> > > > >
> > > > > Staging repository:
> > > > > https://repository.apache.org/content/repositories/orgapachecamel-1224
> > > > >
> > > > >
> > > > > Tag:
> > > > > https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=e10cfef86e5c3c6670f87a3c1d877f7ebc54e615
> > > > >
> > > > > Source release package:
> > > > > https://repository.apache.org/service/local/repositories/orgapachecamel-1224/content/org/apache/camel/quarkus/camel-quarkus/1.0.0-CR3/camel-quarkus-1.0.0-CR3-src.zip
> > > > >
> > > > > Please test this release candidate and cast your vote.
> > > > >
> > > > > [ ] +1 Release the binary as Apache Camel Quarkus 1.0.0-CR3
> > > > > [ ] -1 Veto the release (provide specific comments)
> > > > >
> > > > > The vote is open for at least 72 hours.
> > > > >
> > > > > Many thanks to all contributors!
> > > > >
> > > > > -- Peter
> > > > >
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2

Re: [VOTE] Release Apache Camel Quarkus 1.0.0-CR3

[Willem Jiang]

Done,  I just filled an issue[1] to track it and sent a PR[2] to fix it.

[1]https://github.com/apache/camel-quarkus/pull/1455
[2]https://github.com/apache/camel-quarkus/pull/1458


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Jul 4, 2020 at 2:38 PM Claus Ibsen  wrote:
>
> On Sat, Jul 4, 2020 at 3:55 AM Willem Jiang  wrote:
> >
> > -1.
> > I just checked the source release package[1], there are some binary
> > files in the docs/node directory.
> > I checked the git repo, there is no docs/node directory.
> > As we are not supposed to ship the binary files in the source kit, so
> > I vote -1 for this release.
> >
>
> I checked the RC2 and it was also a binary file there.
> Can you create a JIRA ticket about this so it can be fixed in RC4.
>
> Lets this release go ahead - the community wans to get hands on this
> with the Camel 3.4 upgrade - and they frankly dont care about a node
> binary file.
>
>
>
> > [1]https://repository.apache.org/service/local/repositories/orgapachecamel-1224/content/org/apache/camel/quarkus/camel-quarkus/1.0.0-CR3/camel-quarkus-1.0.0-CR3-src.zip
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Jul 3, 2020 at 5:41 PM Peter Palaga  wrote:
> > >
> > > Hi,
> > >
> > > This is a vote to release Apache Camel Quarkus 1.0.0-CR3.
> > >
> > > Highlights (same as 1.0.0-CR1):
> > > * Camel 3.4.0
> > > * Quarkus 1.6.0.Final
> > > * Fixed issues: 
> > > https://github.com/apache/camel-quarkus/milestone/3?closed=1
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachecamel-1224
> > >
> > >
> > > Tag:
> > > https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=e10cfef86e5c3c6670f87a3c1d877f7ebc54e615
> > >
> > > Source release package:
> > > https://repository.apache.org/service/local/repositories/orgapachecamel-1224/content/org/apache/camel/quarkus/camel-quarkus/1.0.0-CR3/camel-quarkus-1.0.0-CR3-src.zip
> > >
> > > Please test this release candidate and cast your vote.
> > >
> > > [ ] +1 Release the binary as Apache Camel Quarkus 1.0.0-CR3
> > > [ ] -1 Veto the release (provide specific comments)
> > >
> > > The vote is open for at least 72 hours.
> > >
> > > Many thanks to all contributors!
> > >
> > > -- Peter
> > >
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: [VOTE] Release Apache Camel Quarkus 1.0.0-CR3

[Willem Jiang]

-1.
I just checked the source release package[1], there are some binary
files in the docs/node directory.
I checked the git repo, there is no docs/node directory.
As we are not supposed to ship the binary files in the source kit, so
I vote -1 for this release.

[1]https://repository.apache.org/service/local/repositories/orgapachecamel-1224/content/org/apache/camel/quarkus/camel-quarkus/1.0.0-CR3/camel-quarkus-1.0.0-CR3-src.zip

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Jul 3, 2020 at 5:41 PM Peter Palaga  wrote:
>
> Hi,
>
> This is a vote to release Apache Camel Quarkus 1.0.0-CR3.
>
> Highlights (same as 1.0.0-CR1):
> * Camel 3.4.0
> * Quarkus 1.6.0.Final
> * Fixed issues: https://github.com/apache/camel-quarkus/milestone/3?closed=1
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1224
>
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=e10cfef86e5c3c6670f87a3c1d877f7ebc54e615
>
> Source release package:
> https://repository.apache.org/service/local/repositories/orgapachecamel-1224/content/org/apache/camel/quarkus/camel-quarkus/1.0.0-CR3/camel-quarkus-1.0.0-CR3-src.zip
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel Quarkus 1.0.0-CR3
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Many thanks to all contributors!
>
> -- Peter
>

Re: [VOTE] Release Apache Camel K 1.0.0-RC1 and Runtime 1.0.9

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Dec 20, 2019 at 8:28 AM Nicola Ferraro  wrote:
>
> Hello all:
>
> This is a combined vote to release Apache Camel K 1.0.0-RC1 and Apache
> Camel K Runtime 1.0.9.
>
> This is the first release candidate of Camel K 1.0.0 containing a lot of
> new features and bug fixes, as explained in the release notes:
> https://github.com/apache/camel-k/issues/1116#issuecomment-567735389
>
> Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1168
> Runtime Tag:
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-parent-1.0.9
>
> Camel K staging repository:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.0.0-RC1/
> Camel K Tag:
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/1.0.0-RC1
>
> 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-RC1 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1168
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel K 1.0.0-RC1 and Apache Camel K
> Runtime 1.0.9
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Nicola Ferraro

Re: [DISCUSS] - camel-examples git repository

[Willem Jiang]

+1.

Just a quick question about the release of example.
Do we need to do the release the example when we update the BOM
version of Camel?

Regards,

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Dec 19, 2019 at 4:55 PM Claus Ibsen  wrote:
>
> Hi
>
> I would like to create a new git repository that only holds our Camel 
> examples.
>
> camel-examples
>
>
> JIRA:
> https://issues.apache.org/jira/browse/CAMEL-13830
>
>
> This has among others the following benefits
>
> 1)
> Easier to find examples (we also add better navigation to it from website)
> One place to look for examples
>
> 2)
> Easy to download and get started.
>
> It's not a massive set of code, as its just examples.
> Its built against a released versions out of the box, so you can clone
> or download via github etc and get started asap, as the example dont
> need to build source code first but just downloads the needed JARs and
> runs.
>
> 3)
> Its easier for contributors to contribute new examples. Not a massive
> code base to manage.
>
> 4)
> Makes us build examples that are using Camel BOM and don't get tied to
> apache camel source code via parent pom.xml or others that makes it
> harder to copy/paste an example for end users to tweak and use on his
> own.
>
> 5)
> We can include examples across our camel repositories, kafka,
> spring-boot, quarkus, karaf, etc.
>
> 6)
> Reduce build time on other Camel repositories as they dont have
> examples as part of their regular build.
>
>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: [VOTE] Release Apache Camel Quarkus 1.0.0-M1

[Willem Jiang]

+1 （binding）

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Dec 4, 2019 at 8:07 PM Andrea Cosentino
 wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel Quarkus 1.0.0-M1
>
> This release contains new extensions, bug fixes and has been updated to 
> Quarkus 1.0.1.Final and Camel 3.0.0
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1165/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=d7ad515770c2e95b4d46223877f8e1eddfc98d85
>
> Source release package:
> https://repository.apache.org/content/repositories/orgapachecamel-1165/org/apache/camel/quarkus/camel-quarkus-parent/1.0.0-M1/camel-quarkus-parent-1.0.0-M1-source-release.zip
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel Quarkus 1.0.0-M1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Andrea
>
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: Next Patch Releases

[Willem Jiang]

+1 for the release of 2.25
Do we maintain the patch release of 2.x for the coming up next year?

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Nov 29, 2019 at 5:54 PM Claus Ibsen  wrote:
>
> On Fri, Nov 29, 2019 at 10:41 AM Andrea Cosentino  wrote:
> >
> > +1 for 2.24.3
> >
> > I think we should plan also a 2.25.0, at least for releasing new stuff on
> > 2.x line.
> >
>
> Yeah it should be the last 2.x release. Maybe do it January 2020.
>
> One thing we can debate is whether Camel 2.25 should be upgraded to
> Spring Boot 2.2.
>
> It takes some effort and maybe some existing 2.x users would like to
> do soft upgrade to 2.25 and SB 2.2.
> If that is the case then it would take some effort to migrate the work
> as its not a simple version change in the pom.xml.
>
> Otherwise I think 2.25 is fine as-is.
>
>
>
> > For 3.0.1, I agree on having it end of year, beginning of new year
> >
> > Thanks Gregor
> >
> > Il giorno ven 29 nov 2019 alle ore 10:16 Claus Ibsen 
> > ha scritto:
> >
> > > On Fri, Nov 29, 2019 at 10:07 AM Gregor Zurowski
> > >  wrote:
> > > >
> > > > Hi Everyone:
> > > >
> > > > The last patch versions were released back in September:
> > > >
> > > > - 2.23.4 was released on 09/22/2019
> > > > - 2.24.2 was released on 09/13/2019
> > > >
> > >
> > > +1 for 2.24.3
> > >
> > > > 2.23.4 was supposed to be the last release for the 2.23.x branch.
> > > > Should we plan another release for the 2.24.x branch?
> > > >
> > > > And I guess we should plan a patch release for 3.0.x in the next few
> > > weeks.
> > > >
> > >
> > > +1 for 3.0.1 end of this year or start of next (depending how quick we
> > > can or want to do it)
> > >
> > >
> > > > Thanks,
> > > > Gregor
> > >
> > >
> > >
> > > --
> > > 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: [VOTE] Release Apache Camel 3.0.0

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Nov 25, 2019 at 4:45 PM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 3.0.0, a new major release with
> 1012 improvements and fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1164/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1164/org/apache/camel/apache-camel/3.0.0/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.0.0
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 3.0.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel K 1.0.0-M3 and Runtime 1.0.5

[Willem Jiang]

+1 （binding).

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Oct 19, 2019 at 7:46 AM Nicola Ferraro  wrote:
>
> Hello all:
>
> This is a combined vote to release Apache Camel K 1.0.0-M3 and Apache Camel
> K Runtime 1.0.5.
>
> Release notes:
> https://github.com/apache/camel-k/issues/1020#issuecomment-543980848
>
> Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1157
> Runtime Tag:
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-parent-1.0.5
>
> Camel K staging repository:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.0.0-M3/
> Camel K Tag:
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/1.0.0-M3
>
> 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-M3 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1157
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel K 1.0.0-M3 and Apache Camel K 
> Runtime
> 1.0.5
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Nicola Ferraro

Re: Camel theme for reveal.js presentations

[Willem Jiang]

Thanks, Peter.
The sample presentation and template are very helpful.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Oct 19, 2019 at 3:03 AM Peter Palaga  wrote:
>
> Hi *,
>
> I created a reveal.js theme [1] inspired by the new Camel web site. Feel
> free to use it.
>
> A sample presentation using the new theme can be found under [2].
>
> Improvements are welcome!
>
> Thanks,
>
> -- Peter
>
> [1] https://github.com/ppalaga/reveal.js-camel
> [2]
> http://ppalaga.github.io/presentations/191017-baselone-camel/index.html#/
>

Re: Apache Camel 3.0-RC3

[Willem Jiang]

+1.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Oct 11, 2019 at 7:20 PM Claus Ibsen  wrote:
>
> Hi
>
> I think it would be good to get one more and last RC out before we go GA.
>
> There has been some work since RC2 that is needed for especially Camel
> K and Camel Quarkus.
> And of course other changes that we have implemented as well.
>
> So if we could get a RC3 out by end of this month, then that gives
> some time for us to stabilize the last bits and get Camel 3 in really
> good shape for GA ... such as end of November. And to give the RC3
> test spins on JDK 8 and 11 and also on various runtimes like Karaf,
> Spring Boot, Camel Main, and whatnot.
>
> The website and documentation also needs some polishing and final
> touches to make it just even better when we launch Camel 3 and
> announces it around on the internet.
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: Camel integration tests

[Willem Jiang]

yeah, it sounds good to me by recording the real services
request/response to mock the online services
I think it could still be part of the component level tests instead of
real integration test, because of the real services API could be
changed and we still need to record the services request and response
again in that case.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Oct 11, 2019 at 4:21 AM Onder SEZGIN  wrote:
>
> +1
>
> On Wed, Oct 9, 2019 at 10:46 AM Jan Bouška  wrote:
>
> > Hi folks,
> > Recently I was thinking about integration tests in Camel project. Of
> > course, we have camel-testcontainers component [1] which can help with
> > integration testing very much using docker containers. But what about
> > services which does not have docker image? For example we can't have
> > facebook-docker image.
> >
> > Most of this third party services are communicating through REST API. I am
> > working on camel-wiremock-test component [2] [3] which is able to record
> > REST API responses and playback during the test.
> >
> > Can you check my PoC with camel-jira [4]? What you think about this
> > approach? Does it worth it?
> >
> > Thanks for your input.
> >
> > Have a nice day.
> > Jan
> >
> > [1]
> > https://github.com/apache/camel/tree/master/components/camel-testcontainers
> > [2]
> >
> > https://github.com/bouskaJ/camel/tree/camel-wiremock/components/camel-wiremock-test
> > [3] http://wiremock.org/
> > [4]
> >
> > https://github.com/bouskaJ/camel/blob/camel-wiremock/components/camel-jira/src/test/java/org/apache/camel/component/jira/it/JiraProducerItTest.java
> >

Re: [VOTE] Release Apache Camel K 1.0.0-M2 and Runtime 1.0.4

[Willem Jiang]

I agree as we already provide the camel-k-runtime source release kit
in maven stage repo[1], we could list it in our next release vote mail
for verification.

Here is my +1 for it.
I just found there is some 1.0.3 SNAPSHOT dependencies in
camel-k-runtime quarkus examples pom, we may list it as a known issue.

[1]https://repository.apache.org/content/repositories/orgapachecamel-1156/org/apache/camel/k/apache-camel-k-runtime/1.0.4/apache-camel-k-runtime-1.0.4-source-release.zip

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Oct 8, 2019 at 5:29 PM Nicola Ferraro  wrote:
>
> Ok, I think we can put the released artifacts in
> https://dist.apache.org/dist/ also for camel-k-runtime, as we do for Camel.
> Don't think there's need to put them while voting, so I will consider the
> voting closed now.
>
> I'll write some docs about the release process.
>
> Nicola
>
> On Tue, Oct 8, 2019 at 10:40 AM Andrea Cosentino  wrote:
>
> > I think you're a bit to picky for a milestone release, Willem.
> >
> > Il giorno mar 8 ott 2019 alle ore 10:36 Willem Jiang <
> > willem.ji...@gmail.com>
> > ha scritto:
> >
> > > Hi Claus,
> > >
> > > The official release distribution channel is
> > > https://dist.apache.org/dist/, according to the documents[1][2].
> > > For the Apache Camel release, we are not only provide the maven nexus
> > > release, but also upload the release kit to dist.apache.org.
> > >
> > > [1]https://www.apache.org/dev/release-distribution#channels
> > > [2]http://www.apache.org/legal/release-policy.html#host-GA
> > >
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Tue, Oct 8, 2019 at 2:47 PM Claus Ibsen 
> > wrote:
> > > >
> > > > Hi
> > > >
> > > > +1
> > > >
> > > > Its a milestone release, lets get it out in the hands of the community.
> > > >
> > > > Willem, you cannot compare Apache Maven (its all just java) to a go
> > > > project like camel-k.
> > > >
> > > > On Tue, Oct 8, 2019 at 2:58 AM Willem Jiang 
> > > wrote:
> > > > >
> > > > > Hi Nicola,
> > > > >
> > > > > The source release kit is the official Apache release that we mainly
> > > > > vote for, we need to make sure that the user can build the binary
> > > > > artifacts from the source kit.
> > > > > The artifacts which is put the https://dist.apache.org/repos/dist/
> > > > > will be mirrored across of the world and will be archived in Apache.
> > > > > There are bunch of other convenience binary release surch as  apache
> > > > > maven or docker hub are based on the official Apache source release
> > to
> > > > > let the user to consume.
> > > > >
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > > > > On Mon, Oct 7, 2019 at 9:57 PM Nicola Ferraro 
> > > wrote:
> > > > > >
> > > > > > Hi Willem,
> > > > > > artifacts for Camel K runtime are released through the standard
> > > Apache
> > > > > > procedure based on Maven that we already use in Camel. We used
> > > dist/dev for
> > > > > > the content of the Camel K go repository because there was no
> > > standard
> > > > > > process already setup. But for the runtime part, sources,
> > signatures
> > > and
> > > > > > sha are in the usual place (staging maven repository):
> > > > > >
> > >
> > https://repository.apache.org/content/repositories/orgapachecamel-1156/org/apache/camel/k/apache-camel-k-runtime/1.0.4/
> > > > > >
> > > > > > I think there's no need to over complicate the release process.
> > > > > >
> > > > > > Nicola
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Oct 7, 2019 at 1:43 PM Willem Jiang <
> > willem.ji...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Hi Nicola,
> > > > > > >
> > > > > > > Thanks for cutting the release kit of camel-k.
> > > > > > > I cannot find the source release of camel-k-runtime from the
>

Re: [VOTE] Release Apache Camel K 1.0.0-M2 and Runtime 1.0.4

[Willem Jiang]

Hi Claus,

The official release distribution channel is
https://dist.apache.org/dist/, according to the documents[1][2].
For the Apache Camel release, we are not only provide the maven nexus
release, but also upload the release kit to dist.apache.org.

[1]https://www.apache.org/dev/release-distribution#channels
[2]http://www.apache.org/legal/release-policy.html#host-GA


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Oct 8, 2019 at 2:47 PM Claus Ibsen  wrote:
>
> Hi
>
> +1
>
> Its a milestone release, lets get it out in the hands of the community.
>
> Willem, you cannot compare Apache Maven (its all just java) to a go
> project like camel-k.
>
> On Tue, Oct 8, 2019 at 2:58 AM Willem Jiang  wrote:
> >
> > Hi Nicola,
> >
> > The source release kit is the official Apache release that we mainly
> > vote for, we need to make sure that the user can build the binary
> > artifacts from the source kit.
> > The artifacts which is put the https://dist.apache.org/repos/dist/
> > will be mirrored across of the world and will be archived in Apache.
> > There are bunch of other convenience binary release surch as  apache
> > maven or docker hub are based on the official Apache source release to
> > let the user to consume.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Oct 7, 2019 at 9:57 PM Nicola Ferraro  wrote:
> > >
> > > Hi Willem,
> > > artifacts for Camel K runtime are released through the standard Apache
> > > procedure based on Maven that we already use in Camel. We used dist/dev 
> > > for
> > > the content of the Camel K go repository because there was no standard
> > > process already setup. But for the runtime part, sources, signatures and
> > > sha are in the usual place (staging maven repository):
> > > https://repository.apache.org/content/repositories/orgapachecamel-1156/org/apache/camel/k/apache-camel-k-runtime/1.0.4/
> > >
> > > I think there's no need to over complicate the release process.
> > >
> > > Nicola
> > >
> > >
> > >
> > > On Mon, Oct 7, 2019 at 1:43 PM Willem Jiang  
> > > wrote:
> > >
> > > > Hi Nicola,
> > > >
> > > > Thanks for cutting the release kit of camel-k.
> > > > I cannot find the source release of camel-k-runtime from the
> > > > dist.apache.org, I guess it's here[1]
> > > > Could you upload the source distribution into
> > > > https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.0.4,
> > > > with the sha512 and asc files?
> > > >
> > > > [1]
> > > > https://repository.apache.org/content/repositories/orgapachecamel-1156/org/apache/camel/k/apache-camel-k-runtime/1.0.4/apache-camel-k-runtime-1.0.4-source-release.zip
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Mon, Oct 7, 2019 at 5:40 PM Nicola Ferraro 
> > > > wrote:
> > > > >
> > > > > Thanks Mohammad for spotting it, I've now added sources to the staging
> > > > repo.
> > > > >
> > > > > Keys used for signing are in the git repo:
> > > > >
> > > > https://github.com/apache/camel-k/blob/ee1b8d34961df9553abc7e364e965f00dbbe2bb0/KEYS#L1661-L1715
> > > > >
> > > > > Nicola
> > > > >
> > > > > On Mon, Oct 7, 2019 at 11:24 AM Mohammad Asif Siddiqui <
> > > > > asifdxtr...@apache.org> wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Suggestions :
> > > > > >  - I cannot find link to KEYS in the voting mail which is used to 
> > > > > > sign
> > > > the
> > > > > > release artifacts.
> > > > > >  - Source Artifacts of camel-k 1.0.0-M2 is missing in dev svn [Major
> > > > > > Issue]
> > > > > >
> > > > > > Regards
> > > > > > Asif
> > > > > > 
> > > > > > ServiceComb PMC Member, Release Manager
> > > > > > Apache IPMC Member
> > > > > >
> > > > > >
> > > > > > On 2019/10/05 10:24:10, Nicola Ferraro  wrote:
> > > > > > > Hello all:
> > > > > &g

Re: [VOTE] Release Apache Camel K 1.0.0-M2 and Runtime 1.0.4

[Willem Jiang]

Hi Nicola,

The source release kit is the official Apache release that we mainly
vote for, we need to make sure that the user can build the binary
artifacts from the source kit.
The artifacts which is put the https://dist.apache.org/repos/dist/
will be mirrored across of the world and will be archived in Apache.
There are bunch of other convenience binary release surch as  apache
maven or docker hub are based on the official Apache source release to
let the user to consume.


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Oct 7, 2019 at 9:57 PM Nicola Ferraro  wrote:
>
> Hi Willem,
> artifacts for Camel K runtime are released through the standard Apache
> procedure based on Maven that we already use in Camel. We used dist/dev for
> the content of the Camel K go repository because there was no standard
> process already setup. But for the runtime part, sources, signatures and
> sha are in the usual place (staging maven repository):
> https://repository.apache.org/content/repositories/orgapachecamel-1156/org/apache/camel/k/apache-camel-k-runtime/1.0.4/
>
> I think there's no need to over complicate the release process.
>
> Nicola
>
>
>
> On Mon, Oct 7, 2019 at 1:43 PM Willem Jiang  wrote:
>
> > Hi Nicola,
> >
> > Thanks for cutting the release kit of camel-k.
> > I cannot find the source release of camel-k-runtime from the
> > dist.apache.org, I guess it's here[1]
> > Could you upload the source distribution into
> > https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.0.4,
> > with the sha512 and asc files?
> >
> > [1]
> > https://repository.apache.org/content/repositories/orgapachecamel-1156/org/apache/camel/k/apache-camel-k-runtime/1.0.4/apache-camel-k-runtime-1.0.4-source-release.zip
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Oct 7, 2019 at 5:40 PM Nicola Ferraro 
> > wrote:
> > >
> > > Thanks Mohammad for spotting it, I've now added sources to the staging
> > repo.
> > >
> > > Keys used for signing are in the git repo:
> > >
> > https://github.com/apache/camel-k/blob/ee1b8d34961df9553abc7e364e965f00dbbe2bb0/KEYS#L1661-L1715
> > >
> > > Nicola
> > >
> > > On Mon, Oct 7, 2019 at 11:24 AM Mohammad Asif Siddiqui <
> > > asifdxtr...@apache.org> wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Suggestions :
> > > >  - I cannot find link to KEYS in the voting mail which is used to sign
> > the
> > > > release artifacts.
> > > >  - Source Artifacts of camel-k 1.0.0-M2 is missing in dev svn [Major
> > > > Issue]
> > > >
> > > > Regards
> > > > Asif
> > > > 
> > > > ServiceComb PMC Member, Release Manager
> > > > Apache IPMC Member
> > > >
> > > >
> > > > On 2019/10/05 10:24:10, Nicola Ferraro  wrote:
> > > > > Hello all:
> > > > >
> > > > > This is a combined vote to release Apache Camel K 1.0.0-M2 and Apache
> > > > Camel
> > > > > K Runtime 1.0.4.
> > > > >
> > > > > Release notes:
> > > > > https://github.com/apache/camel-k/issues/944#issuecomment-538636280
> > > > >
> > > > > Runtime staging repository:
> > > > >
> > https://repository.apache.org/content/repositories/orgapachecamel-1156
> > > > > Runtime Tag:
> > > > >
> > > >
> > https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-parent-1.0.4
> > > > >
> > > > > Camel K staging repository:
> > > > > https://dist.apache.org/repos/dist/dev/camel/camel-k/1.0.0-M2/
> > > > > Camel K Tag:
> > > > >
> > > >
> > https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/1.0.0-M2
> > > > >
> > > > > 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-M2
> > > > --maven-repository=
> > > > >
> > https://repository.apache.org/content/repositories/orgapachecamel-1156
> > > > >
> > > > > Please test this release candidate and cast your vote.
> > > > >
> > > > > [ ] +1 Release the binary as Apache Camel K 1.0.0-M2 and Apache
> > Camel K
> > > > Runtime
> > > > > 1.0.4
> > > > > [ ] -1 Veto the release (provide specific comments)
> > > > >
> > > > > The vote is open for at least 72 hours.
> > > > >
> > > > > Thanks,
> > > > > Nicola Ferraro
> > > > >
> > > >
> >

Re: [VOTE] Release Apache Camel K 1.0.0-M2 and Runtime 1.0.4

[Willem Jiang]

Hi Nicola,

Thanks for cutting the release kit of camel-k.
I cannot find the source release of camel-k-runtime from the
dist.apache.org, I guess it's here[1]
Could you upload the source distribution into
https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.0.4,
with the sha512 and asc files?

[1]https://repository.apache.org/content/repositories/orgapachecamel-1156/org/apache/camel/k/apache-camel-k-runtime/1.0.4/apache-camel-k-runtime-1.0.4-source-release.zip

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Oct 7, 2019 at 5:40 PM Nicola Ferraro  wrote:
>
> Thanks Mohammad for spotting it, I've now added sources to the staging repo.
>
> Keys used for signing are in the git repo:
> https://github.com/apache/camel-k/blob/ee1b8d34961df9553abc7e364e965f00dbbe2bb0/KEYS#L1661-L1715
>
> Nicola
>
> On Mon, Oct 7, 2019 at 11:24 AM Mohammad Asif Siddiqui <
> asifdxtr...@apache.org> wrote:
>
> > +1 (non-binding)
> >
> > Suggestions :
> >  - I cannot find link to KEYS in the voting mail which is used to sign the
> > release artifacts.
> >  - Source Artifacts of camel-k 1.0.0-M2 is missing in dev svn [Major
> > Issue]
> >
> > Regards
> > Asif
> > 
> > ServiceComb PMC Member, Release Manager
> > Apache IPMC Member
> >
> >
> > On 2019/10/05 10:24:10, Nicola Ferraro  wrote:
> > > Hello all:
> > >
> > > This is a combined vote to release Apache Camel K 1.0.0-M2 and Apache
> > Camel
> > > K Runtime 1.0.4.
> > >
> > > Release notes:
> > > https://github.com/apache/camel-k/issues/944#issuecomment-538636280
> > >
> > > Runtime staging repository:
> > > https://repository.apache.org/content/repositories/orgapachecamel-1156
> > > Runtime Tag:
> > >
> > https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-parent-1.0.4
> > >
> > > Camel K staging repository:
> > > https://dist.apache.org/repos/dist/dev/camel/camel-k/1.0.0-M2/
> > > Camel K Tag:
> > >
> > https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/1.0.0-M2
> > >
> > > 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-M2
> > --maven-repository=
> > > https://repository.apache.org/content/repositories/orgapachecamel-1156
> > >
> > > Please test this release candidate and cast your vote.
> > >
> > > [ ] +1 Release the binary as Apache Camel K 1.0.0-M2 and Apache Camel K
> > Runtime
> > > 1.0.4
> > > [ ] -1 Veto the release (provide specific comments)
> > >
> > > The vote is open for at least 72 hours.
> > >
> > > Thanks,
> > > Nicola Ferraro
> > >
> >

Re: Notifications from camel-k & camel-quarkus github repos

[Willem Jiang]

We could ask Apache Infra to forward the github notification to
commits or notification mailing list instead of flood the dev mailing
list.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Oct 7, 2019 at 1:33 PM Tadayoshi Sato  wrote:
>
> Hi folks,
>
> I've just realised that this dev mailing list is receiving a huge amount of
> notifications from camel-k & camel-quarkus github repositories. I am a bit
> afraid that this overwhelms the actually discussions on camel development
> here and perhaps is making some who are willing to get involved in the dev
> discussions but not yet ready to be interested in camel-k & camel-quarkus
> developments scared of the mailing list and even be leaving.
>
> For github activities I think those who are interested in the dev of
> camel-k & camel-quarkus are already 'watch'ing the repos so they should get
> notified already, so it doesn't seem to make sense to route them to this
> mailing list as well.
>
> What do you think?  Is there any way to mitigate this?
>
> Best regards,

Re: [VOTE] Release Apache Camel Quarkus 0.2.0

[Willem Jiang]

+1.

For the Tag it could be better to use hash number, as the git tags
could be changed without notice.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Sep 23, 2019 at 3:12 PM Andrea Cosentino
 wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel Quarkus 0.2.0
>
> This release contains new extensions and it has been updated to Camel 
> 3.0.0-RC1 and Quarkus 0.22.0.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1153/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=refs/tags/0.2.0
>
> Source release package:
> https://repository.apache.org/content/repositories/orgapachecamel-1153/org/apache/camel/quarkus/camel-quarkus-parent/0.2.0/camel-quarkus-parent-0.2.0-source-release.zip
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel Quarkus 0.2.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Andrea
>
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: [VOTE] Release Apache Camel 3.0.0-RC1 (Release Candidate 1)

[Willem Jiang]

+1 （binding）

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Aug 27, 2019 at 2:51 PM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 3.0.0-RC1, the first release
> candidate towards a new 3.0.0 major release with 148 improvements and
> fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12345723=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1149/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1149/org/apache/camel/apache-camel/3.0.0-RC1/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.0.0-RC1
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 3.0.0-RC1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: Google Search Console access

[Willem Jiang]

Please add me in.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Aug 21, 2019 at 3:07 PM Zoran Regvart  wrote:
>
> Hi Cameleers,
> I have access to Google Search Console and I can add more users
> providing that they have a Google account let me know if you want
> access.
>
> I'm think we should limit this access to PMC members only.
>
> zoran
> --
> Zoran Regvart

Re: Apache Camel 3.0 RC1

[Willem Jiang]

Thanks for the migration guide, it's really helpful for the user
switch Camel 3.x.
Maybe we can add a migration guide link in the release page of Camel
3.0 to let people to find out it when they look for the release kit.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Aug 11, 2019 at 8:12 AM Andrea Cosentino  wrote:
>
> https://github.com/apache/camel/blob/master/MIGRATION.md
>
> Il dom 11 ago 2019, 02:07 Andrea Cosentino  ha scritto:
>
> > Look at the MIGRATION.md file in the git repo
> >
> > Il dom 11 ago 2019, 02:06 Willem Jiang  ha
> > scritto:
> >
> >> Hi Claus,
> >>
> >> Thanks for summarized all these new features of Camel 3.0.  +1 for
> >> cutting a new release candidate of Camel 3.0.
> >> I try to find some migration guide for user from Camel 2.x to Camel
> >> 3.x ,  but now I can only find some release notes which are generated
> >> from JIRA. Is there anything that I'm missing?
> >>
> >> Willem Jiang
> >>
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem
> >>
> >> On Sat, Aug 10, 2019 at 9:14 PM Claus Ibsen 
> >> wrote:
> >> >
> >> > Camel 3.0 Release Candidate 1
> >> > 
> >> >
> >> > I think its time we should close down on the Camel 3.0 release
> >> > and get out first release candidate out.
> >> >
> >> > The CI server has been looking good lately, we had a few bumps the
> >> > last couple of builds due some new changes. But the next build is
> >> > expected to pass
> >> > https://builds.apache.org/job/Camel/job/master/
> >> >
> >> >
> >> >
> >> > Since the milestone 4 release we have done a number of noteworthy
> >> improvements:
> >> >
> >> > 1)
> >> > Renamed components to use normalised names, eg http4 -> http, quartz2
> >> > -> quartz, etc.
> >> > This gives us a "fresh start" on Camel 3.
> >> >
> >> > 2)
> >> > Introduced JUnit 5 support with the new camel-test-junit5 (more work to
> >> come).
> >> >
> >> > 3)
> >> > Improved properties component to by default work better in
> >> > container/cloud's where
> >> > ENV variables can override configurations.
> >> >
> >> > 4)
> >> > You can now configure MDC logging to propagste more or all keys by
> >> patterns.
> >> >
> >> > 5)
> >> > Mock endpoints will now fail fast on first arrived message that fails
> >> > an expecations.
> >> > Beforehand they may on fail after assertion timeout.
> >> >
> >> > 6)
> >> > Fixed an issue with auto configuring Map types in
> >> > application.properties with Camel Spring Boot
> >> >
> >> > 6)
> >> > Intercept send to endpoint can now invoke an after processor that
> >> > allows to do before/after processing.
> >> >
> >> > 7)
> >> > Testing with advice with now support advicing onException and
> >> interceptors.
> >> >
> >> > 8)
> >> > Added new tracer implementation
> >> >
> >> >
> >> > In addition there are other changes and bug fixes, new components,
> >> > etc. And we had some API changes such as deprecating the OUT message
> >> > on Exchange (use getMessage), and the attachment API was externalised
> >> > to camel-attachments etc. So the modularisation of camel-core was
> >> > further improve a bit. We have also improve startup of Camel to avoid
> >> > doing some try .. catch ignore exceptions.
> >> >
> >> >
> >> > You can find all the JIRA tickets for this release at:
> >> > https://issues.apache.org/jira/projects/CAMEL/versions/12345723
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Claus Ibsen
> >> > -
> >> > http://davsclaus.com @davsclaus
> >> > Camel in Action 2: https://www.manning.com/ibsen2
> >>
> >

Re: Apache Camel 3.0 RC1

[Willem Jiang]

Hi Claus,

Thanks for summarized all these new features of Camel 3.0.  +1 for
cutting a new release candidate of Camel 3.0.
I try to find some migration guide for user from Camel 2.x to Camel
3.x ,  but now I can only find some release notes which are generated
from JIRA. Is there anything that I'm missing?

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Aug 10, 2019 at 9:14 PM Claus Ibsen  wrote:
>
> Camel 3.0 Release Candidate 1
> 
>
> I think its time we should close down on the Camel 3.0 release
> and get out first release candidate out.
>
> The CI server has been looking good lately, we had a few bumps the
> last couple of builds due some new changes. But the next build is
> expected to pass
> https://builds.apache.org/job/Camel/job/master/
>
>
>
> Since the milestone 4 release we have done a number of noteworthy 
> improvements:
>
> 1)
> Renamed components to use normalised names, eg http4 -> http, quartz2
> -> quartz, etc.
> This gives us a "fresh start" on Camel 3.
>
> 2)
> Introduced JUnit 5 support with the new camel-test-junit5 (more work to come).
>
> 3)
> Improved properties component to by default work better in
> container/cloud's where
> ENV variables can override configurations.
>
> 4)
> You can now configure MDC logging to propagste more or all keys by patterns.
>
> 5)
> Mock endpoints will now fail fast on first arrived message that fails
> an expecations.
> Beforehand they may on fail after assertion timeout.
>
> 6)
> Fixed an issue with auto configuring Map types in
> application.properties with Camel Spring Boot
>
> 6)
> Intercept send to endpoint can now invoke an after processor that
> allows to do before/after processing.
>
> 7)
> Testing with advice with now support advicing onException and interceptors.
>
> 8)
> Added new tracer implementation
>
>
> In addition there are other changes and bug fixes, new components,
> etc. And we had some API changes such as deprecating the OUT message
> on Exchange (use getMessage), and the attachment API was externalised
> to camel-attachments etc. So the modularisation of camel-core was
> further improve a bit. We have also improve startup of Camel to avoid
> doing some try .. catch ignore exceptions.
>
>
> You can find all the JIRA tickets for this release at:
> https://issues.apache.org/jira/projects/CAMEL/versions/12345723
>
>
>
>
>
>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: [VOTE] Release Apache Camel Quarkus 0.1.0

[Willem Jiang]

+1.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Aug 7, 2019 at 3:39 PM Andrea Cosentino
 wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel Quarkus 0.1.0
>
> This is the second release of the camel-quarkus project which contains new 
> extensions and it has been updated to Camel Milestone 4.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1147/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=refs/tags/0.1.0
>
> Source release package:
> https://repository.apache.org/content/repositories/orgapachecamel-1147/org/apache/camel/quarkus/camel-quarkus-parent/0.1.0/camel-quarkus-parent-0.1.0-source-release.zip
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel Quarkus 0.1.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Andrea
>
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: JUnit 5 support in camel

[Willem Jiang]

It looks like we cannot replace camel-test module right now.
+1 with camel-test-junit5.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Aug 7, 2019 at 10:29 PM Alex Dettinger  wrote:
>
> Hey Zoran,
>
>   Thanks for bringing the version neutral name topic to this discussion.
> As far as I can tell, the next major release of junit could even introduce
> a new api with yet another name than jupiter.
> But, then a good name could be camel-junit alone.
>
>   At this stage I would support camel-test-junit5 as I think users will
> find it clearer to know what is under the hood.
> If anyone has new elements to bring, feel free to let us know. We still
> have time to enrich our rationale.
>
> Alex
>
>
>
> On Wed, Aug 7, 2019 at 11:57 AM Zoran Regvart  wrote:
>
> > Hi Cameleers,
> > I brought up the issue of naming the JUnit 5 component without the
> > version and with 'jupiter' instead. The reason I brought this up is
> > because I think that we should shield the users from version changes
> > as much as possible. A version neutral name would allow us to move to
> > a future JUnit version without any migration step required for the
> > user, well, depending on the amount of backward breaking changes in
> > the future version. I'm afraid that we'll then create -junit6
> > component when that version is released.
> >
> > I don't mind if it's called -junit5, I would prefer if it didn't
> > include any version information for the reason stated above.
> >
> > zoran
> >
> > On Tue, Aug 6, 2019 at 5:08 PM Alex Dettinger 
> > wrote:
> > >
> > > Hi guys,
> > >
> > >   I've started the development of a new module adding the possibility to
> > > write base camel-test with JUnit5. So far, I've named the module
> > > camel-test-junit5, which would lead to a family of name like
> > > camel-test-junit5-spring, camel-test-junit5-spring-boot...
> > >
> > >   I would like to trigger a discussion around the naming of this module
> > as
> > > other candidate are also valid. For instance:
> > >   camel-test-jupiter
> > >  camel-test-junit-jupiter
> > >
> > >
> > > https://github.com/apache/camel/pull/3084
> > > https://issues.apache.org/jira/browse/CAMEL-13826
> >
> >
> >
> > --
> > Zoran Regvart
> >

Re: [HEADS UP] - camel3 - camel-http4 renaming to camel-http

[Willem Jiang]

+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

Re: [HEADSUP] Documentation link checker in the build

[Willem Jiang]

Yeah，that's is what I'm tallking about.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Jul 24, 2019 at 9:22 AM Zheng Feng  wrote:
>
> Thanks for the update and it is great job !
>
> Willem, I think you were thinking to add the pre-push hook script to do
> verifying before pushing ?
>
> On Wed, Jul 24, 2019 at 8:55 AM Willem Jiang  wrote:
>
> > Hi Zoran,
> >
> > Thanks for the heads up, it's a great job.
> > I'm not sure if we can setup a git push-check-out[1] script by running
> > the command of "./mvnw -f docs verify" to make sure we do the clean up
> > work before pushing the change to the remote repository.
> > Any thoughts?
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Jul 24, 2019 at 2:11 AM Zoran Regvart  wrote:
> > >
> > > Hi Cameleers,
> > > I've added a `xref-validator`[1] to the `docs` module[2], this will
> > > fail the build if there's a `xref` link in the asciidoc files (.adoc)
> > > that cannot be resolved -- colloquially: broken link.
> > >
> > > There's been a great effort by Nayananga our GSoC student helping with
> > > the website on getting all the links pointing to the right places and
> > > it's really easy to mistype a `xref` link, so that's why I've added it
> > > as a part of the CAMEL-13589[3].
> > >
> > > Now, you might be wondering what are `xref` links and how to prevent
> > > them from becoming broken. For Antora, the tool that converts the
> > > asciidoc files to html, we need to specify all links between asciidoc
> > > files as `xref:` links, previously you might have seen `link:` being
> > > used.
> > >
> > > There's a good explanation of this concept of page ID in the Antora
> > > documentation[4] and how to link between two pages using `xref:`
> > > links[5].
> > >
> > > For now remember that if you're pointing to the documentation within
> > > the same Antora component, and we have two such components `manual`[6]
> > > and `components`[7], use the form `xref:document.adoc`; and between
> > > two Antora components use the form `xref:component::document.adoc`.
> > >
> > > For example, the cdi.adoc is within the `components` component and
> > > when it needs to link to a `camel-maven-archetypes.adoc` in the
> > > `manual` component the xref needs to look like:
> > >
> > > xref:manual::camel-maven-archetypes.adoc[Maven archetypes]
> > >
> > > Have a look at the example[8] in the git repository.
> > >
> > > So to test if the xrefs are valid you can run:
> > >
> > > $ ./mvnw -f docs verify
> > >
> > > It only takes about 1 minute or so to run.
> > >
> > > Feel free to reach out to me if you have any questions on this.
> > >
> > > zoran
> > >
> > > [1] https://gitlab.com/antora/xref-validator
> > > [2]
> > https://github.com/apache/camel/blob/a607098a51cdde9eb87bf8dcc61c9428dd771dd4/docs/pom.xml#L85-L96
> > > [3] https://issues.apache.org/jira/browse/CAMEL-13589
> > > [4] https://docs.antora.org/antora/2.0/page/page-id/
> > > [5] https://docs.antora.org/antora/2.0/asciidoc/page-to-page-xref/
> > > [6]
> > https://github.com/apache/camel/tree/master/docs/user-manual/modules/ROOT/pages
> > > [7]
> > https://github.com/apache/camel/tree/master/docs/components/modules/ROOT/pages
> > > [8]
> > https://github.com/apache/camel/blob/a607098a51cdde9eb87bf8dcc61c9428dd771dd4/docs/components/modules/ROOT/pages/cdi.adoc#L1071
> > > --
> > > Zoran Regvart
> >

Re: Time for Camel K 1.0.0 M1

[Willem Jiang]

+1 it looks good to me.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Jul 23, 2019 at 7:34 PM Nicola Ferraro  wrote:
>
> Hello all,
> the main Camel project is progressing towards version 3.0.0 with milestone
> releases, so I think it's time to do the same also on Camel K.
>
> It's more than 1 month that we don't release. I've setup a 1.0.0-M1
> milestone release on Github, tracking issues that we want to be fixed for
> first milestone: https://github.com/apache/camel-k/milestone/3
>
> Please add your issues, I'll cut a release when the backlog is empty.
>
> Nicola

Re: [HEADSUP] Documentation link checker in the build

[Willem Jiang]

Hi Zoran,

Thanks for the heads up, it's a great job.
I'm not sure if we can setup a git push-check-out[1] script by running
the command of "./mvnw -f docs verify" to make sure we do the clean up
work before pushing the change to the remote repository.
Any thoughts?

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Jul 24, 2019 at 2:11 AM Zoran Regvart  wrote:
>
> Hi Cameleers,
> I've added a `xref-validator`[1] to the `docs` module[2], this will
> fail the build if there's a `xref` link in the asciidoc files (.adoc)
> that cannot be resolved -- colloquially: broken link.
>
> There's been a great effort by Nayananga our GSoC student helping with
> the website on getting all the links pointing to the right places and
> it's really easy to mistype a `xref` link, so that's why I've added it
> as a part of the CAMEL-13589[3].
>
> Now, you might be wondering what are `xref` links and how to prevent
> them from becoming broken. For Antora, the tool that converts the
> asciidoc files to html, we need to specify all links between asciidoc
> files as `xref:` links, previously you might have seen `link:` being
> used.
>
> There's a good explanation of this concept of page ID in the Antora
> documentation[4] and how to link between two pages using `xref:`
> links[5].
>
> For now remember that if you're pointing to the documentation within
> the same Antora component, and we have two such components `manual`[6]
> and `components`[7], use the form `xref:document.adoc`; and between
> two Antora components use the form `xref:component::document.adoc`.
>
> For example, the cdi.adoc is within the `components` component and
> when it needs to link to a `camel-maven-archetypes.adoc` in the
> `manual` component the xref needs to look like:
>
> xref:manual::camel-maven-archetypes.adoc[Maven archetypes]
>
> Have a look at the example[8] in the git repository.
>
> So to test if the xrefs are valid you can run:
>
> $ ./mvnw -f docs verify
>
> It only takes about 1 minute or so to run.
>
> Feel free to reach out to me if you have any questions on this.
>
> zoran
>
> [1] https://gitlab.com/antora/xref-validator
> [2] 
> https://github.com/apache/camel/blob/a607098a51cdde9eb87bf8dcc61c9428dd771dd4/docs/pom.xml#L85-L96
> [3] https://issues.apache.org/jira/browse/CAMEL-13589
> [4] https://docs.antora.org/antora/2.0/page/page-id/
> [5] https://docs.antora.org/antora/2.0/asciidoc/page-to-page-xref/
> [6] 
> https://github.com/apache/camel/tree/master/docs/user-manual/modules/ROOT/pages
> [7] 
> https://github.com/apache/camel/tree/master/docs/components/modules/ROOT/pages
> [8] 
> https://github.com/apache/camel/blob/a607098a51cdde9eb87bf8dcc61c9428dd771dd4/docs/components/modules/ROOT/pages/cdi.adoc#L1071
> --
> Zoran Regvart

Re: Build startup speed

[Willem Jiang]

Hi Guillaume,

I checked the PR[1], the dependencies of camel components in the
bom/camel-bom/pom.xml were removed.
Please double check it if I missed anything.

[1]https://github.com/apache/camel/pull/3009

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jul 1, 2019 at 8:31 PM Guillaume Nodet  wrote:
>
> 'm not talking about modifying the camel-bom, but the camel-parent.  So
> this should mostly affect project that inherit from camel-parent, and I
> don't think that's the correct way of using camel, users should import the
> bom instead, since CAMEL-8502.
>
> Le lun. 1 juil. 2019 à 14:25, Willem Jiang  a
> écrit :
>
> > When user use the bom file, they don't need to specify the version of
> > camel-xxx component.
> > If we remove the dependency management section form  BOM, the old
> > pom.xml may not work any more.
> > They need to specify the camel version for the camel-xxx component in
> > their pom.
> >
> > We need to inform the end user in the migration document, if we merged the
> > PR.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Jul 1, 2019 at 8:10 PM Guillaume Nodet  wrote:
> > >
> > > I've been spending quite some time last week to try to improve the time
> > > spent by maven before actually starting building something.
> > > I've opened a few PR on maven which should reduce by 50% the time, but I
> > > noticed that a lot of time is spent because the camel parent pom has 800
> > > dependencies in the dependency management section.
> > > So I was wondering if we should remove the camel modules from the
> > > dependency management section.  I experimented that, so this is available
> > > at
> > >   https://github.com/apache/camel/pull/3009
> > > With the above , the execution of `mvn foo` (which fails fast) goes from
> > 54
> > > seconds to 39 seconds. With the addition maven PRs, it goes down to 28
> > > seconds.
> > > Thoughts ?
> > >
> > > --
> > > 
> > > Guillaume Nodet
> >
>
>
> --
> 
> Guillaume Nodet

Re: Build startup speed

[Willem Jiang]

When user use the bom file, they don't need to specify the version of
camel-xxx component.
If we remove the dependency management section form  BOM, the old
pom.xml may not work any more.
They need to specify the camel version for the camel-xxx component in their pom.

We need to inform the end user in the migration document, if we merged the PR.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jul 1, 2019 at 8:10 PM Guillaume Nodet  wrote:
>
> I've been spending quite some time last week to try to improve the time
> spent by maven before actually starting building something.
> I've opened a few PR on maven which should reduce by 50% the time, but I
> noticed that a lot of time is spent because the camel parent pom has 800
> dependencies in the dependency management section.
> So I was wondering if we should remove the camel modules from the
> dependency management section.  I experimented that, so this is available
> at
>   https://github.com/apache/camel/pull/3009
> With the above , the execution of `mvn foo` (which fails fast) goes from 54
> seconds to 39 seconds. With the addition maven PRs, it goes down to 28
> seconds.
> Thoughts ?
>
> --
> 
> Guillaume Nodet

Re: Quarkus

[Willem Jiang]

Hi Peter，

Thanks for the clarification,  in this case you don't need to do any paperwork.
Happy hacking camel quarkus code :)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jul 1, 2019 at 5:54 PM Peter Palaga  wrote:
>
> Hi Willem,
>
> I signed the ICLA on 2012-02-20 when I was active in another ASF
> project. So I hope there is nothing else I should do now?
>
> Thanks,
>
> -- Peter
>
> On 01/07/2019 03:57, Willem Jiang wrote:
> > Hi,
> >
> > I just went through the code commit logs of quarkus camel extension,
> > lots of commits are from Apache Camel committer (gnodet) and ppalaga
> > is the main maintainer.
> > It's clear that Redhat has the copyright. As Red Hat has the CLA with
> > ASF, it make sense that a Red Hat employee who is Camel committer to
> > transfer the code to Apache Camel.
> >
> > If I remembered right, we accepted the new component donation from
> > JIRA with iCLA granted. When moving to the github PRs, I'm not sure if
> > we go through the iCLA check any more.
> > If the contribution is big enough (more than 100 lines in my mind), we
> > still need to the iCLA for the contributor who is new to ASF.
> >
> > I just fill a JIRA[1] to add github pull request template to Camel
> > repo for the user to send a PR. Please feel free to polish the PR
> > template by adding comments on the JIRA.
> >
> > [1]https://issues.apache.org/jira/browse/CAMEL-13704
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> > On Thu, Jun 6, 2019 at 11:06 PM Hiram Chirino  
> > wrote:
> >>
> >> I'm not sure this is much different from a new camel component
> >> contribution.  The whole Quarkus project is not being donated, this just
> >> the camel integration with Quarkus.  It was mostly worked on by camel
> >> committers.  I think that a Red Hat employee that's a Camel comitter should
> >> be able to contribute this code to camel like other components get donated
> >> periodically.  If we can't find a committer that is confident it's 100% Red
> >> Hat copyright, then yeah let's go through the ip-clearance.
> >>
> >> On Tue, Jun 4, 2019 at 6:34 AM Willem Jiang  wrote:
> >>
> >>> +1 for working with Quarkus to make the Camel Application more light and
> >>> fast.
> >>>
> >>> For the code donation part, we need to go through the IP clearance
> >>> process[1].
> >>> Please let me know if you have any questions about this.
> >>>
> >>> [1]https://incubator.apache.org/ip-clearance/
> >>>
> >>> Willem Jiang
> >>>
> >>> Twitter: willemjiang
> >>> Weibo: 姜宁willem
> >>>
> >>> On Tue, Jun 4, 2019 at 5:45 PM Luca Burgazzoli 
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> In the past months some folks at Red Hat have been working on the
> >>>> integration between Apache Camel and Quarkus. For those not familiar
> >>>> with the topic, Quarkus is a new Apache 2 licensed Cloud Native Java
> >>>> framework tailored for GraalVM and HotSpot that bring fast startup
> >>>> and low memory footprint to Java based application by leverage clever
> >>>> build time optimizations and AOT compilation through Substrate VM [1].
> >>>>
> >>>> The result of the experimentation is available in the Quarkus
> >>>> repository [2][3] and I’m also working on an experimental branch
> >>>> on Camel K [4] to bring Quarkus on the K side based on my latest
> >>>> blog “Adventures in GraalVM: polyglot Camel (k) native routes
> >>>> with Quarkus”  [5]
> >>>>
> >>>> I do believe that both communities can benefit from a collaboration:
> >>>>
> >>>> Apache Camel can benefit from Quarkus to become
> >>>> a) Even more suitable for microservices
> >>>> b) Suitable for serverless workloads as Quarkus among others enables
> >>>> built-time warmup of the Camel Context, and elimination of dead-code
> >>>> (code that was only used during warmup) which is a key enabler for
> >>>> very fast start-up and low memory footprint Apache Camel can be on
> >>>> the innovative forefront with a cloud native Java stack for running
> >>>> modern serverless workloads on Kubernetes/Knative with Camel K and
> >>>> Camel Quarkus
> >>>>

Re: Quarkus

[Willem Jiang]

Hi,

I just went through the code commit logs of quarkus camel extension,
lots of commits are from Apache Camel committer (gnodet) and ppalaga
is the main maintainer.
It's clear that Redhat has the copyright. As Red Hat has the CLA with
ASF, it make sense that a Red Hat employee who is Camel committer to
transfer the code to Apache Camel.

If I remembered right, we accepted the new component donation from
JIRA with iCLA granted. When moving to the github PRs, I'm not sure if
we go through the iCLA check any more.
If the contribution is big enough (more than 100 lines in my mind), we
still need to the iCLA for the contributor who is new to ASF.

I just fill a JIRA[1] to add github pull request template to Camel
repo for the user to send a PR. Please feel free to polish the PR
template by adding comments on the JIRA.

[1]https://issues.apache.org/jira/browse/CAMEL-13704

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Jun 6, 2019 at 11:06 PM Hiram Chirino  wrote:
>
> I'm not sure this is much different from a new camel component
> contribution.  The whole Quarkus project is not being donated, this just
> the camel integration with Quarkus.  It was mostly worked on by camel
> committers.  I think that a Red Hat employee that's a Camel comitter should
> be able to contribute this code to camel like other components get donated
> periodically.  If we can't find a committer that is confident it's 100% Red
> Hat copyright, then yeah let's go through the ip-clearance.
>
> On Tue, Jun 4, 2019 at 6:34 AM Willem Jiang  wrote:
>
> > +1 for working with Quarkus to make the Camel Application more light and
> > fast.
> >
> > For the code donation part, we need to go through the IP clearance
> > process[1].
> > Please let me know if you have any questions about this.
> >
> > [1]https://incubator.apache.org/ip-clearance/
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Tue, Jun 4, 2019 at 5:45 PM Luca Burgazzoli 
> > wrote:
> > >
> > > Hi,
> > >
> > > In the past months some folks at Red Hat have been working on the
> > > integration between Apache Camel and Quarkus. For those not familiar
> > > with the topic, Quarkus is a new Apache 2 licensed Cloud Native Java
> > > framework tailored for GraalVM and HotSpot that bring fast startup
> > > and low memory footprint to Java based application by leverage clever
> > > build time optimizations and AOT compilation through Substrate VM [1].
> > >
> > > The result of the experimentation is available in the Quarkus
> > > repository [2][3] and I’m also working on an experimental branch
> > > on Camel K [4] to bring Quarkus on the K side based on my latest
> > > blog “Adventures in GraalVM: polyglot Camel (k) native routes
> > > with Quarkus”  [5]
> > >
> > > I do believe that both communities can benefit from a collaboration:
> > >
> > > Apache Camel can benefit from Quarkus to become
> > > a) Even more suitable for microservices
> > > b) Suitable for serverless workloads as Quarkus among others enables
> > >built-time warmup of the Camel Context, and elimination of dead-code
> > >(code that was only used during warmup) which is a key enabler for
> > >very fast start-up and low memory footprint Apache Camel can be on
> > >the innovative forefront with a cloud native Java stack for running
> > >modern serverless workloads on Kubernetes/Knative with Camel K and
> > >Camel Quarkus
> > >
> > > So I’m proposing to officially support Quarkus in Apache Camel’s main
> > > repository (or a dedicated one if it suits better) by creating a new
> > > platform along with those we support as today (Spring Boot, Karaf).
> > >
> > > Quarkus’ people is keen to donate the code related to Apache Camel
> > > hosted in theirs repository to the Apache Software foundation.
> > >
> > > There has been some other users in the community whom have tried
> > > Quarkus and Camel together and written blogs [6] about their experience,
> > > and Claus also posted a quick gif animation of native compiled Camel
> > > with Quarkus starting up in 7 milliseconds and taking up only 15mb
> > > of memory [7].
> > >
> > > Thoughts ?
> > >
> > > Luca
> > >
> > > [1] https://quarkus.io/
> > > [2] https://github.com/quarkusio/quarkus/tree/master/extensions/camel
> > > [3]
> > https://github.com/quarkusio/quarkus-quickstarts/tree/master/camel-java
> > > [4]
> > >
> > https://github.com/lburgazzoli/apache-camel-k-runtime/tree/quarkus-runtime
> > > [5] https://bit.ly/2HvOrh0
> > > [6] https://bit.ly/2WDtCbW
> > > [7]
> > >
> > https://www.linkedin.com/feed/update/urn:li:activity:6521869236153970688/
> > >
> > > ---
> > > Luca Burgazzoli
> >
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

Re: Quarkus

[Willem Jiang]

Thanks for the information.
I saw there are some PRs from Peter in the camel-quarkus.
I'm not sure if Peter already signed the  iCLA[1], if not we need it
for mass code transferation.

[1] https://www.apache.org/licenses/icla.pdf

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Jun 19, 2019 at 6:22 PM Peter Palaga  wrote:
>
> Hi Again,
>
> just a heads up that the topic of moving Camel extensions away from the
> Quarkus source tree and generally how such externally developed
> extensions can live within the Quarkus ecosystem is discussed on
> quarkus-dev mailing list:
> https://groups.google.com/forum/#!topic/quarkus-dev/yeo0yvC48zA
>
> Thanks,
>
> -- Peter
>
> On 05/06/2019 07:15, Tadayoshi Sato wrote:
> > Hi folks,
> >
> > I like Peter's idea on having a separate repository for camel-quarkus.
> >
> > In addition to his point, I would add that Quarkus is a newly born, cutting
> > edge technology, which itself should evolve fast and likely may not keep
> > how it works now for long as we see in, say, Node.js community. Having a
> > separate repository should let us experiment fast as well and catch up with
> > the rapid evolution in Quarkus without touching the main Camel codebase.
> >
> > On Tue, Jun 4, 2019 at 8:07 PM Peter Palaga  wrote:
> >
> >> Hi,
> >>
> >> I am fully welcoming the initiative to donate the code of Camel Quarkus
> >> extensions that currently live in Quarkus git repository [1] to Apache
> >> Camel community. I believe that's where the code can attract much more
> >> interested developers and users.
> >>
> >> I recently ported a couple of Camel components to Quarkus [2][3] and I
> >> plan to port more in the future.
> >>
> >> I'd like to express my opinion on which git repository should be the
> >> final home for that code.
> >>
> >> As Luca mentioned, there are two options there:
> >>
> >> (a) Apache Camel’s main git repository [4] or
> >> (b) A new separate repository under Apache organization.
> >>
> >> I am clearly in favor of (b) and my reasons for that revolve around the
> >> fact that the Camel main repository currently has 824 Maven modules.
> >> That size has a number of negative impacts on developers day-to-day life:
> >>
> >> * It takes tens of minutes to build without tests and hours with tests.
> >> * Full test suite cannot be run on each pull request and broken master
> >> is a possible consequence
> >> * I was told it is practically not viable to import that big source tree
> >> into IntelliJ (I am not IntelliJ user). Given enough memory, Eclipse can
> >> now import the whole source tree in a reasonable time [5]. Anyway,
> >> working with it feels rather slow.
> >>
> >> Adding more modules to support Quarkus would make the situation even worse.
> >>
> >> Having a separate repo for the Camel Quarkus extensions would make the
> >> life easier for both folks working on the Camel side (smaller source
> >> tree) and on the camel-quarkus side (faster dev builds, faster CI, more
> >> control over the supported Camel version).
> >>
> >> I prepared a proof of concept how such a separate repository could look
> >> like: https://github.com/ppalaga/camel-quarkus
> >>
> >> For the bleeding edge development work the repo is using srcdeps [6][7]
> >> to manage non-released dependencies of Apache Camel and Quarkus. srcdeps
> >> allows for declaring dependencies in terms of git commit sha1s instead
> >> of versions present in remote Maven repositories.
> >>
> >> srcdeps is able to reduce the Maven module hierarchy of the dependency
> >> project to only those modules required by the current repository. Thanks
> >> to this, only 62 Camel modules need to be built to satisfy
> >> camel-quarkus. Building those 62 Camel modules takes about two and a
> >> half minutes on my laptop.
> >> I am listing various build times of the camel-quarkus repo in the readme
> >> [8]
> >>
> >>
> >> [1] https://github.com/quarkusio/quarkus/tree/master/extensions/camel
> >> [2] https://github.com/quarkusio/quarkus/pull/2542
> >> [3] https://github.com/quarkusio/quarkus/pull/2361
> >> [4] https://github.com/apache/camel
> >> [5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668
> >> [6] https://github.com/srcdeps/srcdeps-maven
> >> [7] http://ppalaga.github.io/presentations/181011-jcon-duesseldorf
> >> [8] https://github.com/ppalaga/

Re: [VOTE] Release Apache Camel 2.24.1

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Jun 21, 2019 at 3:05 AM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.24.1, the first patch release
> for the camel-2.24.x branch with 22 improvements and bug fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12345495=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1142/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1142/org/apache/camel/apache-camel/2.24.1/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.24.1
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.24.1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [HEADS UP] The endpoint-dsl branch

[Willem Jiang]

When we deploy the camel routes with the help camel-k into k8s, we
still need to leverage the camel-catalog to find out the dependencies.
Otherwise we need to specify the dependency by using command line
options for camel-k to create the project with right third party
dependencies.
I think the challenge part is how can we do it with the endpoint-dsl
without specifying the dependencies.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Jun 12, 2019 at 1:16 PM Guillaume Nodet  wrote:
>
> Le mer. 12 juin 2019 à 02:37, Willem Jiang  a
> écrit :
>
> > Hi Guillaume,
> >
> > The endpoint-dsl is really helpful for camel to verify the endpoint
> > setting in the compile time.
> > Now I just have a quick question about how does the camel runtime
> > detect the dependencies of camel route?
> > With the endpoint URI we could use the camel-catalog do this kind of
> > work, with the endpoint-dsl we need to figure out another way to do
> > it.
> >
>
> Are you talking about the fact that the blueprint namespace handler
> try to find all the component dependencies ? Or is there any other
> place in the code that does a similar thing ?
> For the blueprint, I agree that could be a problem, but in reality it
> should
> not because blueprint uses the XML DSL which is not supported by
> the endpoint DSL we're talking.
> If there is something else, I could make sure it works too.  The endpoint
> builders are aware of the scheme, so we'd just need to add a getter
> so that it can be checked.
>
> Cheers,
> Guillaume
>
>
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Jun 12, 2019 at 5:37 AM Guillaume Nodet  wrote:
> > >
> > > Le mar. 11 juin 2019 à 20:45, Alex Dettinger  a
> > > écrit :
> > >
> > > > Hey Guillaume, nice feature indeed.
> > > > Just a detail when reading the example, I think one could be surprised
> > to
> > > > have x2 from/to at first glance, I mean:
> > > > from(fromFile(... and to(toFile(...
> > > >
> > > >
> > > I do agree.  My original idea was to only use file(xxx), but one
> > constraint
> > > is to have a different type for consumers and producers because they have
> > > different options, so we can't use the same method name.  So the current
> > > design is a fallback because I haven't found anything better, but I'm
> > open
> > > to suggestions ...
> > >
> > >
> > >
> > > > My 2 cents,
> > > > Alex
> > > >
> > > >
> > > >
> > > > On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet 
> > wrote:
> > > >
> > > > > I think I'm done with a first usable pass at the endpoint DSL.
> > > > > I've removed the getters/setters, added 2 flavors of fluent methods
> > (one
> > > > > with the real java type, another one with a String to allow
> > references
> > > > and
> > > > > property placeholder processing), renamed the generated classes to
> > > > > XxxEndpointBuilder and cleaned things a bit.
> > > > > In order to access this API, one would create an EndpointRouteBuilder
> > > > > anonymous class instead of the usual RouteBuilder (see below).  The
> > only
> > > > > difference is that it gives immediate access to the fromXxx() and
> > toXxx()
> > > > > methods that are generated as default methods on the interface, so
> > > > there's
> > > > > no need to import anything else.
> > > > > Please have a look and let me know what you think or if we see
> > anything
> > > > to
> > > > > improve.
> > > > >
> > > > > Cheers,
> > > > > Guillaume
> > > > >
> > > > > protected RouteBuilder createRouteBuilder() throws Exception {
> > > > > return new EndpointRouteBuilder() {
> > > > > @Override
> > > > > public void configure() throws Exception {
> > > > > from(fromFile(start).initialDelay(0).delay(10).move(done
> > +
> > > > > "/${file:name}"))
> > > > > .to(toMock("result"));
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > >
> > > > > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet  a
> > > > écrit :
> > > > >
> &g

Re: [HEADS UP] The endpoint-dsl branch

[Willem Jiang]

Hi Guillaume,

The endpoint-dsl is really helpful for camel to verify the endpoint
setting in the compile time.
Now I just have a quick question about how does the camel runtime
detect the dependencies of camel route?
With the endpoint URI we could use the camel-catalog do this kind of
work, with the endpoint-dsl we need to figure out another way to do
it.



Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Jun 12, 2019 at 5:37 AM Guillaume Nodet  wrote:
>
> Le mar. 11 juin 2019 à 20:45, Alex Dettinger  a
> écrit :
>
> > Hey Guillaume, nice feature indeed.
> > Just a detail when reading the example, I think one could be surprised to
> > have x2 from/to at first glance, I mean:
> > from(fromFile(... and to(toFile(...
> >
> >
> I do agree.  My original idea was to only use file(xxx), but one constraint
> is to have a different type for consumers and producers because they have
> different options, so we can't use the same method name.  So the current
> design is a fallback because I haven't found anything better, but I'm open
> to suggestions ...
>
>
>
> > My 2 cents,
> > Alex
> >
> >
> >
> > On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet  wrote:
> >
> > > I think I'm done with a first usable pass at the endpoint DSL.
> > > I've removed the getters/setters, added 2 flavors of fluent methods (one
> > > with the real java type, another one with a String to allow references
> > and
> > > property placeholder processing), renamed the generated classes to
> > > XxxEndpointBuilder and cleaned things a bit.
> > > In order to access this API, one would create an EndpointRouteBuilder
> > > anonymous class instead of the usual RouteBuilder (see below).  The only
> > > difference is that it gives immediate access to the fromXxx() and toXxx()
> > > methods that are generated as default methods on the interface, so
> > there's
> > > no need to import anything else.
> > > Please have a look and let me know what you think or if we see anything
> > to
> > > improve.
> > >
> > > Cheers,
> > > Guillaume
> > >
> > > protected RouteBuilder createRouteBuilder() throws Exception {
> > > return new EndpointRouteBuilder() {
> > > @Override
> > > public void configure() throws Exception {
> > > from(fromFile(start).initialDelay(0).delay(10).move(done +
> > > "/${file:name}"))
> > > .to(toMock("result"));
> > > }
> > > };
> > > }
> > >
> > >
> > > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet  a
> > écrit :
> > >
> > > > I just pushed a branch called "endpoint-dsl".
> > > >
> > > > My goal is to experiment with an auto-generated DSL for endpoints,
> > mainly
> > > > to have a complete and type-safe java DSL for endpoints instead of
> > using
> > > > URI containing all the parameters.  Right now, it compiles but isn't
> > > really
> > > > usable at a DSL.
> > > > I'll get back as soon as I have something which can actually be used so
> > > > that we can discuss further various options.
> > > > My rough goal is to be able to write something like:
> > > >
> > > >from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > >   .to(mock("result"))
> > > >
> > > > instead of
> > > >
> > > >from(
> > > >
> > >
> > "file://target/data/foo?delay=4000=4=2=3"
> > > > )
> > > >   .to("mock:result")
> > > >
> > > > Stay tuned !
> > > >
> > > > --
> > > > 
> > > > Guillaume Nodet
> > > >
> > > >
> > >
> > > --
> > > 
> > > Guillaume Nodet
> > >
> >
>
>
> --
> 
> Guillaume Nodet

Re: [VOTE] Release Apache Camel 2.23.3

[Willem Jiang]

+1 （binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jun 10, 2019 at 4:04 PM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.23.3 a new planned patch
> release for the camel-2.23.x branch with 32 improvements and bug
> fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12345358=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1141/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1141/org/apache/camel/apache-camel/2.23.3/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.23.3
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.23.3
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel K 0.3.4

[Willem Jiang]

+1. (binding)
I checked:
1. Verified the signed the signature and sha512 files , (we need to
update the KEYS file once we release the kit).
2. Ran the build from source without any problem
3. Ran the kamel install with my minikube to verify the builded images


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Jun 7, 2019 at 10:09 PM Nicola Ferraro  wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel K 0.3.4, the first official release
> of Apache Camel K.
>
> Staging repository:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/0.3.4/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/0.3.4
>
> Staging container image repository:
> https://hub.docker.com/r/camelk/camel-k/tags
>
> Command to install staging artifacts:
> kamel install --operator-image=camelk/camel-k:0.3.4
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel-K 0.3.4
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Nicola Ferraro

Re: [VOTE] Release Apache Camel K 0.3.4

[Willem Jiang]

Hi, Nicola.

Could you add the your public key into the Keys[1] files as Camel does?
I need to use that public Key to verify the signatures.
You can put the Keys file into here[2] and git repository.

[1]https://dist.apache.org/repos/dist/release/camel/apache-camel/KEYS
[2]https://dist.apache.org/repos/dev/release/camel/camel-k/KEYS

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jun 10, 2019 at 4:36 PM Nicola Ferraro  wrote:
>
> Ok, added. So, I'll keep only external signature from next release.
>
> Nicola
>
> On Mon, Jun 10, 2019 at 10:16 AM Willem Jiang 
> wrote:
>
> > For the convince binary release, we just need to keep signed signature
> > outside of the tar.gz.
> > So we just need to verify the tar.gz files and don't need to verify
> > all the exec files one by one.
> >
> > Could you add those files for the tar.gz files?
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Jun 10, 2019 at 4:03 PM Nicola Ferraro 
> > wrote:
> > >
> > > Yeah, those are in the tar.gz for the binary files. I've added them now
> > > also for sources and examples.
> > > Don't know which strategy is best.
> > >
> > > Nicola
> > >
> > > On Mon, Jun 10, 2019 at 12:52 AM Willem Jiang 
> > > wrote:
> > >
> > > > Hi Nicola,
> > > >
> > > > I cannot find the signed signature[1] and sha512 files in the staging
> > > > directory.
> > > > Could you add them into the release directory?
> > > >
> > > > [1]http://www.apache.org/legal/release-policy.html#release-signing
> > > >
> > > > Regards,
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Fri, Jun 7, 2019 at 10:09 PM Nicola Ferraro 
> > > > wrote:
> > > > >
> > > > > Hello all:
> > > > >
> > > > > This is a vote to release Apache Camel K 0.3.4, the first official
> > > > release
> > > > > of Apache Camel K.
> > > > >
> > > > > Staging repository:
> > > > > https://dist.apache.org/repos/dist/dev/camel/camel-k/0.3.4/
> > > > >
> > > > > Tag:
> > > > >
> > > >
> > https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/0.3.4
> > > > >
> > > > > Staging container image repository:
> > > > > https://hub.docker.com/r/camelk/camel-k/tags
> > > > >
> > > > > Command to install staging artifacts:
> > > > > kamel install --operator-image=camelk/camel-k:0.3.4
> > > > >
> > > > > Please test this release candidate and cast your vote.
> > > > >
> > > > > [ ] +1 Release the binary as Apache Camel-K 0.3.4
> > > > > [ ] -1 Veto the release (provide specific comments)
> > > > >
> > > > > The vote is open for at least 72 hours.
> > > > >
> > > > > Thanks,
> > > > > Nicola Ferraro
> > > >
> >

Re: [VOTE] Release Apache Camel K 0.3.4

[Willem Jiang]

For the convince binary release, we just need to keep signed signature
outside of the tar.gz.
So we just need to verify the tar.gz files and don't need to verify
all the exec files one by one.

Could you add those files for the tar.gz files?

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jun 10, 2019 at 4:03 PM Nicola Ferraro  wrote:
>
> Yeah, those are in the tar.gz for the binary files. I've added them now
> also for sources and examples.
> Don't know which strategy is best.
>
> Nicola
>
> On Mon, Jun 10, 2019 at 12:52 AM Willem Jiang 
> wrote:
>
> > Hi Nicola,
> >
> > I cannot find the signed signature[1] and sha512 files in the staging
> > directory.
> > Could you add them into the release directory?
> >
> > [1]http://www.apache.org/legal/release-policy.html#release-signing
> >
> > Regards,
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Jun 7, 2019 at 10:09 PM Nicola Ferraro 
> > wrote:
> > >
> > > Hello all:
> > >
> > > This is a vote to release Apache Camel K 0.3.4, the first official
> > release
> > > of Apache Camel K.
> > >
> > > Staging repository:
> > > https://dist.apache.org/repos/dist/dev/camel/camel-k/0.3.4/
> > >
> > > Tag:
> > >
> > https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/0.3.4
> > >
> > > Staging container image repository:
> > > https://hub.docker.com/r/camelk/camel-k/tags
> > >
> > > Command to install staging artifacts:
> > > kamel install --operator-image=camelk/camel-k:0.3.4
> > >
> > > Please test this release candidate and cast your vote.
> > >
> > > [ ] +1 Release the binary as Apache Camel-K 0.3.4
> > > [ ] -1 Veto the release (provide specific comments)
> > >
> > > The vote is open for at least 72 hours.
> > >
> > > Thanks,
> > > Nicola Ferraro
> >

Re: [VOTE] Release Apache Camel 2.22.5

[Willem Jiang]

+1 （binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Jun 8, 2019 at 8:53 PM Gregor Zurowski  wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.22.5 the last planned patch
> release for the camel-2.22.x branch with 13 improvements and bug
> fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12345404=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1140/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1140/org/apache/camel/apache-camel/2.22.5/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.22.5
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.22.5
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel K 0.3.4

[Willem Jiang]

Hi Nicola,

I cannot find the signed signature[1] and sha512 files in the staging directory.
Could you add them into the release directory?

[1]http://www.apache.org/legal/release-policy.html#release-signing

Regards,

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Jun 7, 2019 at 10:09 PM Nicola Ferraro  wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel K 0.3.4, the first official release
> of Apache Camel K.
>
> Staging repository:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/0.3.4/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/0.3.4
>
> Staging container image repository:
> https://hub.docker.com/r/camelk/camel-k/tags
>
> Command to install staging artifacts:
> kamel install --operator-image=camelk/camel-k:0.3.4
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel-K 0.3.4
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Nicola Ferraro

Re: [VOTE] Release Apache Camel 3.0.0-M3 (Milestone 3) (Attempt #2)

[Willem Jiang]

+1 （binding）

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Jun 4, 2019 at 2:59 PM Gregor Zurowski  wrote:
>
> Hi Everyone:
>
> This is the second vote to release Apache Camel 3.0.0-M3, the third
> milestone towards a new 3.0.0 major release with currently 653
> improvements and fixes. The first vote was cancelled due to issues
> found while testing the first release candidate. The necessary fixes
> [1,2] were applied and this new release candidate was created.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1139/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1139/org/apache/camel/apache-camel/3.0.0-M3/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.0.0-M3
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 3.0.0-M3
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor
>
> [1] Fixed OSGi type converter not loading the core fallback
> converters: 
> https://github.com/apache/camel/commit/369c382ea2dfab3384478c2f12953e6ca6a16776
> [2] Fix HealthCheckRegistry and HealthCheckService setters:
> https://github.com/apache/camel/commit/d87f5d55d8bf738bc6a62455542456ecf78e1b9e

Re: Quarkus

[Willem Jiang]

+1 for working with Quarkus to make the Camel Application more light and fast.

For the code donation part, we need to go through the IP clearance process[1].
Please let me know if you have any questions about this.

[1]https://incubator.apache.org/ip-clearance/

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Jun 4, 2019 at 5:45 PM Luca Burgazzoli  wrote:
>
> Hi,
>
> In the past months some folks at Red Hat have been working on the
> integration between Apache Camel and Quarkus. For those not familiar
> with the topic, Quarkus is a new Apache 2 licensed Cloud Native Java
> framework tailored for GraalVM and HotSpot that bring fast startup
> and low memory footprint to Java based application by leverage clever
> build time optimizations and AOT compilation through Substrate VM [1].
>
> The result of the experimentation is available in the Quarkus
> repository [2][3] and I’m also working on an experimental branch
> on Camel K [4] to bring Quarkus on the K side based on my latest
> blog “Adventures in GraalVM: polyglot Camel (k) native routes
> with Quarkus”  [5]
>
> I do believe that both communities can benefit from a collaboration:
>
> Apache Camel can benefit from Quarkus to become
> a) Even more suitable for microservices
> b) Suitable for serverless workloads as Quarkus among others enables
>built-time warmup of the Camel Context, and elimination of dead-code
>(code that was only used during warmup) which is a key enabler for
>very fast start-up and low memory footprint Apache Camel can be on
>the innovative forefront with a cloud native Java stack for running
>modern serverless workloads on Kubernetes/Knative with Camel K and
>Camel Quarkus
>
> So I’m proposing to officially support Quarkus in Apache Camel’s main
> repository (or a dedicated one if it suits better) by creating a new
> platform along with those we support as today (Spring Boot, Karaf).
>
> Quarkus’ people is keen to donate the code related to Apache Camel
> hosted in theirs repository to the Apache Software foundation.
>
> There has been some other users in the community whom have tried
> Quarkus and Camel together and written blogs [6] about their experience,
> and Claus also posted a quick gif animation of native compiled Camel
> with Quarkus starting up in 7 milliseconds and taking up only 15mb
> of memory [7].
>
> Thoughts ?
>
> Luca
>
> [1] https://quarkus.io/
> [2] https://github.com/quarkusio/quarkus/tree/master/extensions/camel
> [3] https://github.com/quarkusio/quarkus-quickstarts/tree/master/camel-java
> [4]
> https://github.com/lburgazzoli/apache-camel-k-runtime/tree/quarkus-runtime
> [5] https://bit.ly/2HvOrh0
> [6] https://bit.ly/2WDtCbW
> [7]
> https://www.linkedin.com/feed/update/urn:li:activity:6521869236153970688/
>
> ---
> Luca Burgazzoli

Re: Camel K 1.0 Roadmap

[Willem Jiang]

+1 to create a branch 0.3.x for support camel-2.x and move to camel-k 1.0.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, May 23, 2019 at 1:14 AM Luca Burgazzoli  wrote:
>
> Hello,
>
> we need to start planning what features we want to include in Camel K 1.0
> so I've created milestone 1.0.0 for both camel-k and camel-k runtime [1][2]
> to have a better visibility of what's left so I kindly ask everyone to
> review the open issue and think about what we should include in 1.0.
>
> One of the things we need to decide as earlier as possible is what version
> of camel we want to support on camel-k-runtime: as today we do support from
> 2.18.x to 3.x but it is becoming more and more complex as the development
> of the camel 3 goes ahead so I'm proposing to:
>
> - create a branch for the current code-base of camel-k-runtime we can name
> says camel-2.x which will be used for everyone that need to run camel-k and
> freeze the version to 0.3.x (and eventually remove camel 3 bits)
> - set the master branch to something like 1.0.0.SNAPSHOT and base it to
> camel 3.x only
>
> Thoughts ?
>
> [1] https://github.com/apache/camel-k/milestone/1
> [2] https://github.com/apache/camel-k-runtime/milestone/1
> [3] https://github.com/apache/camel-k-runtime/issues/56
>
> ---
> Luca Burgazzoli

Re: Release Camel-K 0.3.3

[Willem Jiang]

Hi Nicola,

+1 to cut the camel-k release once to simplify the release process.
I think we could create an internal account in the docker hub for the
staging release and publish the snapshot version for internal
validation.
Once we have the official source release, we could push the voted
staging image into Apache docker repo as the final release process.

For the Github release page, it could be better to have one entry
(Apache official link) for the user to download. In this way the user
could not be confused to find out which binary is the best one.

Regards,

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, May 17, 2019 at 6:55 AM Nicola Ferraro  wrote:
>
> Thanks Willem for taking time for looking into this issue.
>
> For staging the binary files, I think it's ok to follow the ServiceComb
> approach (I assume that the /dev path is for dev builds only and cannot be
> mistaken for the official release path).
> Also point 3 can be addressed. I hope we can do it with the new website,
> that I'd like to see online soon.
>
> But I think we have a problem with docker images. In other projects, docker
> images are a different way of packaging the binaries, but camel k is a
> cloud platform and cannot be run without the docker images.
> This means that if we don't publish the docker images, we're not able to
> test the software before the vote.
>
> So we are asked to release docker images after voting, but cannot vote
> without them. It's a kind of chicken and eggs problem.
>
> On the other side. For camel k, users are not expected to look into docker
> hub to find the software, i.e. we're not using docker hub as a portal to
> distribute the software to our users. The primary way to install the
> software is through the 'kamel' CLI, that pulls the docker image on the
> cloud system, under the hood. So there's no way a user can mistakenly take
> a docker image for an official release and use it (that was the main
> concern of the legal discussion you've linked). Same holds also for
> snapshots.
>
> For us, Docker Hub is not a distribution channel, it's a delivery network
> used internally by the software.
> If you agree on this, we have good chances to convince the legal team.
>
> Continuing this thread, I'd like to simplify a bit the release process, to
> avoid having two votes for runtime and go binaries, because Camel k is a
> single project, even if split into two repos.
> I think it makes sense NOT to vote for camel-k-runtime. If we need to
> release a new camel-k-runtime version, we can do it when we're ready to cut
> a full camel-k release. In this case we stage the camel-k-runtime plus the
> go binaries and docker images (...) and ask for a combined vote.
> There can be cases where we won't need to release a new runtime but only a
> new version of the binaries and related docker images. In such cases, we'll
> vote only for the camel-k go stuff.
>
> As last step, I'd like to keep the release page on GitHub as additional
> downstream convenience distribution channel. It seems allowed by legal, as
> long as it's used as additional distribution channel and does not replace
> the main one.
>
> What do you think?
>
> Nicola
>
>
> Il gio 16 mag 2019, 02:14 Willem Jiang  ha scritto:
>
> > For the go artifacts(source and binary) we can put them into [1].
> > Current ServiceComb service-center is using [2] as the staging repo.
> > I found camel-k already use publish the dock image here[3], but
> > according to [4], we cannot use this repo to distribute SNAPSHOT
> > version.
> >
> > So I think the missing parts of current camel-k release are
> > 1.  We need to stage go artifacts and vote of them.
> > 2.  Publish the artifacts if the vote is passed.
> > 3.  Updating the Apache Camel website for the downloading of the artifacts.
> > 4.  Push the convicen binary docker image which is based on the
> > official release.
> >
> > FYI,  there are some discussion[5] in the Zipkin about the release
> > which we take as a reference.
> >
> > [1]https://dist.apache.org/repos/dist/dev/camel/camel-k
> > [2]
> > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/
> > [3]https://hub.docker.com/r/apache/camel-k
> > [4]https://issues.apache.org/jira/browse/INFRA-12659
> > [5]https://github.com/apache/incubator-zipkin/issues/2597
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, May 4, 2019 at 3:46 PM Nicola Ferraro 
> > wrote:
> > >
> > > Yes, released go binaries are still unofficial dev builds. We should
> > find a
> > > way to complete the release process.
> > > Ther

Re: Release Camel-K 0.3.3

[Willem Jiang]

For the go artifacts(source and binary) we can put them into [1].
Current ServiceComb service-center is using [2] as the staging repo.
I found camel-k already use publish the dock image here[3], but
according to [4], we cannot use this repo to distribute SNAPSHOT
version.

So I think the missing parts of current camel-k release are
1.  We need to stage go artifacts and vote of them.
2.  Publish the artifacts if the vote is passed.
3.  Updating the Apache Camel website for the downloading of the artifacts.
4.  Push the convicen binary docker image which is based on the
official release.

FYI,  there are some discussion[5] in the Zipkin about the release
which we take as a reference.

[1]https://dist.apache.org/repos/dist/dev/camel/camel-k
[2]https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/
[3]https://hub.docker.com/r/apache/camel-k
[4]https://issues.apache.org/jira/browse/INFRA-12659
[5]https://github.com/apache/incubator-zipkin/issues/2597

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, May 4, 2019 at 3:46 PM Nicola Ferraro  wrote:
>
> Yes, released go binaries are still unofficial dev builds. We should find a
> way to complete the release process.
> There are many points that we need to cover, including signing and
> distributing binaries but also the docker images. Iirc docker hub is not an
> officially recognized system for distributing resources.
>
> But I agree we should standardize the process, otherwise we cannot even do
> official announcements and people won't know about them.
>
> Nicola
>
>
>
> Il sab 4 mag 2019, 09:07 Andrea Cosentino  ha scritto:
>
> > Ok. Lets synch with others and we can write up a release process for that
> >
> > Il sab 4 mag 2019, 08:56 Willem Jiang  ha scritto:
> >
> > > We could use the  https://dist.apache.org/repos/dist/dev as a staging
> > > repo to host the artifacts which need to be voted.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino 
> > wrote:
> > > >
> > > > We can add a goal to push the binary generated on dist. But all the
> > stuff
> > > > generated is just go binaries and docker images. It's not like a normal
> > > > Java project.
> > > >
> > > > Lets wait for Nicola and Luca about this.
> > > >
> > > > Il sab 4 mag 2019, 03:41 Willem Jiang  ha
> > > scritto:
> > > >
> > > > > Hi,
> > > > >
> > > > > I just found there are release in the github of camel-k 0.3.3
> > > > > recently. I can only find the vote of camel-k runtime 0.3.3.  From my
> > > > > understanding camel-k is dependent on camel-k runtime, but they are
> > > > > two different projects. As the official Apache release, we need the
> > > > > vote of PMC[1]
> > > > > According to the release distribution guild of ASF[2].
> > > > > "The Apache infrastructure must be the primary source for all
> > > > > artifacts officially released by the ASF."  We need to put the
> > > > > artifacts of camel-k into the https://dist.apache.org/repos/dist/.
> > > > >
> > > > > Please let me know if I missed something.
> > > > >
> > > > > [1]http://www.apache.org/dev/release-publishing.html#goal
> > > > > [2]http://www.apache.org/dev/release-publishing.html#distribution
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > >
> >

Re: GSoC 2019: Congratulations, your proposal with The Apache Software Foundation has been accepted!

[Willem Jiang]

It's great to hear that you proposal was accepted.
Did you have chance to discuss the detail with your mentor?
If you need to find a mentor I'd happy to help you.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, May 7, 2019 at 5:22 AM Beto Flores  wrote:
>
> Hi all.
>
> I have just received an email from the GSoC 2019 program and my proposal
> have been accepted. Thanks so much you guys for all your support during the
> application period and really hope that this summer will be productive
> working with the Apache Camel Community.
>
>  Please let me know if you have suggestions on how to get started in the
> community and start working on my project.
>
> Best,
> Roberto.
>
> -- Forwarded message -
> De: Google Summer of Code 
> Date: lun., 6 de may. de 2019 a la(s) 16:07
> Subject: GSoC 2019: Congratulations, your proposal with The Apache Software
> Foundation has been accepted!
> To: 
>
>
> [image: Google Summer of Code]
>
> Hi Roberto Flores,
>
> Your proposal CAMEL-9260 Dataformat Apache Any23
> <https://summerofcode.withgoogle.com/dashboard/student/proposal/5081445427576832/>
> has been accepted!
>
> Welcome to GSoC 2019!
>
> We look forward to seeing the great things you will accomplish this summer
> with The Apache Software Foundation.
>
> The next thing you need to do is read the Information for Accepted Students
> <https://developers.google.com/open-source/gsoc/help/accepted-students>. It
> contains important information you need to know about your participation in
> GSoC 2019.
>
> You will receive another email in the next few days with information about
> your stipend.
>
> If you have any questions, please email the Google Summer of Code support
> team at gsoc-supp...@google.com.
>
> Have a great summer!
>
> -*Google Summer of Code team*
>
> This email was sent to betoflow...@gmail.com.
>
> You are receiving this email because of your participation in Google Summer
> of Code 2019.
> https://summerofcode.withgoogle.com
>
> To leave the program and stop receiving all emails, you can go to your
> profile <https://summerofcode.withgoogle.com/dashboard/profile/> and
> request deletion of your program profile.
>
> For any questions, please contact gsoc-supp...@google.com. Replies to this
> message go to an unmonitored mailbox.
>
> © 2019 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

Re: [VOTE] Release Apache Camel 2.24.0

[Willem Jiang]

+1 (binding)
Tried it with my local projects.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, May 7, 2019 at 3:30 AM Gregor Zurowski  wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.24.0, a new minor release
> with 156 improvements and bug fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344459=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1136/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1136/org/apache/camel/apache-camel/2.24.0/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.24.0
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.24.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: Release Camel-K 0.3.3

[Willem Jiang]

We could use the  https://dist.apache.org/repos/dist/dev as a staging
repo to host the artifacts which need to be voted.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino  wrote:
>
> We can add a goal to push the binary generated on dist. But all the stuff
> generated is just go binaries and docker images. It's not like a normal
> Java project.
>
> Lets wait for Nicola and Luca about this.
>
> Il sab 4 mag 2019, 03:41 Willem Jiang  ha scritto:
>
> > Hi,
> >
> > I just found there are release in the github of camel-k 0.3.3
> > recently. I can only find the vote of camel-k runtime 0.3.3.  From my
> > understanding camel-k is dependent on camel-k runtime, but they are
> > two different projects. As the official Apache release, we need the
> > vote of PMC[1]
> > According to the release distribution guild of ASF[2].
> > "The Apache infrastructure must be the primary source for all
> > artifacts officially released by the ASF."  We need to put the
> > artifacts of camel-k into the https://dist.apache.org/repos/dist/.
> >
> > Please let me know if I missed something.
> >
> > [1]http://www.apache.org/dev/release-publishing.html#goal
> > [2]http://www.apache.org/dev/release-publishing.html#distribution
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >

Release Camel-K 0.3.3

[Willem Jiang]

Hi,

I just found there are release in the github of camel-k 0.3.3
recently. I can only find the vote of camel-k runtime 0.3.3.  From my
understanding camel-k is dependent on camel-k runtime, but they are
two different projects. As the official Apache release, we need the
vote of PMC[1]
According to the release distribution guild of ASF[2].
"The Apache infrastructure must be the primary source for all
artifacts officially released by the ASF."  We need to put the
artifacts of camel-k into the https://dist.apache.org/repos/dist/.

Please let me know if I missed something.

[1]http://www.apache.org/dev/release-publishing.html#goal
[2]http://www.apache.org/dev/release-publishing.html#distribution

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

Re: [VOTE] Release Apache Camel-K Runtime 0.3.2 (take 2)

[Willem Jiang]

+1 binding.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Apr 26, 2019 at 11:44 PM Nicola Ferraro  wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel-K runtime 0.3.2 (take 2).
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1129
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=tag;h=refs/tags/camel-k-runtime-parent-0.3.2
>
> Source release package:
> https://repository.apache.org/content/repositories/orgapachecamel-1129/org/apache/camel/k/apache-camel-k-runtime/0.3.2/apache-camel-k-runtime-0.3.2-source-release.zip
>
> This release adds some important bug fixes and improvements:
> https://github.com/apache/camel-k-runtime/issues/51
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel-K 0.3.2
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Nicola Ferraro

Re: [VOTE]

[Willem Jiang]

+1 for Concept One.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Apr 23, 2019 at 11:15 PM Jason Brock  wrote:
>
> Hello everyone!
>
> Here is a first round of design concepts to help refresh the look and feel
> of the Apache Camel website. Please let me know if you require a particular
> file format and I will furnish that to the group.
>
> Concept One:
> https://design.jboss.org/camel/website/styleguides/images/01-colorpalette.png
> https://design.jboss.org/camel/website/styleguides/images/01-styleguide.png
>
> Concept Two:
> https://design.jboss.org/camel/website/styleguides/images/02-colorpalette.png
> https://design.jboss.org/camel/website/styleguides/images/02-styleguide.png
>
> Concept Three:
> https://design.jboss.org/camel/website/styleguides/images/03-colorpalette.png
> https://design.jboss.org/camel/website/styleguides/images/03-styleguide.png
>
>
> All the best,
>
> JASON K BROCK
>
> Web UX DESIGNER, MIDDLEWARE ENGINEERING SERVICES
>
> Red Hat - Austin, TX <https://www.redhat.com/> | jbr...@redhat.com |
> 512-786-8304

Re: [VOTE] Release Apache Camel 2.22.4

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Apr 8, 2019 at 1:34 PM Gregor Zurowski  wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.22.4, the fourth patch
> release for the camel-2.22.x branch with 26 improvements and bug
> fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344887=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1127/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1127/org/apache/camel/apache-camel/2.22.4/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.22.4
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.22.4
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel 2.23.2

[Willem Jiang]

+1 binding.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Apr 7, 2019 at 2:47 PM Gregor Zurowski  wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.23.2, the second patch
> release for the camel-2.23.x branch with 64 improvements and bug
> fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344839=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1125/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1125/org/apache/camel/apache-camel/2.23.2/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.23.2
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.23.2
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel 3.0.0-M2 (Milestone 2)

[Willem Jiang]

+1 (binding).

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Mar 26, 2019 at 4:51 AM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 3.0.0-M2, the second milestone
> towards a new 3.0.0 major release with currently 471 improvements and
> fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1124/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1124/org/apache/camel/apache-camel/3.0.0-M2/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.0.0-M2
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 3.0.0-M2
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: Question about Camel Connector

[Willem Jiang]

As we are moving to the Camel 3.x,  it is important for the user to
know if they can still keep their investment of Camel Connector, or is
there any replacement of Camel Connector.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Mar 15, 2019 at 10:02 AM Tadayoshi Sato
 wrote:
>
> Could anyone answer this question?  I was also surprised to find Camel
> Connector discontinued in 3.x and would like to get explanation from
> someone knowledgeable on the topic.
>
> I can only find this JIRA other than Claus' commits that deprecated
> connectors, but the JIRA doesn't refer to any background discussions.
> https://issues.apache.org/jira/browse/CAMEL-13052
>
>
> On Thu, Mar 7, 2019 at 12:02 PM Willem Jiang  wrote:
>
> > Hi，
> >
> > I think Camel Connector[1] is quit useful if we have some
> > configuration need to be done on the component or endpoint level.
> > I just found the codes of CamelConnector were removed in the camel
> > 3.x.  But there is not much discussion about it. May I know the reason
> > why do we deprecate these connectors and remove them in Camel 3.x?
> >
> > Thanks,
> >
> > [1]https://issues.apache.org/jira/browse/CAMEL-10721
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >

Re: [DISCUSS] Flat POMs

[Willem Jiang]

+1.
>From my experience, use the profile to support Spring 4.x and Spring
5.x at the same time.
In the maven deploy time, we have to choose one of the profile to use.
The flatten maven plugin could address this kind of problem, we could
deploy Spring 4.x version pom and Spring 5.x version separately. In
this way, the user can choose what kind of version they want to use.

Anything thoughts?

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Mar 15, 2019 at 12:15 AM Zoran Regvart  wrote:
>
> Hi,
> when we deploy POMs to Maven repository they contain a lot of
> information that relates solely to the build: the whole ``
> section, `` and such.
>
> I'm looking at flatten-maven-plugin[1] and I think with 3.0 we have an
> opportunity to cleanup our published POMs.
>
> I can raise a JIRA for this, but I think it's worth discussing and see
> if anyone has any big objections to doing that?
>
> zoran
>
> [1] www.mojohaus.org/flatten-maven-plugin/
> --
> Zoran Regvart

Re: Google Summer of Code 2019 Mentor Registration

[Willem Jiang]

I just send a mentor apply mail.
PMC please acknowledge that.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem
On Tue, Mar 12, 2019 at 4:28 PM Zoran Regvart  wrote:
>
> Hi Cameleers,
> We already have several students interested contributing to Camel,
> that is awesome, to keep the momentum going I think we need more
> mentors to sign up.
>
> I see Andrea and myself signed up for mentorship, if anyone else would
> like to mentor in this years Google Summer of Code, please apply for
> mentorship by sending an e-mail with:
>
> ```
> to: priv...@camel.apache.org
> cc: ment...@community.apache.org
> subject: GSoC 2019 mentor request for 
>
> PMC,
> please acknowledge my request to become a mentor for Google Summer of
> code 2019 projects for Apache Camel
>
> I would like to receive the mentor invite to 
> ```
>
> thanks!
>
> zoran
>
> On Sat, Mar 9, 2019 at 3:55 PM Zoran Regvart  wrote:
> >
> > Google Summer of Code mentors,
> > please follow the instructions provided in the email below,
> >
> > zoran
> > -- Forwarded message -
> > From: Ulrich Stärk 
> > Date: Fri, Mar 8, 2019 at 8:49 PM
> > Subject: Google Summer of Code 2019 Mentor Registration
> > To: 
> > Cc: d...@community.apache.org 
> >
> >
> > Dear PMCs,
> >
> > I'm happy to announce that the ASF has made it onto the list of
> > accepted organizations for
> > Google Summer of Code 2019! [1,2]
> >
> > It is now time for mentors to sign up, so please pass this email on to
> > your community and
> > podlings. If you aren’t already subscribed to
> > ment...@community.apache.org you should do so now else
> > you might miss important information.
> >
> > Mentor signup requires two steps: mentor signup in Google's system [3]
> > and PMC acknowledgement.
> >
> > If you want to mentor a project in this year's SoC you will have to
> >
> > 1. Be an Apache committer.
> > 2. Request an acknowledgement from the PMC for which you want to
> > mentor projects. Use the below
> > template and *do not forget to copy ment...@community.apache.org*. We
> > will use the email adress you
> > indicate to send the invite to be a mentor for Apache.
> >
> > PMCs, read carefully please.
> >
> > We request that each mentor is acknowledged by a PMC member. This is
> > to ensure the mentor is in good
> > standing with the community. When you receive a request for
> > acknowledgement, please ACK it and cc
> > ment...@community.apache.org
> >
> > Lastly, it is not yet too late to record your ideas in Jira (see
> > previous emails for details).
> > Students will now begin to explore ideas so if you haven’t already
> > done so, record your ideas
> > immediately!
> >
> > Cheers,
> >
> > The Apache GSoC Team
> >
> > mentor request email template:
> > 
> > to: private@.apache.org
> > cc: ment...@community.apache.org
> > subject: GSoC 2019 mentor request for 
> >
> >  PMC,
> >
> > please acknowledge my request to become a mentor for Google Summer of
> > Code 2018 projects for Apache
> > .
> >
> > I would like to receive the mentor invite to 
> >
> > 
> >
> > 
> >
> > [1] https://summerofcode.withgoogle.com/organizations/
> > [2] https://summerofcode.withgoogle.com/organizations/6614885824200704/
> > [3] https://summerofcode.withgoogle.com/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Zoran Regvart

Re: [VOTE] Release Apache Camel-K Runtime 0.3.1

[Willem Jiang]

+1. (Binding)

I checked.
* Signed key of the source artifacts.
* Build the source from without any error.
* LICENSE and NOTICE files look good.
* The staging repo artifacts look good

It took me some time to find the updated KEYS file.
I think we could update the vote mail template by adding the KEYS
files for verification.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem



On Wed, Mar 6, 2019 at 5:22 PM Nicola Ferraro  wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel-K runtime 0.3.1
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1123/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=tag;h=refs/tags/camel-k-runtime-parent-0.3.1
>
> Source release package:
> https://repository.apache.org/content/repositories/orgapachecamel-1123/org/apache/camel/k/apache-camel-k-runtime/0.3.1/apache-camel-k-runtime-0.3.1-source-release.zip
>
> This release adds some important improvements in the Knative compatibility
> area: https://github.com/apache/camel-k-runtime/issues/28
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel-K 0.3.1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Nicola Ferraro

Re: Camel-K: How to test the runtime under vote ?

[Willem Jiang]

According to the error, it looks like camel-k  maven plugin cannot be
resolved from the central maven.
We may need to pass the plugin repository to kcamel commend, I'm not
sure if --pluginRepositories could do the track.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Mar 8, 2019 at 5:26 AM Alex Dettinger  wrote:
>
> Hi Luca,
>
>   And many thanks for guidance :) I think camel-k was indeed already
> installed. From there, I've then tried:
>
> make images-dev
> oc login -u system:**
> ./kamel reset
> oc delete
> all,pvc,configmap,rolebindings,clusterrolebindings,secrets,sa,roles,clusterroles,crd
> -l 'app=camel-k'
> ./kamel install --cluster-setup --runtime-version 0.3.1 --repository
> https://repository.apache.org/content/repositories/orgapachecamel-1123/ -w
> oc login -u developer
> ./kamel install --runtime-version 0.3.1 --repository
> https://repository.apache.org/content/repositories/orgapachecamel-1123/ -w
> ./kamel run examples/simple.groovy --dev
>
> But then, "kamel run" hangs forever in the 'Waiting for platform phase'.
> The operator reports "Failure to find
> org.apache.camel.k:camel-k-maven-plugin:jar:0.3.1 in
> https://repo.maven.apache.org/maven2;.
> It's like the staging repository is ignored.
>
> More complete logs below:
> {"level":"info","ts":1551977988.2832928,"logger":"camel-k.maven","msg":"write
> project: {XMLName:{Space: Local:project} XMLNs:
> http://maven.apache.org/POM/4.0.0  XMLNsXsi:
> http://www.w3.org/2001/XMLSchema-instance  XsiSchemaLocation:
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd  ModelVersion:4.0.0
> GroupID:org.apache.camel.k.integration ArtifactID:camel-k-integration
> Version:0.3.1-SNAPSHOT Properties:map[]
> DependencyManagement:{Dependencies:[{GroupID:org.apache.camel
> ArtifactID:camel-bom Version:2.23.1 Type:pom Classifier: Scope:import
> Exclusions:}]} Dependencies:[{GroupID:org.apache.camel.k
> ArtifactID:camel-k-runtime-spring-boot Version:0.3.1 Type: Classifier:
> Scope: Exclusions:0xc000594140}] Repositories:[{*ID:repo-000 Name:
> URL:https://repository.apache.org/content/repositories/orgapachecamel-1123/
> <https://repository.apache.org/content/repositories/orgapachecamel-1123/>*
> Snapshots:{Enabled:false UpdatePolicy:} Releases:{Enabled:true
> UpdatePolicy:}}] PluginRepositories:[] Build:{DefaultGoal: Plugins:[]}}"}
> {"level":"info","ts":1551977988.2835553,"logger":"camel-k.maven","msg":"execute:
> mvn -Dmaven.repo.local=/tmp/artifacts/m2
> org.apache.camel.k:camel-k-maven-plugin:0.3.1:generate-dependency-list"}
> [INFO] Scanning for projects...
> [WARNING] The POM for org.apache.camel.k:camel-k-maven-plugin:jar:0.3.1 is
> missing, no dependency information available
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 0.273 s
> [INFO] Finished at: 2019-03-07T16:59:50Z
> [INFO]
> 
> [ERROR] Plugin org.apache.camel.k:camel-k-maven-plugin:0.3.1 or one of its
> dependencies could not be resolved: Failure to find
> *org.apache.camel.k:camel-k-maven-plugin:jar:0.3.1
> in https://repo.maven.apache.org/maven2
> <https://repo.maven.apache.org/maven2>*  was cached in the local
> repository, resolution will not be reattempted until the update interval of
> central has elapsed or updates are forced -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
> {"level":"info","ts":1551977990.107809,"logger":"camel-k.builder","msg":"step
> failed with error: failure while determining classpath: exit status
> 1","step":"build/compute-dependencies","phase":20,"context":"spring-boot"}
>
> Alex
>
> On Thu, Mar 7, 2019 at 9:03 AM Luca Burgazzoli 
> wrote:
>
> > Hi Alex,
> >
> > was camel-k already installed ?
> >
> > ---
> > Luca Burgazzoli
> >
> > On Wed, Mar 6, 2019 at 10:15 PM Alex Dettinger 
> > wrote:
> > >
> > > Hi Camel

Re: IntelliJ IDEA setup for Apache Camel

[Willem Jiang]

Willem JiangTwitter: willemjiangWeibo: 姜宁willem
On Wed, Mar 6, 2019 at 12:39 AM Marc Carter  wrote:
>
> I took a look at that and it's helped a bit but this does need a
> retelling. For the sake of sanity, CheckStyle and Eclipse rules should
> be golden - IntelliJ has decent import system for both that can be (re)
> documented. However (isn't there always something...)
>
> a) etc/eclipse/CamelCodeFormatter.xml contains an indent of 8 which is
> obviously incorrect (clashes with CS rules). Is this the correct file?
>
> 
>
It's wrong,  do you mind send a PR for it.

> b) buildingtools/camel-checkstyle.xml differs from
> buildingtools/src/main/resources/camel-checkstyle.xml
>
> Which is correct?

It's confuse the user.
The check style file in the resource directory[1] is used in setting
up the eclipse workspace.
But I cannot find the checkstyle plugin setting with the building
tools on the master branch.

[1]https://github.com/apache/camel/blob/84c003e039e00622313d0328270c5f139b6a8821/pom.xml#L407

>
> On 3/5/19 11:45 AM, Onder SEZGIN wrote:
> > http://camel.apache.org/set-up-your-ide.html
> >
> > see this file mentioned below is on older branches on github.
> >
> > *etc/idea/settings.jar*
> >
> > On Tue, Mar 5, 2019 at 1:42 PM Marc Carter  wrote:
> >
> >> Official instructions for IntelliJ(*) point to files that no longer
> >> exist. I'm sure there's some history to this but it does mean I (and
> >> anyone else not using Eclipse) is missing the checkstyle and format
> >> rules that prevent poor quality checkins.
> >>
> >> I have learnt the command-line version but it's no substitute for your
> >> IDE getting the details correct as you type!
> >>
> >> ./mvnw -TC1 -pl :camel-module1,:camel-module2 -Pfastinstall -Psourcecheck
> >>
> >> Are there any newer IJ instructions or should I set this up myself?
> >>
> >> Marc
> >>
> >> (*) http://camel.apache.org/set-up-your-ide.html
> >>
> >>
> >>
> >>

Re: [VOTE] Release Apache Camel-K Runtime 0.3.0 (take 2)

[Willem Jiang]

+1 binding.

I checked

Signed key of the source artifacts.
Build the source from without any error.
LICENSE and NOTICE files look good.
The staging repo artifacts look good

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Feb 27, 2019 at 4:38 PM Willem Jiang  wrote:
>
> The Source release package is here[1]
> https://repository.apache.org/content/repositories/orgapachecamel-1122/org/apache/camel/k/apache-camel-k-runtime/0.3.0/apache-camel-k-runtime-0.3.0-source-release.zip
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Feb 27, 2019 at 4:31 PM Andrea Cosentino
>  wrote:
> >
> > Hello all:
> >
> > This is a vote to release Apache Camel-K runtime 0.3.0
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1122
> >
> > Tag: 
> > https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=tag;h=2d5b34964e392f9c5f4b1a390f64af99de9079c2
> > This release is important because it introduce the split between camel-k 
> > and camel-k-runtime bits and also an initial support for Camel 3 M1.
> >
> > We have added the sources package too.
> >
> > Please test this release candidate and cast your vote.
> >
> > [ ] +1 Release the binary as Apache Camel-K 0.3.0
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 72 hours.
> >
> > Thanks,
> > Andrea
> >
> > --
> > Andrea Cosentino
> > --
> > Apache Camel PMC Chair
> > Apache Karaf Committer
> > Apache Servicemix PMC Member
> > Email: ancosen1...@yahoo.com
> > Twitter: @oscerd2
> > Github: oscerd

Re: [VOTE] Release Apache Camel-K Runtime 0.3.0 (take 2)

[Willem Jiang]

The Source release package is here[1]
https://repository.apache.org/content/repositories/orgapachecamel-1122/org/apache/camel/k/apache-camel-k-runtime/0.3.0/apache-camel-k-runtime-0.3.0-source-release.zip

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Feb 27, 2019 at 4:31 PM Andrea Cosentino
 wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel-K runtime 0.3.0
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1122
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=tag;h=2d5b34964e392f9c5f4b1a390f64af99de9079c2
> This release is important because it introduce the split between camel-k and 
> camel-k-runtime bits and also an initial support for Camel 3 M1.
>
> We have added the sources package too.
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel-K 0.3.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Andrea
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: [VOTE] Release Apache Camel-K Runtime 0.3.0

[Willem Jiang]

Hi Andrea,

I just submit the patch into master branch. I did some test by using
"mvn clean install -Prelease."
Please let me know if you have any questions about the patch.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Feb 27, 2019 at 3:20 PM Andrea Cosentino  wrote:
>
> Great, thanks a lot
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Wednesday, February 27, 2019, 8:18:29 AM GMT+1, Willem Jiang 
>  wrote:
>
>
>
>
>
> Yes, I'm working on it now.
> It should be fine in an hour or so.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Feb 27, 2019 at 3:05 PM Andrea Cosentino  
> wrote:
> >
> > Are you working on this? Otherwise I can take care of that.
> >
> > --
> > Andrea Cosentino
> > --
> > Apache Camel PMC Chair
> > Apache Karaf Committer
> > Apache Servicemix PMC Member
> > Email: ancosen1...@yahoo.com
> > Twitter: @oscerd2
> > Github: oscerd
> >
> >
> >
> >
> >
> >
> > On Wednesday, February 27, 2019, 7:22:42 AM GMT+1, Willem Jiang 
> >  wrote:
> >
> >
> >
> >
> >
> > Yeah, the staging artifacts are signed. But we need to provide a
> > source package for vote.
> > I just created a JIRA[1] and submit a quick fix for it . I think we
> > should cancel this vote and do the release after the apply the patch.
> >
> > BTW, do we have any test project to help us to verify those staging 
> > artifacts?
> >
> > [1]https://issues.apache.org/jira/browse/CAMEL-13264
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Feb 27, 2019 at 1:56 PM Andrea Cosentino  
> > wrote:
> > >
> > > And btw I think everything in the staging repo is already signed.
> > >
> > > Inviato da Yahoo Mail su Android
> > >
> > > Il mer, 27 feb, 2019 alle 6:53, Andrea Cosentino
> > >  ha scritto:
> > > We can add that in the next release. Can you cast your vote or do you 
> > > want to start a new release?
> > >
> > > Inviato da Yahoo Mail su Android
> > >
> > >  Il mer, 27 feb, 2019 alle 2:09, Willem Jiang ha 
> > > scritto:  I cannot find the source package link from the staging repo to 
> > > do the
> > > verify (make sure we can build the kit from scratch).
> > > The source package[1] is quite important an Apache release.  We also
> > > need a release sign for the kits.
> > >
> > > BTW,
> > > The old camel source and binary release kits are also signed during the 
> > > release.
> > >
> > > [1]http://www.apache.org/legal/release-policy.html#source-packages
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Tue, Feb 26, 2019 at 5:31 PM Andrea Cosentino
> > >  wrote:
> > > >
> > > > Hello all:
> > > >
> > > > This is a vote to release Apache Camel-K runtime 0.3.0
> > > >
> > > > Staging repository:
> > > > https://repository.apache.org/content/repositories/orgapachecamel-1121/
> > > >
> > > > Tag: 
> > > > https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=tag;h=ffce60741685f5385c4923200cc8d8adf4a9eaac
> > > >
> > > > This release is important because it introduce the split between 
> > > > camel-k and camel-k-runtime bits and also an initial support for Camel 
> > > > 3 M1.
> > > > Please test this release candidate and cast your vote.
> > > > [ ] +1 Release the binary as Apache Camel-K 0.2.1
> > > > [ ] -1 Veto the release (provide specific comments)
> > > >
> > > > The vote is open for at least 72 hours.
> > > >
> > > > Thanks,
> > > > Andrea
> > > >
> > > > --
> > > > Andrea Cosentino
> > > > --
> > > > Apache Camel PMC Chair
> > > > Apache Karaf Committer
> > > > Apache Servicemix PMC Member
> > > > Email: ancosen1...@yahoo.com
> > > > Twitter: @oscerd2
> > > > Github: oscerd

Re: [VOTE] Release Apache Camel-K Runtime 0.3.0

[Willem Jiang]

Yes, I'm working on it now.
It should be fine in an hour or so.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Feb 27, 2019 at 3:05 PM Andrea Cosentino  wrote:
>
> Are you working on this? Otherwise I can take care of that.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Wednesday, February 27, 2019, 7:22:42 AM GMT+1, Willem Jiang 
>  wrote:
>
>
>
>
>
> Yeah, the staging artifacts are signed. But we need to provide a
> source package for vote.
> I just created a JIRA[1] and submit a quick fix for it . I think we
> should cancel this vote and do the release after the apply the patch.
>
> BTW, do we have any test project to help us to verify those staging artifacts?
>
> [1]https://issues.apache.org/jira/browse/CAMEL-13264
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Feb 27, 2019 at 1:56 PM Andrea Cosentino  
> wrote:
> >
> > And btw I think everything in the staging repo is already signed.
> >
> > Inviato da Yahoo Mail su Android
> >
> > Il mer, 27 feb, 2019 alle 6:53, Andrea Cosentino
> >  ha scritto:
> > We can add that in the next release. Can you cast your vote or do you want 
> > to start a new release?
> >
> > Inviato da Yahoo Mail su Android
> >
> >  Il mer, 27 feb, 2019 alle 2:09, Willem Jiang ha 
> > scritto:  I cannot find the source package link from the staging repo to do 
> > the
> > verify (make sure we can build the kit from scratch).
> > The source package[1] is quite important an Apache release.  We also
> > need a release sign for the kits.
> >
> > BTW,
> > The old camel source and binary release kits are also signed during the 
> > release.
> >
> > [1]http://www.apache.org/legal/release-policy.html#source-packages
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Tue, Feb 26, 2019 at 5:31 PM Andrea Cosentino
> >  wrote:
> > >
> > > Hello all:
> > >
> > > This is a vote to release Apache Camel-K runtime 0.3.0
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachecamel-1121/
> > >
> > > Tag: 
> > > https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=tag;h=ffce60741685f5385c4923200cc8d8adf4a9eaac
> > >
> > > This release is important because it introduce the split between camel-k 
> > > and camel-k-runtime bits and also an initial support for Camel 3 M1.
> > > Please test this release candidate and cast your vote.
> > > [ ] +1 Release the binary as Apache Camel-K 0.2.1
> > > [ ] -1 Veto the release (provide specific comments)
> > >
> > > The vote is open for at least 72 hours.
> > >
> > > Thanks,
> > > Andrea
> > >
> > > --
> > > Andrea Cosentino
> > > --
> > > Apache Camel PMC Chair
> > > Apache Karaf Committer
> > > Apache Servicemix PMC Member
> > > Email: ancosen1...@yahoo.com
> > > Twitter: @oscerd2
> > > Github: oscerd

Re: Re: [VOTE] Release Apache Camel-K Runtime 0.3.0

[Willem Jiang]

Yeah, the staging artifacts are signed. But we need to provide a
source package for vote.
I just created a JIRA[1] and submit a quick fix for it . I think we
should cancel this vote and do the release after the apply the patch.

BTW, do we have any test project to help us to verify those staging artifacts?

[1]https://issues.apache.org/jira/browse/CAMEL-13264

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Feb 27, 2019 at 1:56 PM Andrea Cosentino  wrote:
>
> And btw I think everything in the staging repo is already signed.
>
> Inviato da Yahoo Mail su Android
>
> Il mer, 27 feb, 2019 alle 6:53, Andrea Cosentino
>  ha scritto:
> We can add that in the next release. Can you cast your vote or do you want to 
> start a new release?
>
> Inviato da Yahoo Mail su Android
>
>   Il mer, 27 feb, 2019 alle 2:09, Willem Jiang ha 
> scritto:  I cannot find the source package link from the staging repo to do 
> the
> verify (make sure we can build the kit from scratch).
> The source package[1] is quite important an Apache release.  We also
> need a release sign for the kits.
>
> BTW,
> The old camel source and binary release kits are also signed during the 
> release.
>
> [1]http://www.apache.org/legal/release-policy.html#source-packages
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Feb 26, 2019 at 5:31 PM Andrea Cosentino
>  wrote:
> >
> > Hello all:
> >
> > This is a vote to release Apache Camel-K runtime 0.3.0
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1121/
> >
> > Tag: 
> > https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=tag;h=ffce60741685f5385c4923200cc8d8adf4a9eaac
> >
> > This release is important because it introduce the split between camel-k 
> > and camel-k-runtime bits and also an initial support for Camel 3 M1.
> > Please test this release candidate and cast your vote.
> > [ ] +1 Release the binary as Apache Camel-K 0.2.1
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 72 hours.
> >
> > Thanks,
> > Andrea
> >
> > --
> > Andrea Cosentino
> > --
> > Apache Camel PMC Chair
> > Apache Karaf Committer
> > Apache Servicemix PMC Member
> > Email: ancosen1...@yahoo.com
> > Twitter: @oscerd2
> > Github: oscerd

Re: [VOTE] Release Apache Camel-K Runtime 0.3.0

[Willem Jiang]

I cannot find the source package link from the staging repo to do the
verify (make sure we can build the kit from scratch).
The source package[1] is quite important an Apache release.  We also
need a release sign for the kits.

BTW,
The old camel source and binary release kits are also signed during the release.

[1]http://www.apache.org/legal/release-policy.html#source-packages

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Feb 26, 2019 at 5:31 PM Andrea Cosentino
 wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel-K runtime 0.3.0
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1121/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=tag;h=ffce60741685f5385c4923200cc8d8adf4a9eaac
>
> This release is important because it introduce the split between camel-k and 
> camel-k-runtime bits and also an initial support for Camel 3 M1.
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel-K 0.2.1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Andrea
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: [Camel-K] Moving the runtime in his own repo

[Willem Jiang]

That makes sense. Thanks for the clarification.
Here my +1.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Feb 21, 2019 at 5:22 PM Luca Burgazzoli  wrote:
>
> It is an interim solution till we have all the bits ready so we do not
> break the project
>
> On Thu, 21 Feb 2019 at 10:10, Willem Jiang  wrote:
>
> > Hi,
> >
> > I just have a quick question for the submodule of camel-k-runtime.
> > If we release the camel-k-runtime separately, do we need to put the
> > camel-k-runtime into camel-k repo as a submodule?
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Feb 21, 2019 at 4:32 PM Andrea Cosentino
> >  wrote:
> > >
> > > Hello all,
> > >
> > > We created a new repo https://github.com/apache/camel-k-runtime
> > >
> > > The aim of this repo is containing the runtime bits for Camel-k, so we
> > may be able to release it as a separated entity and use it in the camel-k
> > repository as dependency.
> > >
> > > We'll create a submodule in the camel-k repo until we release on central
> > the 0.2.1
> > >
> > > We'll add a note on the README in camel-k docs.
> > >
> > > Any thoughts?
> > >
> > > Thanks
> > > --
> > > Andrea Cosentino
> > > --
> > > Apache Camel PMC Chair
> > > Apache Karaf Committer
> > > Apache Servicemix PMC Member
> > > Email: ancosen1...@yahoo.com
> > > Twitter: @oscerd2
> > > Github: oscerd
> >
> --
> --
> Luca Burgazzoli

Re: [Camel-K] Moving the runtime in his own repo

[Willem Jiang]

Hi,

I just have a quick question for the submodule of camel-k-runtime.
If we release the camel-k-runtime separately, do we need to put the
camel-k-runtime into camel-k repo as a submodule?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Feb 21, 2019 at 4:32 PM Andrea Cosentino
 wrote:
>
> Hello all,
>
> We created a new repo https://github.com/apache/camel-k-runtime
>
> The aim of this repo is containing the runtime bits for Camel-k, so we may be 
> able to release it as a separated entity and use it in the camel-k repository 
> as dependency.
>
> We'll create a submodule in the camel-k repo until we release on central the 
> 0.2.1
>
> We'll add a note on the README in camel-k docs.
>
> Any thoughts?
>
> Thanks
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: [VOTE] Release Apache Camel 3.0.0-M1 (Milestone 1)

[Willem Jiang]

>From the Apache release policy, the source release is endorsed by ASF.
Even lots of user just consume the convenience binary, we still need
to keep the source artifact in a good sharp.

I just created a JIRA[1] to follow the issue.

[1]https://issues.apache.org/jira/browse/CAMEL-13240

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Feb 20, 2019 at 9:59 PM Claus Ibsen  wrote:
>
> On Wed, Feb 20, 2019 at 2:39 PM Willem Jiang  wrote:
> >
> > Yeah, we can fix it in next milestone.
> >
>
> Can you log a JIRA ticket.
>
> Although I dont think anyone uses the big .src zip anymore. Its all
> consumed via maven repos etc.
> And if you wanted to work with the source for a release, then its
> possible better/easier to get it via the tag from the git source repo.
>
>
>
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Feb 20, 2019 at 9:20 PM Andrea Cosentino
> >  wrote:
> > >
> > > I don't know if all agree about this, but I think that since this is just 
> > > a Milestone we can fix this in the next milestone.
> > >
> > > What do you think?
> > >
> > > --
> > > Andrea Cosentino
> > > --
> > > Apache Camel PMC Chair
> > > Apache Karaf Committer
> > > Apache Servicemix PMC Member
> > > Email: ancosen1...@yahoo.com
> > > Twitter: @oscerd2
> > > Github: oscerd
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wednesday, February 20, 2019, 2:15:26 PM GMT+1, Willem Jiang 
> > >  wrote:
> > >
> > >
> > >
> > >
> > >
> > > I just checked size of the source zip and binary zip.
> > > It's strange that the source artifact size is twiced than the binary one.
> > >
> > > I can find there are some binary files in the source zip by using find
> > > ./ -name "*.jar"
> > >
> > > .//tests/camel-itest/lib/org/apache/camel/camel-validator-test-resources/1.0.0/camel-validator-test-resources-1.0.0.jar
> > > .//components/camel-spring/src/test/resources/package_scan_test.jar
> > > .//components/camel-spring/src/test/resources/package+scan+test.jar
> > >
> > > I guess these binary files are only used for testing, from my
> > > understanding of the Apache release policy[1], we are not supposed to
> > > include binary files in the source release kit.
> > >
> > > [1]http://www.apache.org/legal/release-policy.html#what
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > >
> > > On Mon, Feb 18, 2019 at 3:23 PM Gregor Zurowski
> > >  wrote:
> > > >
> > > > Hi Everyone:
> > > >
> > > > This is a vote to release Apache Camel 3.0.0-M1, the first milestone
> > > > towards a new 3.0.0 major release with currently 366 improvements and
> > > > fixes.
> > > >
> > > > Release notes: 
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
> > > >
> > > > Staging repository:
> > > > https://repository.apache.org/content/repositories/orgapachecamel-1119/
> > > >
> > > > Tarballs: 
> > > > https://repository.apache.org/content/repositories/orgapachecamel-1119/org/apache/camel/apache-camel/3.0.0-M1/
> > > >
> > > > Tag: 
> > > > https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.0.0-M1
> > > >
> > > > Please test this release candidate and cast your vote.
> > > > [ ] +1 Release the binary as Apache Camel 3.0.0-M1
> > > > [ ] -1 Veto the release (provide specific comments)
> > > >
> > > > The vote is open for at least 72 hours.
> > > >
> > > > Thanks,
> > > > Gregor
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: [VOTE] Release Apache Camel 3.0.0-M1 (Milestone 1)

[Willem Jiang]

Oh, here is my +1.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Feb 20, 2019 at 9:39 PM Willem Jiang  wrote:
>
> Yeah, we can fix it in next milestone.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Feb 20, 2019 at 9:20 PM Andrea Cosentino
>  wrote:
> >
> > I don't know if all agree about this, but I think that since this is just a 
> > Milestone we can fix this in the next milestone.
> >
> > What do you think?
> >
> > --
> > Andrea Cosentino
> > --
> > Apache Camel PMC Chair
> > Apache Karaf Committer
> > Apache Servicemix PMC Member
> > Email: ancosen1...@yahoo.com
> > Twitter: @oscerd2
> > Github: oscerd
> >
> >
> >
> >
> >
> >
> > On Wednesday, February 20, 2019, 2:15:26 PM GMT+1, Willem Jiang 
> >  wrote:
> >
> >
> >
> >
> >
> > I just checked size of the source zip and binary zip.
> > It's strange that the source artifact size is twiced than the binary one.
> >
> > I can find there are some binary files in the source zip by using find
> > ./ -name "*.jar"
> >
> > .//tests/camel-itest/lib/org/apache/camel/camel-validator-test-resources/1.0.0/camel-validator-test-resources-1.0.0.jar
> > .//components/camel-spring/src/test/resources/package_scan_test.jar
> > .//components/camel-spring/src/test/resources/package+scan+test.jar
> >
> > I guess these binary files are only used for testing, from my
> > understanding of the Apache release policy[1], we are not supposed to
> > include binary files in the source release kit.
> >
> > [1]http://www.apache.org/legal/release-policy.html#what
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> >
> > On Mon, Feb 18, 2019 at 3:23 PM Gregor Zurowski
> >  wrote:
> > >
> > > Hi Everyone:
> > >
> > > This is a vote to release Apache Camel 3.0.0-M1, the first milestone
> > > towards a new 3.0.0 major release with currently 366 improvements and
> > > fixes.
> > >
> > > Release notes: 
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachecamel-1119/
> > >
> > > Tarballs: 
> > > https://repository.apache.org/content/repositories/orgapachecamel-1119/org/apache/camel/apache-camel/3.0.0-M1/
> > >
> > > Tag: 
> > > https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.0.0-M1
> > >
> > > Please test this release candidate and cast your vote.
> > > [ ] +1 Release the binary as Apache Camel 3.0.0-M1
> > > [ ] -1 Veto the release (provide specific comments)
> > >
> > > The vote is open for at least 72 hours.
> > >
> > > Thanks,
> > > Gregor

Re: [VOTE] Release Apache Camel 3.0.0-M1 (Milestone 1)

[Willem Jiang]

Yeah, we can fix it in next milestone.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Feb 20, 2019 at 9:20 PM Andrea Cosentino
 wrote:
>
> I don't know if all agree about this, but I think that since this is just a 
> Milestone we can fix this in the next milestone.
>
> What do you think?
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Wednesday, February 20, 2019, 2:15:26 PM GMT+1, Willem Jiang 
>  wrote:
>
>
>
>
>
> I just checked size of the source zip and binary zip.
> It's strange that the source artifact size is twiced than the binary one.
>
> I can find there are some binary files in the source zip by using find
> ./ -name "*.jar"
>
> .//tests/camel-itest/lib/org/apache/camel/camel-validator-test-resources/1.0.0/camel-validator-test-resources-1.0.0.jar
> .//components/camel-spring/src/test/resources/package_scan_test.jar
> .//components/camel-spring/src/test/resources/package+scan+test.jar
>
> I guess these binary files are only used for testing, from my
> understanding of the Apache release policy[1], we are not supposed to
> include binary files in the source release kit.
>
> [1]http://www.apache.org/legal/release-policy.html#what
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Mon, Feb 18, 2019 at 3:23 PM Gregor Zurowski
>  wrote:
> >
> > Hi Everyone:
> >
> > This is a vote to release Apache Camel 3.0.0-M1, the first milestone
> > towards a new 3.0.0 major release with currently 366 improvements and
> > fixes.
> >
> > Release notes: 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1119/
> >
> > Tarballs: 
> > https://repository.apache.org/content/repositories/orgapachecamel-1119/org/apache/camel/apache-camel/3.0.0-M1/
> >
> > Tag: 
> > https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.0.0-M1
> >
> > Please test this release candidate and cast your vote.
> > [ ] +1 Release the binary as Apache Camel 3.0.0-M1
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 72 hours.
> >
> > Thanks,
> > Gregor

Re: [VOTE] Release Apache Camel 3.0.0-M1 (Milestone 1)

[Willem Jiang]

I just checked size of the source zip and binary zip.
It's strange that the source artifact size is twiced than the binary one.

I can find there are some binary files in the source zip by using find
./ -name "*.jar"

.//tests/camel-itest/lib/org/apache/camel/camel-validator-test-resources/1.0.0/camel-validator-test-resources-1.0.0.jar
.//components/camel-spring/src/test/resources/package_scan_test.jar
.//components/camel-spring/src/test/resources/package+scan+test.jar

I guess these binary files are only used for testing, from my
understanding of the Apache release policy[1], we are not supposed to
include binary files in the source release kit.

[1]http://www.apache.org/legal/release-policy.html#what

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem


On Mon, Feb 18, 2019 at 3:23 PM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 3.0.0-M1, the first milestone
> towards a new 3.0.0 major release with currently 366 improvements and
> fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1119/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1119/org/apache/camel/apache-camel/3.0.0-M1/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.0.0-M1
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 3.0.0-M1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel-K 0.2.1

[Willem Jiang]

As the tag could be changed, it's better to specify the hash version
in the vote mail.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Feb 19, 2019 at 8:13 PM Andrea Cosentino
 wrote:
>
> Hello all:
>
> This is a vote to release Apache Camel-K 0.2.1 (runtime bits)
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1120/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=tag;h=refs/tags/camel-k-runtime-parent-0.2.1
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel-K 0.2.1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Andrea
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: Camel 3.0 milestone 1 soon ?

[Willem Jiang]

+1,

If we can identify the changes automatically, it could save us lot of
time for the migration guide.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Feb 2, 2019 at 2:43 PM Claus Ibsen  wrote:
>
> +1
>
> We need to improve the migration guide also.
> And we can test against the cia2 book spurce code too
>
> On Thu, 31 Jan 2019 at 22.49, Andrea Cosentino
>  wrote:
>
> > Totally agree. +1.
> > I think it's super important to have an early feedback of 3.0
> > Gregor Zurowski, will you be available in the coming week to cut the
> > release?
> > Thanks!
> >
> > Inviato da Yahoo Mail su Android
> >
> >   Il gio, 31 gen, 2019 alle 22:44, Guillaume Nodet ha
> > scritto:   Given the amount of work and refactoring that has been done the
> > past weeks
> > on the master branch, I wonder if it makes sense to consider releasing a
> > first milestone of Camel 3 in the coming weeks.
> > I think we should release a few milestones as early as possible rather than
> > waiting a lot and release a big band 3.0 version.  That will help us if
> > users can provide some early feedback.
> > Thoughts ?
> >
> > --
> > 
> > Guillaume Nodet
> >
> > --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: GitHub actions are available

[Willem Jiang]

Is there a Jenkins account that we can use in the Github?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Jan 31, 2019 at 4:12 PM Zoran Regvart  wrote:
>
> Hi Willem,
> I don't have an action to publish the website yet, but I'm
> considering/speculating about adding one. It would need to be a docker
> container with nodejs and yarn similar to what we use in the current
> Jenkins pipeline build[1][2].
>
> The reason I'm considering/speculating is that I don't feel that the
> current solution of using personal access token from by GitHub account
> is a good idea long term.
>
> zoran
>
> [1] https://github.com/apache/camel-website/blob/master/Jenkinsfile
> [2] https://github.com/apache/camel-website/blob/master/Dockerfile
>
> On Thu, Jan 31, 2019 at 2:35 AM Willem Jiang  wrote:
> >
> > It's nice to hear that. I'm quite interesting about that :)
> > Could you share more information about how to set up the action to
> > publish the website?
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Jan 31, 2019 at 5:32 AM Zoran Regvart  wrote:
> > >
> > > Hi Cameleers,
> > > seems that GitHub actions are available on apache organization. Could
> > > be just me but this is really exciting :)
> > >
> > > I'm thinking we could use this for the camel-website repository,
> > > perhaps even replacing Jenkins.
> > >
> > > For background, there's a whole discussion over at builds@ on not
> > > having an organization wide personal access token available, so the
> > > Jenkins pipeline is now configured with personal access token from my
> > > GitHub account.
> > >
> > > zoran
> > > --
> > > Zoran Regvart
>
>
>
> --
> Zoran Regvart

Re: GitHub actions are available

[Willem Jiang]

It's nice to hear that. I'm quite interesting about that :)
Could you share more information about how to set up the action to
publish the website?

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Jan 31, 2019 at 5:32 AM Zoran Regvart  wrote:
>
> Hi Cameleers,
> seems that GitHub actions are available on apache organization. Could
> be just me but this is really exciting :)
>
> I'm thinking we could use this for the camel-website repository,
> perhaps even replacing Jenkins.
>
> For background, there's a whole discussion over at builds@ on not
> having an organization wide personal access token available, so the
> Jenkins pipeline is now configured with personal access token from my
> GitHub account.
>
> zoran
> --
> Zoran Regvart

Re: [VOTE] Release Apache Camel 2.22.3

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Jan 20, 2019 at 3:22 AM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.22.3, a new patch release for
> the camel-2.22.x branch with 44 improvements and bug fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344398=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1117/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1117/org/apache/camel/apache-camel/2.22.3/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.22.3
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.22.3
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel 2.23.1

[Willem Jiang]

+1 binding.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Jan 13, 2019 at 3:45 AM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.23.1, the first patch release
> for the camel-2.23.x branch with 33 improvements and bug fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344567=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1116/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1116/org/apache/camel/apache-camel/2.23.1/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.23.1
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.23.1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [VOTE] Release Apache Camel 2.21.4

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jan 7, 2019 at 4:19 PM Gregor Zurowski  wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.21.4, the last planned patch
> release for the camel-2.21.x branch with 24 improvements and bug
> fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344344=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1115/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1115/org/apache/camel/apache-camel/2.21.4/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.21.4
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.21.4
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [CAMEL 3] Moving sandbox/camel-3.x to master

[Willem Jiang]

+1, let's start it.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Dec 17, 2018 at 10:32 PM Andrea Cosentino
 wrote:
>
> If it works for everyone the next steps should be:
>
> - On Wednesday morning I'll send an email with an alert about the creation of 
> 2.x branch from master
> - I'll move sanbox/camel-3.x to master shortly after pushing 2.x
>
> Does this work for all? Thoughts?
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Friday, December 14, 2018, 3:01:01 PM GMT+1, Andrea Cosentino 
>  wrote:
>
>
>
>
>
> Sure. Let me open a different one.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Friday, December 14, 2018, 2:59:22 PM GMT+1, Claus Ibsen 
>  wrote:
>
>
>
>
>
> Hi
>
> Can we please move the discussion about Java 8 and 11 to another
> thread, and keep this focused on the subj.
>
>
> On Fri, Dec 14, 2018 at 2:34 AM Willem Jiang  wrote:
> >
> > I think for the average the enterprise JDK user they may still use JDK
> > 8 for a long time.
> > If we start the Camel 3.x, we still need to maintain the Camel 2.x
> > branch for a while.
> > It could be great, if we can provide a roadmap of JDK8 support time,
> >
> > BTW,  Spring has good backward compatibility for JDK 6,7,8[1]
> > It could be useful if we can still provide the backward compatibility
> > in Camel 3.x and if we cannot do that we need to drop a line for it.
> >
> > [1]https://spring.io/blog/2015/04/03/how-spring-achieves-compatibility-with-java-6-7-and-8
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> > On Thu, Dec 13, 2018 at 3:19 PM Andrea Cosentino
> >  wrote:
> > >
> > > You're right, but if we always think about how much effort is needed to 
> > > switch to a new and different JDK, we will never move from JDK 8.
> > >
> > > I'd like to have other feedback on this by the way.
> > >
> > > For the compatibility matrix we need to it to the documentation too.
> > >
> > > --
> > > Andrea Cosentino
> > > --
> > > Apache Camel PMC Chair
> > > Apache Karaf Committer
> > > Apache Servicemix PMC Member
> > > Email: ancosen1...@yahoo.com
> > > Twitter: @oscerd2
> > > Github: oscerd
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thursday, December 13, 2018, 8:14:04 AM GMT+1, Onder SEZGIN 
> > >  wrote:
> > >
> > >
> > >
> > >
> > >
> > > Almost +1, (as points below affects the idea of where to using any camel 
> > > versions and even contributing because for example;
> > > if you use (let's say JDK 8) and have come across a problem and solved in 
> > > your local branch 2.X and submitted and if Camel 3.X would require JDK 10 
> > > as the base minimum version, it will create a regression effort, in terms 
> > > of building and executing on JDK 10. would it slow down the contribution 
> > > efforts? )
> > >
> > > Can we also discuss the matters of compatibility matrix? Maybe having one 
> > > like in starters guide or in some other document.
> > > I know we have pages [1] [2]
> > >
> > > [1] http://camel.apache.org/what-are-the-dependencies.html
> > > [2] 
> > > https://github.com/apache/camel/blob/master/docs/user-manual/en/camel-jar-dependencies.adoc
> > >
> > > Having such matrix considering other integration platforms would be 
> > > helpful IMHO.
> > > Such as Spring Boot, Karaf, CDI etcs...
> > >
> > >
> > >
> > >
> > > On Wed, Dec 12, 2018 at 3:12 PM Claus Ibsen  wrote:
> > > > On Wed, Dec 12, 2018 at 1:11 PM Andrea Cosentino 
> > > >  wrote:
> > > >>
> > > >> It makes sense to set a date.
> > > >>
> > > >> Once we checked the documentation and resolved doubts,
> > > >> I propose Wed 19th Dec in the morning.
> > > >>
> > > >> Does it work for all?
> > > >>
> > > >
> > > >

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Willem Jiang]

It's a great news.  +1 build Camel 3 on top of Java 11.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Dec 16, 2018 at 11:34 PM Claus Ibsen  wrote:
>
> On Sun, Dec 16, 2018 at 2:14 PM Zoran Regvart  wrote:
> >
> > Hi Cameleers,
> > my 2 cents on this is that we're now in a different situation than we
> > were 5-10 years before. It's all about individual deployments,
> > containers, microservices and such. Enterprises are moving away from
> > monolithic app servers and thick runtimes and the choice of Java
> > version is up to the individual applications.
> >
> > Coupled with the fact that soon enterprise will have to pay for Java 8
> > support[1][2] (which they might not do at the moment), they'd be eager
> > to switch to the next LTS release: 11 or 17.
> >
> > So I would keep a 2.x line with Java 8 as a base and backport fixes
> > there, and moving to Java 11 as base for 3.x. That would also allow us
> > to future proof our reactive story with the use of
> > java.util.concurrent.Flow (introduced in Java 9) in public facing
> > APIs.
> >
> > We have a chance to change APIs and break (some) backward
> > compatibility with a major version, I think with 3.x we're in a good
> > position to do that.
> >
>
> +1
>
> Yeah I would like to base Camel 3 on Java 11 as well. And its going to
> take about 1 year to
> get Camel 3 developed and released.
>
>
> > zoran
> >
> > [1] 
> > https://blogs.oracle.com/java-platform-group/end-of-public-updates-is-a-process%2c-not-an-event
> > [2] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
> > On Fri, Dec 14, 2018 at 3:03 PM Andrea Cosentino
> >  wrote:
> > >
> > > Hello,
> > >
> > > In the other thread about moving the master branch to 3.x, we started a 
> > > discussion around the Java supported version for Camel 3.
> > >
> > > Lets discuss this argument here.
> > >
> > > Thanks.
> > >
> > > --
> > > Andrea Cosentino
> > > --
> > > Apache Camel PMC Chair
> > > Apache Karaf Committer
> > > Apache Servicemix PMC Member
> > > Email: ancosen1...@yahoo.com
> > > Twitter: @oscerd2
> > > Github: oscerd
> >
> >
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: [CAMEL 3] Java 8 and Java 11 discussion

[Willem Jiang]

Hi,

I think for the average the enterprise JDK user they may still use JDK
8 for a very long time.
If we start the Camel 3.x to support JDK 11,  it doesn't mean that we
have to drop the backward compatibility of JDK 8.
Spring has good backward compatibility for JDK 6,7,8[1]. It could be
useful if we can still provide the backward compatibility in Camel 3.x
and if we cannot do that we need to drop a line for it (it depends how
may new feature of JDK 11 we use).

It could be great, if we have a clean roadmap of JDK8, JDK11 support time.

[1]https://spring.io/blog/2015/04/03/how-spring-achieves-compatibility-with-java-6-7-and-8

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Dec 14, 2018 at 10:03 PM Andrea Cosentino
 wrote:
>
> Hello,
>
> In the other thread about moving the master branch to 3.x, we started a 
> discussion around the Java supported version for Camel 3.
>
> Lets discuss this argument here.
>
> Thanks.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: [CAMEL 3] Moving sandbox/camel-3.x to master

[Willem Jiang]

I think for the average the enterprise JDK user they may still use JDK
8 for a long time.
If we start the Camel 3.x, we still need to maintain the Camel 2.x
branch for a while.
It could be great, if we can provide a roadmap of JDK8 support time,

BTW,  Spring has good backward compatibility for JDK 6,7,8[1]
It could be useful if we can still provide the backward compatibility
in Camel 3.x and if we cannot do that we need to drop a line for it.

[1]https://spring.io/blog/2015/04/03/how-spring-achieves-compatibility-with-java-6-7-and-8

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Dec 13, 2018 at 3:19 PM Andrea Cosentino
 wrote:
>
> You're right, but if we always think about how much effort is needed to 
> switch to a new and different JDK, we will never move from JDK 8.
>
> I'd like to have other feedback on this by the way.
>
> For the compatibility matrix we need to it to the documentation too.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Thursday, December 13, 2018, 8:14:04 AM GMT+1, Onder SEZGIN 
>  wrote:
>
>
>
>
>
> Almost +1, (as points below affects the idea of where to using any camel 
> versions and even contributing because for example;
> if you use (let's say JDK 8) and have come across a problem and solved in 
> your local branch 2.X and submitted and if Camel 3.X would require JDK 10 as 
> the base minimum version, it will create a regression effort, in terms of 
> building and executing on JDK 10. would it slow down the contribution 
> efforts? )
>
> Can we also discuss the matters of compatibility matrix? Maybe having one 
> like in starters guide or in some other document.
> I know we have pages [1] [2]
>
> [1] http://camel.apache.org/what-are-the-dependencies.html
> [2] 
> https://github.com/apache/camel/blob/master/docs/user-manual/en/camel-jar-dependencies.adoc
>
> Having such matrix considering other integration platforms would be helpful 
> IMHO.
> Such as Spring Boot, Karaf, CDI etcs...
>
>
>
>
> On Wed, Dec 12, 2018 at 3:12 PM Claus Ibsen  wrote:
> > On Wed, Dec 12, 2018 at 1:11 PM Andrea Cosentino  
> > wrote:
> >>
> >> It makes sense to set a date.
> >>
> >> Once we checked the documentation and resolved doubts,
> >> I propose Wed 19th Dec in the morning.
> >>
> >> Does it work for all?
> >>
> >
> > +1
> >
> >> Thanks.
> >>
> >> --
> >> Andrea Cosentino
> >> --
> >> Apache Camel PMC Chair
> >> Apache Karaf Committer
> >> Apache Servicemix PMC Member
> >> Email: ancosen1...@yahoo.com
> >> Twitter: @oscerd2
> >> Github: oscerd
> >>
> >>
> >> On Wednesday, December 12, 2018, 1:09:05 PM GMT+1, Claus Ibsen 
> >>  wrote:
> >>
> >>
> >> On Wed, Dec 12, 2018 at 12:14 PM Guillaume Nodet  wrote:
> >> >
> >> > Sounds good to me.
> >> >
> >> > Fwiw, I've been working on the camel build those past days, trying to
> >> > improve things a bit.  I'll report when I have something in a correct 
> >> > shape.
> >> >
> >>
> >> What if we set a date when we make the change? For example Friday 14th
> >> December or Monday 17th eg?
> >>
> >> And we would need to update the contributing document
> >> with a section about that Camel 2.x is now located in the 2.x branch,
> >> and that master is for 3.x.
> >>
> >> I wonder if this change will affect the current release procedure of
> >> Camel 2.x? For example when we need to do next round of patch releases
> >> for 2.x and also the new 2.24.0 release,
> >> is there something we need to update our release guides at
> >> http://camel.apache.org/release-guide.html
> >>
> >> Gregor if you are listening, is there something on-top-of your head
> >> you can think of?
> >>
> >>
> >>
> >>
> >>
> >> > Guillaume
> >> >
> >> > Le mer. 12 déc. 2018 à 11:54, Andrea Cosentino
> >> >  a écrit :
> >> >
> >> > > Hello,
> >> > >
> >> > > Since we started work of some cleanup about Camel 3 and it's already
> >> > > aligned with master, I'd like to ask what do you think about switching 
> >> > > the
> >> > > master to 3.x and create a 2.x branch for the activities on Camel 2.x..
> >> > >
> >> > > What do you think about this?
> >> > >
> >> > > Thanks
> >> > >
> >> > > --
> >> > > Andrea Cosentino
> >> > > --
> >> > > Apache Camel PMC Chair
> >> > > Apache Karaf Committer
> >> > > Apache Servicemix PMC Member
> >> > > Email: ancosen1...@yahoo.com
> >> > > Twitter: @oscerd2
> >> > > Github: oscerd
> >> > >
> >> >
> >> >
> >> > --
> >> > 
> >> > Guillaume Nodet
> >>
> >>
> >>
> >>
> >> --
> >> 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: Create an Apache Camel Twitter Account

[Willem Jiang]

+1.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Dec 13, 2018 at 9:22 PM Zoran Regvart  wrote:
>
> +1
>
> Seems that @ApacheCamel on Twitter was abandoned, perhaps it's also
> inactive[1] and I don't mean to be rude or aggressive but it seems
> that this individual is also squatting[2] and/or violating the
> trademark policy[3].
>
> If everyone is on board with this I think it should be a simple as
> reporting a trademark violation to Twitter[4] to gain access to that
> Twitter handle.
>
> zoran
>
> [1] https://help.twitter.com/en/rules-and-policies/inactive-twitter-accounts
> [2] https://help.twitter.com/en/rules-and-policies/twitter-username-squatting
> [3] https://help.twitter.com/en/rules-and-policies/twitter-trademark-policy
> [4] https://help.twitter.com/forms/trademark
> On Thu, Dec 13, 2018 at 1:14 PM Andrea Cosentino
>  wrote:
> >
> > What do you think about this? It could be useful to share news, posts etc.
> >
> > Feedback welcome.
> >
> > --
> > Andrea Cosentino
> > --
> > Apache Camel PMC Chair
> > Apache Karaf Committer
> > Apache Servicemix PMC Member
> > Email: ancosen1...@yahoo.com
> > Twitter: @oscerd2
> > Github: oscerd
>
>
>
> --
> Zoran Regvart

Re: [HEADS UP] Work on Apache Camel 3 is beginning

[Willem Jiang]

Thanks for th Zoran, I think website is quite important for the user
find the documents and solutions.
We definitely could get some help from the community if we put it into
the roadmap.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Dec 11, 2018 at 10:18 PM Zoran Regvart  wrote:
>
> Hi Cameleers,
> exciting times ahead indeed :)
>
> I'd like to put the new website and work around Java 11 compatibility
> on the roadmap.
>
> I had a couple of days to experiment with Antora for the user manual
> and component documentation and thus far it seems very promising. Once
> I merry this with the Hugo static site generator for the rest of the
> pages we'll have a rough first pass of the new website (hope on doing
> that soon). We've had a great deal of interest in getting this done
> and few folks already helped or announced their willingness to help.
> And I'm not saying that the website will be done for Camel 3 release,
> I'd actually like to see it done in the next 1-2 months.
>
> For the Java 11 support, I think this should go in to the 2.x with our
> current approach of testing on Java 11 and upgrading component
> dependencies when they're Java 11 ready. All work on this is in the
> `java-10-test` branch. One thought I had is that we could introduce a
> `camel-java11-compat` dependency that would bring in the JEE APIs
> (JAXB and the rest) that were removed from Java 11. For Camel 3,
> perhaps we can make Java 11 the base minimum version -- would be good
> to get some feedback on this. One more thing we could try to evaluate
> is the use of Java modules, Camel 3, IMHO, should at least be Java
> module ready, i.e. have `Automatic-Module-Name` in the manifest.
> Perhaps we can count the number of component dependencies that are
> usable on the module path and see if we can go ahead and add
> `module-info.java` in (some?) of the components.
>
> zoran
> On Tue, Dec 11, 2018 at 2:59 PM Andrea Cosentino
>  wrote:
> >
> > Hello Camelers,
> >
> > We are starting the work on Apache Camel 3. We are working at multiple 
> > levels to improve Camel and introduce new features.
> >
> > The first work has actually started by Guillaume Nodet in the start of 
> > October, where he jump started by cleaning up the codebase, removed 
> > deprecated code and components, improving the routing engine and other 
> > internals in the core. His work is published on the sandbox/3.x branch. We 
> > plan to use his work as the baseline for the actual Camel 3. I have helped 
> > by aligning this branch with all the changes from the master branch (2.x) 
> > so its fully up to date. The intention is to switch over the sandbox/3.x 
> > branch as the new master branch, so we can start working on that branch and 
> > being able to add new features, components etc. (as always) for Camel 3.
> >
> > For 2.x users we will create a 2.x branch where we plan to do 1 or 2 more 
> > last 2.x releases, eg 2.24 and 2.25, before 3.0 is ready and released.
> >
> > Here in the beginning of the Camel 3 work is to continue the work from 
> > Guillaume Nodet and finish up the cleanup of the codebase, modularize the 
> > camel-core, etc.
> >
> > We invite community users and any Camel committers and developers who has 
> > interest to help with the Camel 3 work. We have talked about doing a number 
> > of milestone releases of 3.x that can help give feedback to us quicker and 
> > faster. For example any Camel users of 2.x can try to upgrade and use the 
> > 3.0 milestone releases to report back their findings.
> >
> > Over the coming weeks it would be good if we could work on the roadmap and 
> > a rough timetable for Camel 3 so we can sketch out the first set of goals 
> > for the first milestone release and then rinse and repeat for the upcoming 
> > milestone releases.
> >
> > We have also talked about letting Camel 3 be a timeboxed release to avoid 
> > it dragging out “forever”. It would be great if we can build and release 
> > Camel 3 within 1 year of development, for example maybe try to aim for a 
> > release in Q3 2019.
> >
> > We will keep the community posted on the progress, and as always we love 
> > contribution and any feedback.
> >
> > Exciting times ahead!
> >
> > Thoughts?
> >
> > Claus & Andrea
> >
> > --
> > Andrea Cosentino
> > --
> > Apache Camel PMC Chair
> > Apache Karaf Committer
> > Apache Servicemix PMC Member
> > Email: ancosen1...@yahoo.com
> > Twitter: @oscerd2
> > Github: oscerd
>
>
>
> --
> Zoran Regvart

Re: [HEADS UP] Work on Apache Camel 3 is beginning

[Willem Jiang]

+1 to start Camel 3. I'd be happy to join the development.
Let's make it happen by discussion the roadmap first.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Dec 11, 2018 at 9:59 PM Andrea Cosentino
 wrote:
>
> Hello Camelers,
>
> We are starting the work on Apache Camel 3. We are working at multiple levels 
> to improve Camel and introduce new features.
>
> The first work has actually started by Guillaume Nodet in the start of 
> October, where he jump started by cleaning up the codebase, removed 
> deprecated code and components, improving the routing engine and other 
> internals in the core. His work is published on the sandbox/3.x branch. We 
> plan to use his work as the baseline for the actual Camel 3. I have helped by 
> aligning this branch with all the changes from the master branch (2.x) so its 
> fully up to date. The intention is to switch over the sandbox/3.x branch as 
> the new master branch, so we can start working on that branch and being able 
> to add new features, components etc. (as always) for Camel 3.
>
> For 2.x users we will create a 2.x branch where we plan to do 1 or 2 more 
> last 2.x releases, eg 2.24 and 2.25, before 3.0 is ready and released.
>
> Here in the beginning of the Camel 3 work is to continue the work from 
> Guillaume Nodet and finish up the cleanup of the codebase, modularize the 
> camel-core, etc.
>
> We invite community users and any Camel committers and developers who has 
> interest to help with the Camel 3 work. We have talked about doing a number 
> of milestone releases of 3.x that can help give feedback to us quicker and 
> faster. For example any Camel users of 2.x can try to upgrade and use the 3.0 
> milestone releases to report back their findings.
>
> Over the coming weeks it would be good if we could work on the roadmap and a 
> rough timetable for Camel 3 so we can sketch out the first set of goals for 
> the first milestone release and then rinse and repeat for the upcoming 
> milestone releases.
>
> We have also talked about letting Camel 3 be a timeboxed release to avoid it 
> dragging out “forever”. It would be great if we can build and release Camel 3 
> within 1 year of development, for example maybe try to aim for a release in 
> Q3 2019.
>
> We will keep the community posted on the progress, and as always we love 
> contribution and any feedback.
>
> Exciting times ahead!
>
> Thoughts?
>
> Claus & Andrea
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd

Re: [VOTE] Release Apache Camel 2.22.2

[Willem Jiang]

+1 (binding).

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Nov 2, 2018 at 2:24 PM Gregor Zurowski  wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.22.2, a patch release for the
> camel-2.22.x branch with 37 improvements and bug fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344006=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1113/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1113/org/apache/camel/apache-camel/2.22.2/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.22.2
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.22.2
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [FOSDEM] FOSDEM 2019 Free Java Dev Room Call For Participation

[Willem Jiang]

Hi Zoran,

I'd like to attend this meeting and share some experiences of moving
the enterprise application into Cloud with Camel.
Please let me know what I need to do next.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Oct 22, 2018 at 4:27 PM Zoran Regvart  wrote:
>
> Hi,
> so I'll reply here on topic, I'd like to encourage anyone to have a
> talk at FOSDEM about Camel (well about anything you like really[1],
> but I'd like it to be about Camel :).
>
> I think Free Java Dev Room is a good place to talk about Camel,
> perhaps a lightning talk there would be nice.
>
> I offer my help with the writing the submission, presentation material
> or anything really to anyone wishing to participate :)
>
> zoran
>
> [1] https://fosdem.org/2019/news/2018-10-14-accepted-developer-rooms/
> --
> Zoran Regvart

Re: [VOTE] Release Apache Camel 2.21.3

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sun, Oct 21, 2018 at 11:27 PM Gregor Zurowski
 wrote:
>
> Hi Everyone:
>
> This is a vote to release Apache Camel 2.21.3, a patch release for the
> camel-2.21.x branch with 43 improvements and bug fixes.
>
> Release notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343751=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1112/
>
> Tarballs: 
> https://repository.apache.org/content/repositories/orgapachecamel-1112/org/apache/camel/apache-camel/2.21.3/
>
> Tag: 
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.21.3
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.21.3
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor

Re: [HEADS UP] Camel K is here!

[Willem Jiang]

Yeah,  it's great to see we can use Camel more easily with K8S.
It's awesome that camel-k can be a part of Camel 3 :)

Regards,

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Oct 17, 2018 at 6:24 AM Nicola Ferraro  wrote:
>
> Hi folks,
> after some months of brainstorming with the community and a bit more than
> one month of development, our Camel K project has reached a good level of
> stability and I've published the first blog post about it yesterday.
>
> For those of you who haven't heard of Camel K, it's now a subproject of
> Apache Camel (https://github.com/apache/camel-k) with the target of
> building a lightweight runtime for running integration code directly on
> cloud platforms like Kubernetes and Openshift. It was inspired by
> "serverless" principles and it will also target Knative shortly.
>
> With the exception of the runtime code, that remains the good old Camel
> Java framework with 200+ components and full of EIPs, most of the
> "operator" code in Camel K is written in Go. But the new language has not
> stopped many adventurer Camel developers that have actively contributed to
> the project during last month. We still have a long way in front of us,
> let's continue to make Camel great!
>
> So, please.. check the project out! Spread it to the world!
> And provide your feedback, so we can make it always better. We love any
> kind of contribution!
>
> Links follow..
>
> Announcement: https://twitter.com/ni_ferraro/status/1051872786946363392
> Article: https://www.nicolaferraro.me/2018/10/15/introducing-camel-k/
> Home: https://github.com/apache/camel-k
>
> Nicola

Re: [VOTE] Release Apache Camel 2.22.1

[Willem Jiang]

+1 (binding)

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem


On Sun, Sep 2, 2018 at 8:49 PM Gregor Zurowski 
wrote:

> Hi Everyone:
>
> This is a vote to release Apache Camel 2.22.1, the first patch release
> for the camel-2.22.x branch with 47 improvements and bug fixes.
>
> Release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343346=12311211
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-/
>
> Tarballs:
> https://repository.apache.org/content/repositories/orgapachecamel-/org/apache/camel/apache-camel/2.22.1/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-2.22.1
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as Apache Camel 2.22.1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor
>