Re: GitHub discussions for Apache Camel project

[Tadayoshi Sato]

+1 Sounds like a great idea!

On Mon, Aug 14, 2023 at 10:43 PM Claus Ibsen  wrote:

> Hi
>
> We have talked about opening up for GH discussions at
> https://github.com/apache/camel
>
> This allows more community users to more easily get involved, and ask for
> help, and whatnot.
>
> Also for technical discussion, then instead of DEV mailing list, then its
> maybe easier on GH as we can more easily link to existing source code,
> projects when its technical.
>
> We would then need to setup GH discussions in a way so users can find space
> for support/help, and another space where we can have roadmap and
> design/tech discussions etc.
>
> For big organisational decisions and whatnot,
> then we should still use the DEV mailing list.
>
> Any thoughts?
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel Kamelets 3.20.0

[Tadayoshi Sato]

+1 (non-binding)

Thanks!

On Wed, Dec 21, 2022 at 10:26 PM Andrea Cosentino  wrote:

> Hello all:
>
> This is a vote for releasing camel-kamelets 3.20.0
>
> The release contains fixes and it's updated to Camel 3.20.0.
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/3.20.0
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1510
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v3.20.0
>
> Please cast your vote.
>
> [ ] +1 Release camel-kamelets 3.20.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: [HEADS UP] Camel-Kamelets moving to 3.20.0 version

[Tadayoshi Sato]

Wow, great milestone!  Thanks Andrea!

On Wed, Dec 21, 2022 at 2:54 AM Andrea Cosentino
 wrote:

> Hello,
>
> I finished to move the version of camel-kamelets to 3.20.0-SNAPSHOT.
>
> This means the next release will be 3.20.0, instead of 0.11.0. This is
> related to multiple aspects:
> - Kamelets are no more just a building block of Camel K
> - Kamelets are now part of all the runtimes
>
> So it makes sense to move to a version semantically aligned with the Camel
> Core version.
>
> Thanks for reading.
>
> Cheers.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>


-- 
Tadayoshi Sato

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

[Tadayoshi Sato]

On Sun, Dec 18, 2022 at 6:16 PM Andrea Cosentino  wrote:

> +1 (binding)
>
> I think we should add a step in release guide, about increasing the camel
> jbang version right before releasing the whole Camel project.
>
> So we won't forget.
>

Thanks. I'll update the guide shortly.


>
> Il dom 18 dic 2022, 10:12 Claus Ibsen  ha scritto:
>
> > +1 (binding)
> >
> > Tested with CiA2 source code
> >
> > On Sat, Dec 17, 2022 at 12:35 PM Gregor Zurowski <
> gre...@list.zurowski.org
> > >
> > wrote:
> >
> > > Hi Everyone:
> > >
> > > This is a vote to release Apache Camel 3.20.0, a new LTS release with
> > > 205 improvements and fixes.
> > >
> > > Release notes:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352266=12311211
> > >
> > > == Apache Camel 3.20.0 ==
> > >
> > > Staging repository:
> > >
> https://repository.apache.org/content/repositories/orgapachecamel-1506/
> > >
> > > Tarballs:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecamel-1506/org/apache/camel/apache-camel/3.20.0/
> > >
> > > Tag:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.20.0
> > >
> > > == Apache Camel Spring Boot 3.20.0 ==
> > >
> > > Staging repository:
> > >
> https://repository.apache.org/content/repositories/orgapachecamel-1508/
> > >
> > > Tag:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel-spring-boot.git;a=tag;h=refs/tags/camel-spring-boot-3.20.0
> > >
> > > == Apache Camel Karaf 3.20.0 ==
> > >
> > > Staging repository:
> > >
> https://repository.apache.org/content/repositories/orgapachecamel-1509/
> > >
> > > Tag:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel-karaf.git;a=tag;h=refs/tags/camel-karaf-3.20.0
> > >
> > > Please test this release candidate and cast your vote:
> > > [ ] +1 Release the binary as Apache Camel, Camel Spring Boot and Camel
> > > Karaf 3.20.0
> > > [ ] -1 Veto the release (provide specific comments)
> > >
> > > The vote is open for at least 72 hours.
> > >
> > > Thanks,
> > > Gregor
> > >
> >
> >
> > --
> > Claus Ibsen
> > -
> > @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>


-- 
Tadayoshi Sato

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

[Tadayoshi Sato]

Hi,

Sorry for the delay, but is it possible to have it in the camel-3.20.0
release?
https://github.com/apache/camel/pull/8914

If it can be merged right before 3.20.0 release, then we can allow users to
install the exact 3.20.0 version by doing like this:

$ jbang app install camel@apache/camel/camel-3.20.0

Right now, by doing this camel-jbang 3.19.0 is installed.

If it's too late, then it's ok. We can still let users install the latest
3.20.x release by doing `jbang app install camel@apache/camel/camel-3.20.x`,
but the opportunity to choose the exact version will be lost.

IMHO, it's a good practice to increase the camel-jbang version right before
releasing a Camel version, so that users can choose the exact versions. I
don't think it's a problem that the version to be released is not yet
present in the Maven Central repo for Camel JBang for the short time.

Best regards,
Tadayoshi

On Sat, Dec 17, 2022 at 8:35 PM Gregor Zurowski 
wrote:

> Hi Everyone:
>
> This is a vote to release Apache Camel 3.20.0, a new LTS release with
> 205 improvements and fixes.
>
> Release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352266=12311211
>
> == Apache Camel 3.20.0 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1506/
>
> Tarballs:
> https://repository.apache.org/content/repositories/orgapachecamel-1506/org/apache/camel/apache-camel/3.20.0/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.20.0
>
> == Apache Camel Spring Boot 3.20.0 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1508/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-spring-boot.git;a=tag;h=refs/tags/camel-spring-boot-3.20.0
>
> == Apache Camel Karaf 3.20.0 ==
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1509/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=camel-karaf.git;a=tag;h=refs/tags/camel-karaf-3.20.0
>
> Please test this release candidate and cast your vote:
> [ ] +1 Release the binary as Apache Camel, Camel Spring Boot and Camel
> Karaf 3.20.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thanks,
> Gregor
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel K 1.11.0 and related libraries

[Tadayoshi Sato]

Thanks Andrea!

+1

On Wed, Dec 7, 2022 at 7:20 PM Andrea Cosentino  wrote:

> Hello all:
>
> This is a combined vote to release Apache Camel K 1.11.0, Camel K Runtime
> 1.16.0 and Kamelets 0.10.0.
>
> This is a patch release based on Camel-Quarkus 2.14.0 and Camel 3.19.0 and
> contains several bug fixes and improvements.
>
> Runtime source files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.16.0/
> Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1499
> Runtime Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-project-1.16.0
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/0.10.0/
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1500
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v0.10.0
>
> Camel K release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.11.0/
> Camel K Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.11.0
>
> 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.11.0 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1499
>  --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1500
>  --olm=false
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel K 1.11.0, Apache Camel K Runtime
> 1.16.0 and Apache Camel Kamelets 0.10.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: Evolution of Kamelets

[Tadayoshi Sato]

t; > > > - It works? Cool. It doesn't work? Let's see why
> > > > - My integration is now stable, I want to pass to another level. I
> > could
> > > > still use the kamelets, but also I could switch to a full Camel
> route.
> > > Let
> > > > me select my runtime: Quarkus, Spring Boot, Camel K or plain camel.
> Let
> > > me
> > > > export the project to my selected runtime.
> > > > - Ready to go.
> > > >
> > > > All of this could also pass through Camel-Karavan, without touching
> > code,
> > > > or touching very few lines of code. We have really a lot of power
> and a
> > > lot
> > > > of stuff to improve.
> > > >
> > > > In my opinion we should work on multiple sides:
> > > > - make it possible to load different kamelet catalogs (complex cases,
> > > > custom kamelets, etc.)
> > > > - improve the default Kamelets catalog
> > > > - Focus on the camel-jbang experience
> > > > - Maybe try to think about a Kamelets Marketplace or catalog
> > marketplace
> > > >
> > > > My proposal is also to note in terms of documentation that kamelets
> are
> > > not
> > > > only tied to Camel K, but some fundamental building block in the
> Camel
> > > > experience.
> > > >
> > > > I think we should create some epic around this and try to follow this
> > > path.
> > > >
> > > > Any feedback, comments and thoughts are welcome. Please let me know
> > what
> > > > you think.
> > > >
> > > > Cheers,
> > > > Andrea
> > > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -
> > > @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
> >
>
>
> --
> Otavio R. Piske
> http://orpiske.net
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel K 1.10.3 and Camel K Runtime 1.15.2

[Tadayoshi Sato]

+1
Thanks Andrea!

On Fri, Nov 11, 2022 at 6:31 PM Andrea Cosentino  wrote:

> Hello,
>
> This is a combined vote to release Apache Camel K 1.10.3 and Camel K
> Runtime
> 1.15.2.
>
> We are upgrading to Camel 3.18.3 and Camel-Kamelets 0.9.3, this means
> Camel-Quarkus will be updated to 2.13.1.
>
> Runtime source files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.15.2/
> Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1495
> Runtime Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-project-1.15.2
>
> Camel K release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.10.3/
> Camel K Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.10.3
>
> 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.10.3 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1495
>  --olm=false
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel K 1.10.3 and
> Apache Camel K Runtime
> 1.15.2
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel Kamelets 0.9.3

[Tadayoshi Sato]

+1

Thanks!

On Fri, Nov 4, 2022 at 6:33 PM Andrea Cosentino  wrote:

> Hello all:
>
> This is a vote for releasing only camel-kamelets 0.9.3.
>
> The release contains fixes and it's updated to Camel 3.18.3.
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/0.9.3/
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1494
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v0.9.3
>
> Please cast your vote.
>
> [ ] +1 Release camel-kamelets 0.9.3
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel Kamelets 0.9.2

[Tadayoshi Sato]

+1

Thanks Andrea!

On Wed, Oct 26, 2022 at 5:24 PM Andrea Cosentino  wrote:

> Hello all:
>
> This is a vote for releasing only camel-kamelets 0.9.2.
>
> The release contains fixes.
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/0.9.2/
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1488
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v0.9.2
>
> Please cast your vote.
>
> [ ] +1 Release camel-kamelets 0.9.2
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 48 hours.
>
> NOTE: The vote for 48 hours is because there are no breaking changes but
> the release is not really urgent.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: Extend LTS concept to Camel K

[Tadayoshi Sato]

Hi Andrea,


> It makes sense, we need to find a way to rotate the release manager,
> because especially post-release steps are time-consuming.
>

I can volunteer for the release manager for Camel K. Let me know how I can
help.

On Tue, Sep 13, 2022 at 9:10 PM Andrea Cosentino  wrote:

> It makes sense, we need to find a way to rotate the release manager,
> because especially post-release steps are time-consuming.
>
> But in the end it makes sense to follow LTS approach for both camel-k and
> camel-k-runtime, for the latter until we find a way to integrate the
> codebase in camel-quarkus directly.
>
> Il giorno mar 13 set 2022 alle ore 13:44 Claudio Miranda <
> clau...@claudius.com.br> ha scritto:
>
> > On Tue, Sep 13, 2022 at 7:31 AM Pasquale Congiusti
> >  wrote:
> > >
> > > I am not sure if this was discussed in the past, but here goes my
> > proposal
> > > to officially extend the LTS concept to Camel K releases as well. Since
> > we
> >
> > Sure, the LTS is a good idea for users and developers, +1.
> >
> > Camel has the LTS releases, and camel quarkus [1] seems to have a LTS
> > too, but there is no camel-k-runtime LTS.
> > In this case the LTS concept would be extended to camel-k-runtime and
> > sync the Camel K LTS with the camel quarkus/camel LTS releases ?
> >
> > 1. https://camel.apache.org/camel-quarkus/next/index.html
> >
> > --
> >   Claudio Miranda
> >
> > clau...@claudius.com.br
> > http://www.claudius.com.br
> >
>


-- 
Tadayoshi Sato

Re: Extend LTS concept to Camel K

[Tadayoshi Sato]

+1 for having LTS releases for Camel K.

On Tue, Sep 13, 2022 at 7:31 PM Pasquale Congiusti <
pasquale.congiu...@gmail.com> wrote:

> Hi folks,
> I am not sure if this was discussed in the past, but here goes my proposal
> to officially extend the LTS concept to Camel K releases as well. Since we
> depend on Camel Quarkus and Camel framework for the runtime, we should
> follow the same path in order to be able to apply any fix/upgrade in the
> proper release version. For example, right now we're not actively
> supporting the 1.8 release, which is based on Camel Quarkus 2.7 and Camel
> 3.14 (both LTS). I think it would be good from a user point of view,
> relying on some long time support release. Also from the developer point of
> view, it will give us a certain capability to plan ahead of time on which
> release to focus to enable more stability.
>
> Please, share your feedback.
>
> Regards,
> Pasquale.
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel K 1.10.0 and related libraries

[Tadayoshi Sato]

+1

Thank you Andrea!

On Wed, Aug 31, 2022 at 8:55 PM Andrea Cosentino  wrote:

> Hello all:
>
> This is a combined vote to release Apache Camel K 1.10.0, Camel K Runtime
> 1.14.0 and Kamelets 0.9.0.
>
> This is a patch release based on Camel-Quarkus 2.11.3 and Camel 3.18.0 and
> contains several bug fixes and improvements.
>
> Runtime source files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.14.0/
> Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1465
> Runtime Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-project-1.14.0
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/0.9.0/
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1461
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v0.9.0
>
> Camel K release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.10.0/
> Camel K Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.10.0
>
> 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.10.0 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1465
>  --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1461
>  --olm=false
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel K 1.10.0, Apache Camel K Runtime
> 1.14.0 and Apache Camel Kamelets 0.9.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel K 1.9.0 and related libraries

[Tadayoshi Sato]

+1

Thanks Andrea!

On Thu, Apr 21, 2022 at 8:26 PM Andrea Cosentino  wrote:

> Just a little correction: for camel-k the tag is the following
>
>
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.9.0
>
> Il giorno gio 21 apr 2022 alle ore 13:23 Andrea Cosentino <
> anco...@gmail.com>
> ha scritto:
>
> > Hello all:
> >
> > This is a combined vote to release Apache Camel K 1.9.0, Camel K Runtime
> > 1.13.0 and Kamelets 0.8.0.
> >
> > This is a patch release based on Camel-Quarkus 2.8.0 and Camel 3.16.0 and
> > contains several bug fixes and improvements.
> >
> > Runtime source files:
> > https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.13.0/
> > Runtime staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1427
> > Runtime Tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-project-1.13.0
> >
> > Kamelets release files:
> > https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/0.8.0/
> > Kamelets staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1426
> > Kamelets Tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v0.8.0
> >
> > Camel K release files:
> > https://dist.apache.org/repos/dist/dev/camel/camel-k/1.9.0/
> > Camel K Tag:
> > https://gitbox.apache.org/repos/asf?p=camel-k
> > .git;a=shortlog;h=refs/tags/v1.8.1
> >
> > 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.9.0 --maven-repository=
> > https://repository.apache.org/content/repositories/orgapachecamel-1426
> >  --maven-repository=
> > https://repository.apache.org/content/repositories/orgapachecamel-1427
> >  --olm=false
> >
> > Please test this release candidate and cast your vote.
> >
> > [ ] +1 Release the binary as Apache Camel K 1.9.0, Apache Camel K Runtime
> > 1.13.0 and Apache Camel Kamelets 0.8.0
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 72 hours.
> >
> > Here's my +1.
> >
> > Thanks,
> > Andrea Cosentino
> >
>


-- 
Tadayoshi Sato

Re: Camel K 1.9.0 Release

[Tadayoshi Sato]

FYI: https://github.com/apache/camel-k/pull/3204

On Thu, Apr 14, 2022 at 3:20 PM Tadayoshi Sato 
wrote:

> I just found one bug in Camel K CLI:
> https://github.com/apache/camel-k/issues/3203
>
> It doesn't look cool and IMO is better to be fixed before 1.9.0.
>
> On Thu, Apr 14, 2022 at 12:37 PM Tadayoshi Sato 
> wrote:
>
>> +1
>>
>> Thanks Andrea!
>>
>> On Wed, Apr 13, 2022 at 6:23 PM Andrea Cosentino 
>> wrote:
>>
>>> Hello,
>>>
>>> We have been working on moving some of the core modules of
>>> camel-k-runtime
>>> to Camel core.
>>>
>>> I'd like to start the release of camel-k-runtime and camel-kamelets
>>> 0.8.0,
>>> so we could update the camel-k main branch to make it works fine with the
>>> runtime.
>>>
>>> I will stage camel-k-runtime 1.13.0 and camel-kamelets 0.8.0 and then we
>>> could use them to align the camel-k release 1.9.0 and test everything,
>>> once
>>> everything it's in place I'll release camel-k too and start the vote.
>>>
>>> Any thoughts?
>>>
>>> Thanks.
>>>
>>
>>
>> --
>> Tadayoshi Sato
>>
>
>
> --
> Tadayoshi Sato
>


-- 
Tadayoshi Sato

Re: Camel K 1.9.0 Release

[Tadayoshi Sato]

I just found one bug in Camel K CLI:
https://github.com/apache/camel-k/issues/3203

It doesn't look cool and IMO is better to be fixed before 1.9.0.

On Thu, Apr 14, 2022 at 12:37 PM Tadayoshi Sato 
wrote:

> +1
>
> Thanks Andrea!
>
> On Wed, Apr 13, 2022 at 6:23 PM Andrea Cosentino 
> wrote:
>
>> Hello,
>>
>> We have been working on moving some of the core modules of camel-k-runtime
>> to Camel core.
>>
>> I'd like to start the release of camel-k-runtime and camel-kamelets 0.8.0,
>> so we could update the camel-k main branch to make it works fine with the
>> runtime.
>>
>> I will stage camel-k-runtime 1.13.0 and camel-kamelets 0.8.0 and then we
>> could use them to align the camel-k release 1.9.0 and test everything,
>> once
>> everything it's in place I'll release camel-k too and start the vote.
>>
>> Any thoughts?
>>
>> Thanks.
>>
>
>
> --
> Tadayoshi Sato
>


-- 
Tadayoshi Sato

Re: Camel K 1.9.0 Release

[Tadayoshi Sato]

+1

Thanks Andrea!

On Wed, Apr 13, 2022 at 6:23 PM Andrea Cosentino  wrote:

> Hello,
>
> We have been working on moving some of the core modules of camel-k-runtime
> to Camel core.
>
> I'd like to start the release of camel-k-runtime and camel-kamelets 0.8.0,
> so we could update the camel-k main branch to make it works fine with the
> runtime.
>
> I will stage camel-k-runtime 1.13.0 and camel-kamelets 0.8.0 and then we
> could use them to align the camel-k release 1.9.0 and test everything, once
> everything it's in place I'll release camel-k too and start the vote.
>
> Any thoughts?
>
> Thanks.
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel K 1.8.0 and related libraries

[Tadayoshi Sato]

+1 (non-binding)

Thank you!

On Thu, Jan 20, 2022 at 2:17 AM Andrea Cosentino  wrote:

> Hello all:
>
> This is a combined vote to release Apache Camel K 1.8.0, Camel K Runtime
> 1.11.0 and Kamelets 0.7.0.
>
> This is a major release based on Camel-Quarkus 2.6.0 and Camel 3.14.0 and
> contains several changes in both the operator and the runtime.
>
> Runtime source files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.11.0/
> Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1401
> Runtime Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-project-1.11.0
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/0.7.0/
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1400
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v0.7.0
>
> Camel K release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.8.0/
> Camel K Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.8.0
>
> 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.8.0 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1400
> --maven-repository=
> <https://repository.apache.org/content/repositories/orgapachecamel-1400--maven-repository=>
> <https://repository.apache.org/content/repositories/orgapachecamel-1400>
>
> https://repository.apache.org/content/repositories/orgapachecamel-1401--olm=false
> <https://repository.apache.org/content/repositories/orgapachecamel-1401>
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel K 1.8.0, Apache Camel K Runtime
> 1.11.0 and Apache Camel Kamelets 0.7.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel K 1.6.1 and related libraries

[Tadayoshi Sato]

+1 (non-binding)

Thanks!

On Mon, Oct 25, 2021 at 9:37 PM Luca Burgazzoli 
wrote:

> +1 (binding)
>
> ---
> Luca Burgazzoli
>
>
> On Mon, Oct 25, 2021 at 2:15 PM Otavio Rodolfo Piske  >
> wrote:
>
> > +1 (non-binding)
> >
> > Thanks Nicola!
> >
> > On Mon, Oct 25, 2021 at 11:24 AM Antonin Stefanutti
> >  wrote:
> >
> > > +1 (non-binding)
> > >
> > > Thanks Nicola!
> > >
> > > > On 23 Oct 2021, at 20:27, Nicola Ferraro 
> wrote:
> > > >
> > > > Hello all:
> > > >
> > > > This is a combined vote to release Apache Camel K 1.6.1 and Camel K
> > > Runtime
> > > > 1.9.1.
> > > >
> > > > This is a minor release upgrading the runtime to Camel-Quarkus
> > > > 2.3.0 and Camel 3.11.2 and contains some fixes in the operator. More
> > > > details in the release notes:
> > > > https://github.com/apache/camel-k/issues/2713#issue-1034225593
> > > >
> > > > Runtime source files:
> > > > https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.9.1/
> > > > Runtime staging repository:
> > > >
> https://repository.apache.org/content/repositories/orgapachecamel-1369
> > > >
> > > > Runtime Tag:
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-project-1.9.1
> > > >
> > > > Camel K release files:
> > > > https://dist.apache.org/repos/dist/dev/camel/camel-k/1.6.1/
> > > > Camel K Tag:
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.6.1
> > > >
> > > > 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.6.1
> --maven-repository
> > > >
> https://repository.apache.org/content/repositories/orgapachecamel-1369
> > > > --olm=false
> > > >
> > > > Please test this release candidate and cast your vote.
> > > >
> > > > [ ] +1 Release the binary as Apache Camel K 1.6.1 and
> > > > Apache Camel K Runtime 1.9.1
> > > > [ ] -1 Veto the release (provide specific comments)
> > > >
> > > > The vote is open for at least 72 hours.
> > > >
> > > > Here's my +1.
> > > >
> > > > Thanks,
> > > > Nicola Ferraro
> > >
> > >
> >
> > --
> > Otavio R. Piske
> > http://orpiske.net
> >
>


-- 
Tadayoshi Sato

Re: Dropping Java 8

[Tadayoshi Sato]

+1

Great that we can soon use Java 11 API like List.of(...) to write simpler
code!

On Mon, Sep 6, 2021 at 4:25 PM Alexandre Gallice 
wrote:

> I think these days developers typically have both JDK 8 and JDK 11
> deployed to production. We must be behind the adoption bump of JDK 11.
> So a 2 year LTS is fine.
>
> +1
>
> On Mon, Sep 6, 2021 at 3:45 AM Zheng Feng  wrote:
>
> > +1
> >
> > On Fri, Sep 3, 2021 at 6:26 PM Andrea Cosentino 
> wrote:
> >
> > > Hello all,
> > >
> > > More and more third party libraries are starting to drop JDK 8 in favor
> > of
> > > JDK 11 (last one I've found is Optaplanner).
> > >
> > > I think we need to define a release where we totally drop Java 8
> Support
> > > and start to build and release with Java 11 only.
> > >
> > > What are your thoughts?
> > >
> >
>


-- 
Tadayoshi Sato

Re: [Website] Better error checking

[Tadayoshi Sato]

N (asciidoctor): skipping reference to missing
> attribute: 4
> > file: docs/modules/ROOT/pages/apis/crds-html.adoc
> > source: https://github.com/apache/camel-k.git (refname: main, start
> path: docs)
> > [22:45:47.780] WARN (asciidoctor): skipping reference to missing
> attribute: 3
> > file: docs/modules/ROOT/pages/apis/crds-html.adoc
> > source: https://github.com/apache/camel-k.git (refname: main, start
> path: docs)
> > [22:45:47.781] WARN (asciidoctor): skipping reference to missing
> attribute: 6
> > file: docs/modules/ROOT/pages/apis/crds-html.adoc
> > source: https://github.com/apache/camel-k.git (refname: main, start
> path: docs)
> > [22:45:48.245] WARN (asciidoctor): skipping reference to missing
> attribute: period
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname: main, start
> path: docs)
> > [22:45:48.245] WARN (asciidoctor): skipping reference to missing
> attribute: lookahead
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname: main, start
> path: docs)
> > [22:45:48.245] WARN (asciidoctor): skipping reference to missing
> attribute: period
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname: main, start
> path: docs)
> > [22:45:48.246] WARN (asciidoctor): skipping reference to missing
> attribute: lookahead
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname: main, start
> path: docs)
> > [22:45:48.248] WARN (asciidoctor): skipping reference to missing
> attribute: period
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname: main, start
> path: docs)
> > [22:45:49.586] WARN (asciidoctor): unterminated listing block
> > file: docs/modules/ROOT/pages/contributing/developers.adoc:230
> > source: https://github.com/apache/camel-k.git (refname:
> release-1.4.x, start path: docs)
> > [22:45:49.825] WARN (asciidoctor): skipping reference to missing
> attribute: period
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname:
> release-1.4.x, start path: docs)
> > [22:45:49.825] WARN (asciidoctor): skipping reference to missing
> attribute: lookahead
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname:
> release-1.4.x, start path: docs)
> > [22:45:49.826] WARN (asciidoctor): skipping reference to missing
> attribute: period
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname:
> release-1.4.x, start path: docs)
> > [22:45:49.826] WARN (asciidoctor): skipping reference to missing
> attribute: lookahead
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname:
> release-1.4.x, start path: docs)
> > [22:45:49.828] WARN (asciidoctor): skipping reference to missing
> attribute: period
> > file: docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
> > source: https://github.com/apache/camel-k.git (refname:
> release-1.4.x, start path: docs)
> > [22:45:54.820] WARN (asciidoctor): skipping reference to missing
> attribute: body
> > file: docs/modules/ROOT/pages/reference/extensions/core.adoc
> > source: https://github.com/apache/camel-quarkus.git (refname: main,
> start path: docs)
> > [22:45:59.069] WARN (asciidoctor): skipping reference to missing
> attribute: body
> > file: docs/modules/ROOT/pages/reference/extensions/core.adoc
> > source: https://github.com/apache/camel-quarkus.git (refname:
> release/2.0.0, start path: docs)
> >
> >
> > Currently this sort of warning is output to the console but cannot be
> used to fail the build.
> >
> > David Jencks
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Tadayoshi Sato

Re: [discuss] find a better name for KameletBinding

[Tadayoshi Sato]

"Binding" sounds good to me, too.

On Fri, Aug 20, 2021 at 7:07 PM Claus Ibsen  wrote:

> Hi
>
> Yeah one of the hardest problem is naming, and after that renaming as
> a lot of old stuff "expects" the old name.
>
> I am also leading to Binding, as we have other concepts in Camel K
> that are neutral named (no Camel or product in the name) like
> Integration, IntegrationKit.
> And they are all in the same namespace, so there are no clash on
> kubernetes.
>
> +1 for Binding
>
>
>
> On Fri, Aug 20, 2021 at 10:59 AM John Poth  wrote:
> >
> > +1 for Binding
> >
> > Dropping the Kamelet part makes it clearer that you can bind more
> > than just Kamelets.
> >
> > Keeping it as "Binding" gives Kubernetes users a pretty good idea of what
> > it's going to do without reading the documentation.
> >
> > On Mon, Aug 16, 2021 at 2:04 PM Antonin Stefanutti
> >  wrote:
> >
> > > Hi Luca, all,
> > >
> > > +1 for Binding.
> > >
> > > Users in the Kubernetes ecosystem may already be familiar with the
> term,
> > > as it seems it's the choice made by projects like Knative and Service
> > > Binding,
> > > to convey the general concept of "integrating" in their respective
> domain.
> > >
> > > I find projecting that concept into the integration domain to be a good
> > > fit, which
> > > Would materialises in Kubernetes as bindings.camel.apache.org<
> > > http://bindings.camel.apache.org> resources.
> > >
> > > On 16 Aug 2021, at 10:27, Luca Burgazzoli   > > lburgazz...@gmail.com>> wrote:
> > >
> > > Hello,
> > >
> > > When the KameletBinding concept was introduced in camel-k, if was
> meant to
> > > bind two Kamelets and nothing more, but over time we have added more
> > > capabilities, like:
> > >
> > > - support for processing steps to transform exchanges/messages
> > > - support to address/source from different systems so the source/sink
> does
> > > not need be a kamelet anymore
> > >
> > > So I think the term KameletBinding is not more appropriate and to
> reduce
> > > confusion, we should try to find a better name.
> > >
> > > On top of my mind, I'd see the following names as a possible
> replacement:
> > > - Binding so leave Kamelet out of the game as Kamelets are one of the
> > > option but not the exclusive on
> > > - Connector as in essence, a KameletBinding describe how to connect A
> to B
> > >
> > > Any opinion ?
> > >
> > > ---
> > > Luca Burgazzoli
> > >
> > >
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Tadayoshi Sato

Re: Camel code generator for the Camel web site

[Tadayoshi Sato]

+1 for linking from camel-website to kameleon.dev. It's awesome generator!

Why not just starting from linking it from the front page as well as in the
Getting Started with some more details on the status of the site (like not
official but community contributions yet at this moment)?
https://camel.apache.org/manual/latest/getting-started.html

On Tue, Jul 6, 2021 at 12:10 PM Marat Gubaidullin <
marat.gubaidul...@gmail.com> wrote:

> Hello,
>
> It would be great if we could start with a link on a camel web site. Just
> in case, it is *kameleon*.dev ;-)
>
> Marat
>
> On Wed, Jun 30, 2021 at 4:25 AM Claus Ibsen  wrote:
>
> > Hi
> >
> >
> > On Tue, Jun 29, 2021 at 4:31 PM Otavio Rodolfo Piske
> >  wrote:
> > >
> > > Hi,
> > >
> > > +1 for linking it from the Camel website.
> > >
> > > I think that's a good starting point. I don't know if it's feasible or
> > not,
> > > so I am just speculating ... but IMHO, it would be good if we could see
> > how
> > > the larger community receives it. If it's well received, then maybe we
> > > could work w/ Marat and INFRA to bring it onboard.
> > >
> >
> > Yeah this is good suggestions.
> >
> > Also it may be worth for Marat to write a blog post to introduce
> > Kamelon, and have it posted on the Camel front page.
> >
> > > Kind regards
> > >
> > > On Tue, Jun 29, 2021 at 10:46 AM Zoran Regvart 
> > wrote:
> > >
> > > > Hi Cameleers,
> > > > what do other folk think? We could link to kamelon.dev from the
> > > > frontpage of the website quite easily.
> > > >
> > > > zoran
> > > >
> > > > On Wed, Jun 23, 2021 at 9:19 AM Zoran Regvart 
> > wrote:
> > > > >
> > > > > Hi Marat,
> > > > > we can certainly link to it, it might be problematic hosting the
> > > > > server bits, the websites are served as static content. To host
> this
> > > > > at ASF we would need somewhere to run it and that would involve
> > > > > talking to INFRA[1].
> > > > >
> > > > > I would try to stay away from embedding something that reaches out
> to
> > > > > a 3rd party service without having a SLA/agreement of sorts in
> place.
> > > > > Sole example of that used on the website is the Algolia search.
> > > > >
> > > > > zoran
> > > > >
> > > > > [1] https://infra.apache.org/services.html#virtual-servers
> > > > >
> > > > > On Tue, Jun 22, 2021 at 2:49 PM Marat Gubaidullin
> > > > >  wrote:
> > > > > >
> > > > > > Hello Camel Developers,
> > > > > >
> > > > > > I would like to propose to add a code generator to the Camel web
> > site
> > > > > > to simplify (archetypes, versions, components, etc) the project
> > > > creation
> > > > > > process for developers.
> > > > > >
> > > > > > I have developed a prototype https://kameleon.dev
> > > > > > It could be used as a starting point.
> > > > > >
> > > > > > Thank you and have a nice day
> > > > > > Marat Gubaidullin
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Zoran Regvart
> > > >
> > > >
> > > >
> > > > --
> > > > Zoran Regvart
> > > >
> > >
> > >
> > > --
> > > Otavio R. Piske
> > > http://orpiske.net
> >
> >
> >
> > --
> > Claus Ibsen
> > -
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>


-- 
Tadayoshi Sato

Re: [headsup] Setting GitHub username/token to build the website is required

[Tadayoshi Sato]

That's awesome. Thanks Zoran!

On Wed, Jun 30, 2021 at 4:30 PM Zoran Regvart  wrote:

> Hi Cameleers,
> I'm making a change in what's required to build the website, you now
> need to set `HUGO_PARAMS_GitHubUsername` and
> `HUGO_PARAMS_GitHubToken`[1] environment variables in order to build
> the website.
>
> That change upgrades Hugo to 0.84 which includes the ability to set
> HTTP headers when fetching remote data. The change makes it mandatory
> to set those headers as otherwise the default request limit with
> unauthenticated access to GitHub API will not be enough to build the
> website successfully.
>
> So if you're building/previewing the website locally please make sure
> those environment variables are set.
>
> zoran
>
> [1]
> https://github.com/apache/camel-website/blob/pr/upgrade-hugo-remove-proxy/README.md#build-the-website-and-antora-theme
> --
> Zoran Regvart
>


-- 
Tadayoshi Sato

Re: GitHub API limits hit when building camel-website locally

[Tadayoshi Sato]

Thanks Karen for your info!  It's very helpful.

And today I noticed that Zoran already updated README with a workaround
solution to the issue:
https://github.com/apache/camel-website#checks-publishing-the-website
So far the workaround seems to work fine for me.

On Mon, May 17, 2021 at 10:20 PM Karen Lease 
wrote:

> Hi Tadayoshi,
>
> I had this same issue very recently land Zoran Regvart gave me this
> information:
>
> > Yes, this is a known limitation, GitHub removed support for providing
> > authentication tokens via URL parameters and the HTTP calls from Hugo
> > can't include HTTP headers (https://github.com/gohugoio/hugo/issues/5617).
> We get around that with caches, i.e.
> > for Hugo `HUGO_CACHEDIR` can be set to a filesystem path that stores
> > the caches. On ASF Jenkins we keep the cache, and for the checks
> > running on GitHub I think we get higher API limits (or so it seems).
> >
> > And yes, it's definitely worth mentioning that in the README, I was
> > hoping that custom headers in HTTP calls would land soon in Hugo so I
> > didn't invest time in an alternative to getJSON. I think a pragmatic
> > course of action would be to wait for this to get supported in Hugo
> > until we see issues in publishing the website.
>
> I found that if I ran the build again after a short time (about 15
> minutes) it passed because the API limit was reset, and then it was
> cached, at least until I ran clean.
> So far, I didn't add this information to the documentation about
> building the website, so I'll put that on my "to do" list.
>
> -Karen Lease
>
> On 17/05/2021 12:11, Tadayoshi Sato wrote:
> > Hi folks,
> >
> > When trying to build camel-website locally, quite oftentimes I hit GitHub
> > API limits for unauthenticated requests and get the errors like this:
> >
> > $ yarn build:hugo
> > Building sites … ERROR 2021/05/17 19:04:33 Failed to get JSON resource "
> >
> https://api.github.com/repos/apache/camel-k-runtime/issues?state=closed=10
> ":
> > Failed to retrieve remote file: Forbidden
> > ERROR 2021/05/17 19:04:33 Failed to get JSON resource "
> >
> https://api.github.com/repos/apache/camel-k/issues?state=closed=18
> ":
> > Failed to retrieve remote file: Forbidden
> > ERROR 2021/05/17 19:04:33 Failed to get JSON resource "
> >
> https://api.github.com/repos/apache/camel-k/issues?state=closed=11
> ":
> > Failed to retrieve remote file: Forbidden
> > ...
> >
> >
> > Is there any good way to eschew this issue when developing locally?
> >
> > Thank you,
> >
>


-- 
Tadayoshi Sato

GitHub API limits hit when building camel-website locally

[Tadayoshi Sato]

Hi folks,

When trying to build camel-website locally, quite oftentimes I hit GitHub
API limits for unauthenticated requests and get the errors like this:

$ yarn build:hugo
Building sites … ERROR 2021/05/17 19:04:33 Failed to get JSON resource "
https://api.github.com/repos/apache/camel-k-runtime/issues?state=closed=10":
Failed to retrieve remote file: Forbidden
ERROR 2021/05/17 19:04:33 Failed to get JSON resource "
https://api.github.com/repos/apache/camel-k/issues?state=closed=18":
Failed to retrieve remote file: Forbidden
ERROR 2021/05/17 19:04:33 Failed to get JSON resource "
https://api.github.com/repos/apache/camel-k/issues?state=closed=11":
Failed to retrieve remote file: Forbidden
...


Is there any good way to eschew this issue when developing locally?

Thank you,
-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel-kafka-connector 0.9.0

[Tadayoshi Sato]

+1 (non-binding)

Thanks!

On Wed, Mar 31, 2021 at 6:04 PM Andrea  wrote:

> Hello all,
>
> This is a vote to release Apache Camel-kafka-connector 0.9.0
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1307
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kafka-connector.git;a=tag;h=refs/tags/camel-kafka-connector-0.9.0
>
> Aligned to camel 3.9.0
>
> Please test this release candidate and cast your vote.
> [ ] +1 Release the binary as  Apache Camel-kafka-connector 0.9.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 48 hours.
>
> Thanks,
> Andrea.
>


-- 
Tadayoshi Sato

Re: Camel 3 - More middle folders in components

[Tadayoshi Sato]

Great idea.

+1

On Wed, Mar 10, 2021 at 8:17 PM Andrea Cosentino  wrote:

> Yeah, it makes sense.
>
> +1.
>
> We need to create some issues to track these down.
>
> Il giorno mer 10 mar 2021 alle ore 12:15 Claus Ibsen <
> claus.ib...@gmail.com>
> ha scritto:
>
> > Hi
> >
> > To make maintaining Camel components easier, and to avoid the
> > components root folder gets too big, then recently we have moved cloud
> > components into aws, google etc.
> >
> > I think we could do the same for more components like
> > - debezium
> > - microprofile (all microprpofile modules)
> > - spring (all spring modules)
> > - test (unit test and testcontainers)
> >
> >
> >
> > --
> > Claus Ibsen
> > -
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>


-- 
Tadayoshi Sato

Re: [HEADS UP] - Optional property placeholders in Camel 3.9

[Tadayoshi Sato]

Ah there is already the "?speedUp" notation to describe it as optional in
camel-main. Then I'm fine with {{?speedUp}} syntax to maintain consistency
within Camel.
https://camel.apache.org/components/latest/others/main.html#_optional_parameters_on_beans

On Mon, Mar 8, 2021 at 2:25 PM Tadayoshi Sato 
wrote:

> Hi Zoran,
>
> Just in case, Properties component already provide the feature of
> specifying a default value with {{speedUp:other}} syntax:
> https://camel.apache.org/components/3.7.x/properties-component.html#_syntax
>
> So what Claus proposes here is a feature that optionally can assign some
> value but otherwise leaves it unassigned at all.
> I see Claus' point that the syntax {{optional:speedUp}} is really
> confusing as the properties component would then see it as the placeholder
> "optional" with default value "speedUp".
>
> Personally, I second Babak's syntax of {{speedUp?}} as it aligns with JS
> syntax and REST producer optional parameters Zoran introduced.
>
> Best regards,
> Tadayoshi
>
> On Sat, Mar 6, 2021 at 4:41 AM Zoran Regvart  wrote:
>
>> Hi Claus,
>> I like the bash shell parameter expansion[1], this allows for
>> specifying the default value if parameter doesn't expand. Something
>> like {{speedUp:-}} would be optional without a default value, whereas
>> {{speedUp:-other}} would provide `other` as a default value.
>>
>> For the REST producer bits I introduced optional parameters with a
>> trailing question mark, see[2]. Doing something consistent here would
>> be good I think.
>>
>> zoran
>>
>> [1]
>> https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html#Shell-Parameter-Expansion
>> [2]
>> https://github.com/apache/camel/blob/b040a056ddf1b8f0756516cd47c00f180f128c05/core/camel-core/src/test/java/org/apache/camel/component/rest/RestProducerTest.java#L84
>>
>> On Fri, Mar 5, 2021 at 3:04 PM Claus Ibsen  wrote:
>> >
>> > Hi
>> >
>> > In Camel 3.9 we are introducing optional property placeholders.
>> > https://issues.apache.org/jira/browse/CAMEL-16302
>> >
>> > The use-case is to allow configuring Camel endpoints (primarily) where
>> > you can specify some options that may be configured or not (optional).
>> >
>> > Currently all property placeholders are mandatory, unless a default
>> > value is provided. So with the default value, you could do "optional"
>> > but then you would need to know what the default value would be (if
>> > there is any).
>> >
>> > Optional placeholders is also a feature that we want to have with
>> > route templates (aka Kamelets). So you can create kamelets with a
>> > number of options (some are required, and others would be optional).
>> > And others have default values etc.
>> >
>> > The syntax for marking a property placeholder as option is to prefix
>> > the key name with ?, eg
>> >
>> >  from("jms:cheese?concurrentConsumers={{?speedUp}}")
>> >
>> > Here the concurrent consumers option is optional, as the placeholder
>> > value starts with a ? in the key name.
>> >
>> > Then the Camel end user can configure the property placeholder, such
>> > as in application.properties
>> >
>> > speedUp=5
>> >
>> > Or if there are no configuration, then the option is not present and
>> > the endpoint is resolved as:
>> >
>> >  from("jms:cheese")
>> >
>> >
>> > The syntax with the ? mark was choose to keep it short. But we are
>> > open for feedback.
>> > Another alternative was to prefix with optional:
>> >
>> > {{optional:speedUp}}
>> >
>> > However the properties component in Camel then assume the key is named
>> > optional, and the default value is speedUp. So it clashes with this.
>> > But we could make "optional" a reserved word and do special handling
>> > for this.
>> >
>> > The only concern about using ? is that an endpoint uri already have ?
>> > for query parameters. And if using more ? would be confusing?
>> >
>> >
>> from("jms:cheese?concurrentConsumers={{?speedUp}}={{someName}}")
>> >
>> > Any thoughts?
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -
>> > http://davsclaus.com @davsclaus
>> > Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> Zoran Regvart
>>
>
>
> --
> Tadayoshi Sato
>


-- 
Tadayoshi Sato

Re: [HEADS UP] - Optional property placeholders in Camel 3.9

[Tadayoshi Sato]

Hi Zoran,

Just in case, Properties component already provide the feature of
specifying a default value with {{speedUp:other}} syntax:
https://camel.apache.org/components/3.7.x/properties-component.html#_syntax

So what Claus proposes here is a feature that optionally can assign some
value but otherwise leaves it unassigned at all.
I see Claus' point that the syntax {{optional:speedUp}} is really confusing
as the properties component would then see it as the placeholder "optional"
with default value "speedUp".

Personally, I second Babak's syntax of {{speedUp?}} as it aligns with JS
syntax and REST producer optional parameters Zoran introduced.

Best regards,
Tadayoshi

On Sat, Mar 6, 2021 at 4:41 AM Zoran Regvart  wrote:

> Hi Claus,
> I like the bash shell parameter expansion[1], this allows for
> specifying the default value if parameter doesn't expand. Something
> like {{speedUp:-}} would be optional without a default value, whereas
> {{speedUp:-other}} would provide `other` as a default value.
>
> For the REST producer bits I introduced optional parameters with a
> trailing question mark, see[2]. Doing something consistent here would
> be good I think.
>
> zoran
>
> [1]
> https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html#Shell-Parameter-Expansion
> [2]
> https://github.com/apache/camel/blob/b040a056ddf1b8f0756516cd47c00f180f128c05/core/camel-core/src/test/java/org/apache/camel/component/rest/RestProducerTest.java#L84
>
> On Fri, Mar 5, 2021 at 3:04 PM Claus Ibsen  wrote:
> >
> > Hi
> >
> > In Camel 3.9 we are introducing optional property placeholders.
> > https://issues.apache.org/jira/browse/CAMEL-16302
> >
> > The use-case is to allow configuring Camel endpoints (primarily) where
> > you can specify some options that may be configured or not (optional).
> >
> > Currently all property placeholders are mandatory, unless a default
> > value is provided. So with the default value, you could do "optional"
> > but then you would need to know what the default value would be (if
> > there is any).
> >
> > Optional placeholders is also a feature that we want to have with
> > route templates (aka Kamelets). So you can create kamelets with a
> > number of options (some are required, and others would be optional).
> > And others have default values etc.
> >
> > The syntax for marking a property placeholder as option is to prefix
> > the key name with ?, eg
> >
> >  from("jms:cheese?concurrentConsumers={{?speedUp}}")
> >
> > Here the concurrent consumers option is optional, as the placeholder
> > value starts with a ? in the key name.
> >
> > Then the Camel end user can configure the property placeholder, such
> > as in application.properties
> >
> > speedUp=5
> >
> > Or if there are no configuration, then the option is not present and
> > the endpoint is resolved as:
> >
> >  from("jms:cheese")
> >
> >
> > The syntax with the ? mark was choose to keep it short. But we are
> > open for feedback.
> > Another alternative was to prefix with optional:
> >
> > {{optional:speedUp}}
> >
> > However the properties component in Camel then assume the key is named
> > optional, and the default value is speedUp. So it clashes with this.
> > But we could make "optional" a reserved word and do special handling
> > for this.
> >
> > The only concern about using ? is that an endpoint uri already have ?
> > for query parameters. And if using more ? would be confusing?
> >
> >
> from("jms:cheese?concurrentConsumers={{?speedUp}}={{someName}}")
> >
> > Any thoughts?
> >
> >
> > --
> > Claus Ibsen
> > -
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Zoran Regvart
>


-- 
Tadayoshi Sato

Re: Are you using binary distribution?

[Tadayoshi Sato]

Hi folks,

I don't use binary distributions, either. It makes sense for runtime
projects such as Apache Karaf, Kafka, Artemis, etc. to provide binary
distributions, but it doesn't for library frameworks like Camel Core, Camel
Quarkus, and CKC.

For Camel-K, however, it has a CLI `kamel` so IMO it still makes sense to
keep binary distributions for it.

Thanks,
Tadayoshi

On Mon, Dec 14, 2020 at 10:58 PM Ajmera, Hemang C 
wrote:

> I am relying on maven for binaries and git for sourcecode. IMHO binary
> distribution may not be needed.
> Github has release feature, where we can have binaries can be downloaded
> from there. Many users might be used to that way of downloading binary, so
> if needed, that can be alternate place for download if anyone needs it.
> However CI/CD pipeline might need updates for github release to work.
>
>
> Thanks and Regards,
> Hemang Ajmera
>
>
> -Original Message-
> From: Zoran Regvart 
> Sent: 14 December 2020 19:08
> To: Dev ; us...@camel.apache.org
> Subject: Are you using binary distribution?
>
>
> EXTERNAL SENDER:   Do not click any links or open any attachments unless
> you trust the sender and know the content is safe.
> EXPÉDITEUR EXTERNE:Ne cliquez sur aucun lien et n’ouvrez aucune pièce
> jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous
> ayez l'assurance que le contenu provient d'une source sûre.
>
> Hi Cameleers,
> we're discussing binary distribution on two issues[1][2]. The binary
> distribution is the tar.gz/ZIP file linked from the Camel website. By ASF
> policy we only ship source code, and the binary distribution is optional.
>
> Back in the dark days, before using build tools that knew about dependency
> management (Maven, Gradle...) folk used to use the binary distribution.
>
> I've found some statistics on downloads/per day, for us[3]/eu[4] and
> created these charts:
>
>
> https://urldefense.com/v3/__https://s.apache.org/camel-dl-us__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDiSwKzT18$
>
> https://urldefense.com/v3/__https://s.apache.org/camel-dl-eu__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDic4MBCm6$
>
> The data is over 2 and 1/4 years, we've had 19.7+-8.8 via US, and
> 20.24+-8.43 in via EU per day. So not that much IMHO.
>
> I'm wondering if anyone is still relying on these, and if so what would a
> binary distribution look like for sub projects? Should we do the same as we
> do for the Camel core?
>
> Please reply on this thread or chime in on those issues for sub-project
> specific concerns.
>
> Thanks :)
>
> zoran
>
> [1]
> https://urldefense.com/v3/__https://github.com/apache/camel-quarkus/issues/2045__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDiZ80_jXD$
> [2]
> https://urldefense.com/v3/__https://github.com/apache/camel-kafka-connector/issues/754__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDiVlO1Pqs$
> [3]
> https://urldefense.com/v3/__https://www-us.apache.org/dyn/stats/camel.log__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDiStt2eyy$
> [4]
> https://urldefense.com/v3/__https://www-eu.apache.org/dyn/stats/camel.log__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDicRsFgPE$
> --
> Zoran Regvart
>


-- 
Tadayoshi Sato

Re: [ANNOUNCEMENT] Apache Camel K 1.0.0 released

[Tadayoshi Sato]

Great achievement!  Congratulations, all!

On Wed, Jun 10, 2020 at 10:50 AM Michael Joyner 
wrote:

> Nicola,
>
> Congratulations
>
> On Tue, Jun 9, 2020 at 8:10 AM Kurt Stam  wrote:
>
> > Very exciting to see this! Congratulations! —Kurt
> >
> > > On Jun 9, 2020, at 16:13, Nicola Ferraro  wrote:
> > >
> > > The Camel community announces the immediate availability of Apache
> > > Camel K 1.0.0 and
> > > related Camel K Runtime 1.3.0. This is the first GA release of Camel K,
> > > with several improvements and bug fixes that you can find in the
> release
> > > notes[1].
> > >
> > > The artifacts are published and ready for you to download either
> > > from the Apache mirrors or from the Github repository.
> > >
> > > Many thanks to all who made this release possible.
> > >
> > > On behalf of the Camel PMC,
> > > Nicola Ferraro
> > >
> > > [1] https://github.com/apache/camel-k/releases/tag/1.0.0
> >
>
>
> --
> --
> Michael Joyner
> Solutions Architect
> SugarCRM
>
> mobile: (206)-288-3937
> email: michaelwjoy...@gmail.com
> <https://facebook.com/michaelwjoyner>..
>


-- 
Tadayoshi Sato

Re: Merge Commits?

[Tadayoshi Sato]

+1 for avoiding merge commits in favour of linear history. While
undocumented, I learned it on the job by reading the commit history which
is mostly linear except developing big feature branches like the major
upgrade. Of course, it would be better if the policy is documented clearly
somewhere.

A couple points that support linear commit history:
* Camel accepts many community contributions via GitHub pull reqs. Not
rebasing them would add non-necessary merge-point commits in the history
and make it lengthier.
* We have many regular committers who work in parallel. Allowing merges
would make the history messy and hard to trace changes for troubleshooting
and learning from history.

On Thu, Apr 16, 2020 at 7:19 AM David Jencks 
wrote:

> I’m in favor of changing the GitHub camel repositories to enforce
> rebase-and-merge:  Rebasing and merging your commits <
> https://help.github.com/en/github/administering-a-repository/about-merge-methods-on-github#rebasing-and-merging-your-commits>.
> This will produce linear history.  IIUC, the committer on each commit will
> change to the person doing the rebase-and-merge, and the author will remain
> unchanged.
>
> Is it possible to do something equivalent on the Apache git repo?
>
> AFAICT without this, GitHub merges will definitely have a merge commit and
> may have non-linear history.
>
> Thanks
> David Jencks
>
> > On Apr 15, 2020, at 2:08 PM, Andrea Cosentino  wrote:
> >
> > I don't think there is a consensus around this.. we can collect here the
> > different views. Personally I don't think merge commits are evil, but if
> a
> > clean history is desired it's fine for me
> >
> >
> > Il mer 15 apr 2020, 22:09 Pascal Schumacher 
> ha
> > scritto:
> >
> >> Hi,
> >>
> >> recently there were several merge commits (especially for merged pull
> >> request).
> >>
> >> I thought the consensus was to avoid merge commits to keep the git
> >> history as clean as possible.
> >>
> >> Should we keep this policy?
> >>
> >> What do you think?
> >>
> >> Cheers,
> >>
> >> Pascal
> >>
> >>
> >>
>
>

-- 
Tadayoshi Sato

Re: [DISCUSS] - LTS and non-LTS releases coming to Apache Camel 3.x

[Tadayoshi Sato]

Hello,

Node.js is also famous for LTS-based releasing, so it might give some
inspiration for us:
https://nodejs.org/en/download/

The download page is separated with the two tabs: LTS and Current (latest
features), highlighting LTS so users can know which should be used for most
cases.

My two cents.

On Mon, Mar 2, 2020 at 6:43 PM Claus Ibsen  wrote:

> Hi
>
> Okay so I have looked a bit around what other ASF projects do and I
> got a bit inspired by Karaf
> http://karaf.apache.org/download.html
>
> So in the top we can have links to the latest downloads (a bit like
> today) but since we start to have releases that are LTS and not-LTS
> then we need to show that information. And since this page is
> automatic then its harder as how would it know if its a TLS release or
> not?
>
> But the Karaf schedule table is nice and that can help users to see
> Java version and next version etc.
>
>
> On Sat, Feb 29, 2020 at 2:19 PM Claus Ibsen  wrote:
> >
> > Hi
> >
> > Okay so lets get some write-up about this as a blog post on the Camel
> website.
> >
> > And change the download page to cover this and we can have a TLS [x]
> > for which release that gets patch releases.
> > https://camel.apache.org/download/
> >
> > On Fri, Feb 28, 2020 at 7:39 AM Claus Ibsen 
> wrote:
> > >
> > > Hi
> > >
> > > We have released Camel 3.0 and 3.1 yesterday. As Camel v3 is a major
> > > new foundation with all the effort that went into it, then we want to
> > > take the new few releases to continue as there are things we need to
> > > work on.
> > >
> > > Therefore we want to have a more aggressive release schedule and
> > > release more frequent releases but they are not LTS releases (long
> > > term support). Therefore these releases likely only have 1 patch
> > > releases, eg 3.0.1, or none at all.
> > >
> > > When we hit Camel 3.3 then its expected to be a LTS release and have
> > > patch releases for a longer period of time.
> > >
> > > And in fact this model is maybe something we want to continue
> > > thereafter and be able to mark releases as LTS and non LTS. Eg just
> > > like the JDK etc.
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> >
> >
> >
> > --
> > Claus Ibsen
> > -
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Tadayoshi Sato

Re: Closing Down on Apache Camel 3.1

[Tadayoshi Sato]

On Mon, Jan 27, 2020 at 7:29 PM Andrea Cosentino  wrote:

> By the way, I believe it is a good chance, to move the examples out of the
> main repository.
>

+1


>
> Il giorno lun 27 gen 2020 alle ore 11:28 Omar Al-Safi 
> ha
> scritto:
>
> > +1
> >
> > I am working actively on the (3) the component DSL, hopefully would be
> done
> > this week or next week, so I guess should be on track for 3.1.
> > Also I hope I can push some bug fixes for camel-debezium once done from
> the
> > fluent builder
> >
> > Regards,
> > Omar
> >
> > On Mon, Jan 27, 2020 at 11:22 AM Andrea Cosentino 
> > wrote:
> >
> > > +1,
> > >
> > > I'm working on AWS SDK2 components.
> > >
> > > Il giorno lun 27 gen 2020 alle ore 11:19 Claus Ibsen <
> > > claus.ib...@gmail.com>
> > > ha scritto:
> > >
> > > > Hi
> > > >
> > > > I just wanted to start the process of getting closer to Camel 3.1
> > > release.
> > > > Despite 3.0 was released only a while back, then we have made great
> > > > progress on 3.1 that is important to get in the hands of the Camel
> > > > users. And for Camel users that migrate to 3.x can then skip 3.0 and
> > > > go straight to 3.1.
> > > >
> > > > I am working on some further optimizations in the core for 3.1, and I
> > > > hope to find time to share more details in a blog.
> > > >
> > > > However to get the other work (high level) done and ready for 3.1,
> > > > then lets discuss them here on the @dev mailing list.
> > > >
> > > > On top of my head we have to do
> > > >
> > > > 1)
> > > > Finish the separation of camel-spring-boot (there are some tools that
> > > > update docs and generate component list) that needs to be completed.
> > > >
> > > > 2)
> > > > Generate source code configurer for data formats and languages
> > > >
> > > > 3)
> > > > The component configuration fluent builder (would be nice)
> > > >
> > > > 4)
> > > > More camel AWS SDK2 components
> > > >
> > > > 5)
> > > > Camel Main to plugin the new lightweight XML route parser/loader (for
> > > > example auto discover on classpath the JAR and use it instead of
> JAXB)
> > > >
> > > > There are other things of course, but these are the bigger high level
> > > > things I could remember.
> > > >
> > > > The usual work with new components, examples, other improvements is
> of
> > > > course also ongoing.
> > > >
> > > > Lets see if we can get this done and release Camel 3.1 in February.
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Claus Ibsen
> > > > -
> > > > http://davsclaus.com @davsclaus
> > > > Camel in Action 2: https://www.manning.com/ibsen2
> > > >
> > >
> >
>


-- 
Tadayoshi Sato

Re: [DISCUSS] - camel-examples git repository

[Tadayoshi Sato]

+1

It's especially cool that we can gather all camel, camel-k, camel-quarkus,
and camel-kafka-connector examples in one place.

On Thu, Dec 19, 2019 at 5: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
>


-- 
Tadayoshi Sato

Re: Sending camel-kafka-connector and camel-website github notification mails to camel-commits instead of camel-dev?

[Tadayoshi Sato]

Thanks!  Andrea++

On Tue, Dec 10, 2019 at 6:20 PM Zoran Regvart  wrote:

> Thanks Andrea!
>
> On Mon, Dec 9, 2019 at 8:08 PM Andrea Cosentino  wrote:
> >
> > I already created an infra issue for camel-kafka-connector. I'll do the
> > same for the camel-website.
> >
> > Il lun 9 dic 2019, 20:04 Pascal Schumacher  ha
> > scritto:
> >
> > > Hello,
> > >
> > > what about sending the camel-kafka-connector and camel-website github
> > > notification mails to the camel-commits mailing list instead of to the
> > > camel-dev mailing list?
> > >
> > > This would make the behavior consistent for camel, camel-k,
> > > camel-website and camel-kafka-connector.
> > >
> > > What do you think?
> > >
> > > Cheers,
> > >
> > > Pascal
> > >
> > >
> > > Am 09.12.2019 um 16:38 schrieb GitBox:
> > > > valdar edited a comment on issue #31: run integration test insided
> gihub
> > > actions
> > > > URL:
> > >
> https://github.com/apache/camel-kafka-connector/issues/31#issuecomment-563296282
> > > >
> > > >
> > > > See if it is possible to have integrations tests running as
> github
> > > actions, not as heach PR but once in a while (nightly? weekly?).
> > > >
> > > > 
> > > > This is an automated message from the Apache Git Service.
> > > > To respond to the message, please log on to GitHub and use the
> > > > URL above to go to the specific comment.
> > > >
> > > > For queries about this service, please contact Infrastructure at:
> > > > us...@infra.apache.org
> > > >
> > > >
> > > > With regards,
> > > > Apache Git Services
> > >
> > >
> > >
>
>
>
> --
> Zoran Regvart
>


-- 
Tadayoshi Sato

Re: [ANNOUNCEMENT] Apache Camel 3.0.0 Released

[Tadayoshi Sato]

Congratulations!  It's an epic release indeed!

Thanks everyone for making it happen!

Best regards,
Tadayoshi

On Thu, Nov 28, 2019 at 11:13 PM Gregor Zurowski 
wrote:

> It's finally here - after four release candidates and three milestone
> releases, the Camel community announces the immediate availability of
> Camel 3.0.0, a new major release with over 1000 new features,
> improvements and fixes.
>
> Please read our migration guide [1] that describes how to upgrade
> Camel 2.x applications to Camel 3.0.
>
> The artifacts are published and ready for you to download [2] either
> from the Apache mirrors or from the Central Maven repository. For more
> details please take a look at the release notes [3, 4].
>
> Many thanks to all who made this release possible.
>
> On behalf of the Camel PMC,
> Gregor Zurowski
>
> [1] https://camel.apache.org/manual/latest/camel-3-migration-guide.html
> [1] http://camel.apache.org/download.html
> [2] https://camel.apache.org/blog/release-3-0-0.html
> [3]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
>


-- 
Tadayoshi Sato

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

[Tadayoshi Sato]

Thank you Andrea!

On Mon, Oct 7, 2019 at 4:15 PM Andrea Cosentino  wrote:

> https://issues.apache.org/jira/browse/INFRA-19233
>
> Il giorno lun 7 ott 2019 alle ore 08:52 Willem Jiang <
> willem.ji...@gmail.com>
> ha scritto:
>
> > 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,
> >
>


-- 
Tadayoshi Sato

Notifications from camel-k & camel-quarkus github repos

[Tadayoshi Sato]

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: Where to add Spring Boot integration tests?

[Tadayoshi Sato]

Thanks Andrea for your comments.

On Thu, Sep 12, 2019 at 7:26 PM Andrea Cosentino  wrote:

> I don't think it's a good idea to create something with issues in the
> folder name.
>

Yes, it was just a bad example for further better ideas ;-)


>
> If this is an integration tests specific to camel-servlet, you can create
> an integration test in the component starter folder.
>

Ideally this isn't specific to any single starter; it is rather based on a
real use case, which may grow into cross-component integration tests. But
practically this time it seems to only need camel-log & camel-rest other
than camel-servlet, so it appears that I can put it in
camel-servlet-starter.

If things grow otherwise and I cannot put it in a single starter project
I'll consider other options.

Thank you!


>
> Il giorno gio 12 set 2019 alle ore 12:21 Tadayoshi Sato <
> sato.tadayo...@gmail.com> ha scritto:
>
> > Hi folks,
> >
> > I'd like to add an integration test for camel-servlet that can run only
> on
> > Spring Boot. Initially I thought to add it to
> > tests/camel-itest-spring-boot, but this is rather for systematic
> > compatibility checks for camel components with Spring Boot, not where a
> > real cross-component regression test is placed.
> >
> > Where should I put such Spring Boot integration tests in Camel project?
> Is
> > it good idea to create another sub-project under tests/?  If so what do
> you
> > think is the best name for the project?  I cannot think of a good name
> for
> > such a project..., e.g. tests/camel-itest-spring-boot-issues?
> >
> > Best regards,
> > Tadayoshi
> >
>

Where to add Spring Boot integration tests?

[Tadayoshi Sato]

Hi folks,

I'd like to add an integration test for camel-servlet that can run only on
Spring Boot. Initially I thought to add it to
tests/camel-itest-spring-boot, but this is rather for systematic
compatibility checks for camel components with Spring Boot, not where a
real cross-component regression test is placed.

Where should I put such Spring Boot integration tests in Camel project?  Is
it good idea to create another sub-project under tests/?  If so what do you
think is the best name for the project?  I cannot think of a good name for
such a project..., e.g. tests/camel-itest-spring-boot-issues?

Best regards,
Tadayoshi

Re: [ANNOUNCEMENT] Brand new Apache Camel website

[Tadayoshi Sato]

Congratulations, and well done to all who have been involved in the website
renewal!!!

On Tue, Aug 20, 2019 at 10:03 PM Zoran Regvart  wrote:

> Hi Cameleers!
> I'm delighted to announce that the new Apache Camel website is live
> now. This has been a work that many of you contributed to either
> directly by modifying the site content working on the design or
> functionality or indirectly by providing feedback.
>
> Have a look at the new website at:
>
> https://camel.apache.org/
>
> Please feel free to share feedback we're always looking for ways to
> improve, we already have some issues that we're working on[1].
>
> If you find any issues with the website you can either create a an
> JIRA issue and set the component to 'website', or you can use the new
> functionality 'Edit this Page' to suggest improvements yourself!
>
> zoran
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20component%20%3D%20website
> --
> Zoran Regvart
>

Re: [DISCUSS] New Camel website, rump up to go live

[Tadayoshi Sato]

The new website looks great. Great job to Zoran and everyone involved in
the website renewal!

On Fri, Aug 16, 2019 at 2:32 AM Zoran Regvart  wrote:

> Hi Cameleers,
> today I merged the redesign of the front page. I will work on adding a
> filter box to the compnents navigation menu (CAMEL-13622[1]),
> Nayananga has a PR in the works for adding site search. I would still
> like to address the design of the news section (CAMEL-13818[2]).
>
> That would resolve all but a few issues on the new website
> (CAMEL-11492[3]), and with that I would like to *launch the website
> early next week*.
>
> If you have few moments have a look at the staging site[4] and log any
> issues as sub-tasks of CAMEL-11492[3] that you find blocking for the
> website launch. Also please have a look at any issue you might be able
> to help with.
>
> I'll be on vacation from tomorrow till Monday, so I might not as
> responsive to new issues.
>
> zoran
>
> [1] https://issues.apache.org/jira/browse/CAMEL-13622
> [2] https://issues.apache.org/jira/browse/CAMEL-13818
> [3] https://issues.apache.org/jira/browse/CAMEL-11492
> [4] https://camel.apache.org/staging/
>
> On Thu, Aug 1, 2019 at 11:18 AM Zoran Regvart  wrote:
> >
> > Hi Cameleers,
> > so it's been a while since we discussed the state of the new website,
> > so let me start by enumerating what we have done so far and then what
> > I think needs to be done for the website to go live.
> >
> > So what has been done:
> >
> > A lot. A lot of folk over almost two years helped with the website
> > effort and their help needs to be acknowledged. I'm sorry not to
> > mention everyone here as I would certainly forget someone. I do wish
> > to thank you all for your contributions.
> >
> > In points:
> >  - content from the Confluence wiki has been (high 90% of it) cleaned
> > up and migrated to asciidoc format and is now maintained in the git
> > repository
> >  - tools that maintain the documentation were developed (updating from
> > javadoc, moving/copying documents and maintaining indexes)
> >  - initial website design was contributed and polished over time
> >  - tools to build and develop the website were implemented and
> > integrated with the CI
> >  - a lot of small paper-cut issues were resolved
> >
> > You can find the majority of these issues as subtasks of CAMEL-11492[1].
> >
> > What I think needs to be done:
> >  - gather more feedback on the staging website
> > (https://camel.apache.org/staging/)
> >  - find/resolve any search engine issues (such as CAMEL-13800[2])
> >
> > What I think would be good to do:
> >  - more search engine optimization (like the microdata effort
> CAMEL-11494[3])
> >  - I'd like to polish the documentation a bit CAMEL-13780[3], if it
> > turns out not too much work split up the documentation into even
> > further modules (CAMEL-13812[4])
> >  - add search (CAMEL-11503)
> >  - iron out any design/responsive layout issues
> >
> > I think we can work on the 'needs to be done' bits in the following
> > week and rump up the effort to replace the old website with the new
> > one currently present only on the staging.
> >
> > And depending on the feedback, that is if there are no large blocking
> > issues found, I think we can go live with the new website somewhere in
> > the middle of August.
> >
> > So, with that I would like to call to action, I'd like to have a list
> > of actionable issues we need to resolve for the go live of the new
> > website.
> >
> > If you can take a moment and have a look at the staging site
> > (https://camel.apache.org/staging/) and either by replying on the
> > thread or by creating a subtask on CAMEL-11492[1] with any issues that
> > you think need to be addressed before we go live.
> >
> > And, if you can contribute to this effort, by modifying the design,
> > improving the build tools, correcting the documentation please feel
> > free to do so.
> >
> > zoran
> >
> > [1] https://issues.apache.org/jira/browse/CAMEL-11492
> > [2] https://issues.apache.org/jira/browse/CAMEL-13800
> > [3] https://issues.apache.org/jira/browse/CAMEL-11494
> > [4] https://issues.apache.org/jira/browse/CAMEL-13780
> > [5] https://issues.apache.org/jira/browse/CAMEL-13812
> > [6] https://issues.apache.org/jira/browse/CAMEL-11503
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Zoran Regvart
>

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

[Tadayoshi Sato]

+1

Maybe it's also good time to review other components that have similar
variants.

On Thu, Jul 25, 2019 at 7:09 PM Alex Dettinger 
wrote:

> +1
>
> On Thu, Jul 25, 2019 at 12:02 PM Andrea Cosentino 
> wrote:
>
> > +1
> >
> > Il giorno gio 25 lug 2019 alle ore 11:48 Claus Ibsen <
> > claus.ib...@gmail.com>
> > ha scritto:
> >
> > > Hi
> > >
> > > So what has been bothering Camel 2.x users is that when they use http
> > > they would likely use the camel-http4 component and then they should
> > > use http4 as the component name. The old camel-http component is
> > > deprecated as the http client it uses is EOL for many many years.
> > >
> > > So with Camel 3 on the way we have deleted the old camel-http
> > > component and the camel-http4 component now has both http and http4 as
> > > component names.
> > >
> > > I think we should rename the camel-http4 back to camel-http and then
> > > favour using http as the component name, and then deprecate http4 (or
> > > even remove it).
> > >
> > > Any thoughts?
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
> >
>

Re: [HEADSUP] Documentation link checker in the build

[Tadayoshi Sato]

And if I'm not mistaken, are the header IDs [[...]] such as:
https://raw.githubusercontent.com/apache/camel/master/core/camel-core/src/main/docs/eips/aggregate-eip.adoc
-
[[aggregate-eip]]
== Aggregate EIP
...
-
not necessary any longer as they are used only for <<...>> style of
cross-referencing?

Best regards,
Tadayoshi

On Wed, Jul 24, 2019 at 11:41 AM Tadayoshi Sato 
wrote:

> Great job Zoran and Nayananga!
>
> Just to make sure, is now the <> type of cross-referencing
> all deprecated and should be rewritten to xref link?  Looks like there are
> still a few leftovers that still use the <> style.
>
> Thank you,
> Tadayoshi
>
> On Wed, Jul 24, 2019 at 3: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: [HEADSUP] Documentation link checker in the build

[Tadayoshi Sato]

Great job Zoran and Nayananga!

Just to make sure, is now the <> type of cross-referencing all
deprecated and should be rewritten to xref link?  Looks like there are
still a few leftovers that still use the <> style.

Thank you,
Tadayoshi

On Wed, Jul 24, 2019 at 3: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: Quarkus

[Tadayoshi Sato]

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/camel-quarkus#fast-build-times
>
> Thanks,
>
> Peter
> --
> Peter Palaga, Red Hat Fuse
>
> On 04/06/2019 12:44, Andrea Cosentino wrote:
> > +1 for working with the Quarkus community.
> >
> > I don't think this would be an incubator project btw, it should be a
> > subproject if it will go in a separate repo or it will be placed in the
> > main repo as a platform.
> >
> > We can discuss this later by the way.
> >
> >
> >
> > Il giorno mar 4 giu 2019 alle ore 12:34 Willem Jiang <
> willem.ji...@gmail.com>
> > ha scritto:
> >
> >> +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 

Re: [VOTE]

[Tadayoshi Sato]

Great designs, Jason!
I like 1 and 3, with a little more emphasis on 3 :-)

Thank you!
Tadayoshi

On Thu, Apr 25, 2019 at 11:21 AM Nayananga Muhandiram <
nayanangamuhandi...@gmail.com> wrote:

> +1 for concept three :)
>
> Thank you,
>
> *Nayananga Anuradha Muhandiram*
>
> Batch 11,
> Department of Computer Science,
> Faculty of  Science,
> University of Jaffna.
>
> Contacts :
> |Mobile : (+94) 716369541 / (+94) 711475769
> |whatsapp : +94716369541
> |email : nayanangamuhandi...@gmail.com
> |facebook : *https://web.facebook.com/nayananga
> *
> |linkedln : *https://www.linkedin.com/in/nayanangamuhandiram/
> *
>
>
> On Thu, 25 Apr 2019 at 05:14, Willem Jiang  wrote:
>
> > +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  | jbr...@redhat.com |
> > > 512-786-8304
> >
>

Re: Question about Camel Connector

[Tadayoshi Sato]

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: Camel website

[Tadayoshi Sato]

Awesome job, Francois!  That's really modern & cool web site!

On Tue, Dec 18, 2018 at 9:06 PM Francois Papon 
wrote:

> Cool!
>
> I will push a PR for the responsive soon.
>
> Regards,
>
> François Papon
> fpa...@apache.org
>
> Le 18/12/2018 à 15:51, Zoran Regvart a écrit :
> > Thank you François, I merged your PR to camel-website master and it's
> > now on staging:
> >
> > https://camel.apache.org/staging/
> >
> > looks pretty good :)
> >
> > zoran
> >
> > On Mon, Dec 17, 2018 at 11:19 AM Francois Papon
> >  wrote:
> >> Hi,
> >>
> >> Thanks for your feeback!
> >>
> >> For the mobile responsive, I didn't work on it yet but I keep it in
> mind ;)
> >>
> >> Regards,
> >>
> >> François Papon
> >> fpa...@apache.org
> >>
> >> Le 17/12/2018 à 12:41, Andrea Cosentino a écrit :
> >>> Really nice! Only that problem on mobile, but it looks great.
> >>>
> >>> --
> >>> Andrea Cosentino
> >>> --
> >>> Apache Camel PMC Chair
> >>> Apache Karaf Committer
> >>> Apache Servicemix PMC Member
> >>> Email: ancosen1...@yahoo.com
> >>> Twitter: @oscerd2
> >>> Github: oscerd
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Monday, December 17, 2018, 9:33:21 AM GMT+1, Onder SEZGIN <
> ond...@apache.org> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Thanks François. It looks very nice.
> >>> One minor comment:
> >>> Look and feel is overlapping on mobile view. Maybe it could be
> adjusted to
> >>> be more responsive.
> >>>
> >>> On Sun, Dec 16, 2018 at 3:59 PM Zoran Regvart 
> wrote:
> >>>
>  Hi François,
>  I think that's awesome! Please do create a PR :)
> 
>  zoran
>  On Sat, Dec 15, 2018 at 7:28 PM Francois Papon
>   wrote:
> > Hi guys,
> >
> > I made some design integration on the website based on the new logo,
> > it's not fully finished and it's just a proposal.
> >
> > You can have a preview about the home page here :
> >
> > https://openobject.fr/camel/
> >
> > If you like it I'm ready to push my PR and move forward with the
> > documentation theme ;)
> >
> > Regards,
> >
> > François Papon
> > fpa...@apache.org
> >
> > Le 14/12/2018 à 18:03, Claus Ibsen a écrit :
> >> Hi
> >>
> >> Yay its good to see progress on this, and that we can easily have a
> >> sneak-peak by browsing that staging site.
> >>
> >> Great work guys, love to see the collaboration going on, to
> >> reinvigorate the Camel project and its website.
> >>
> >>
> >> On Thu, Dec 13, 2018 at 12:36 PM Zoran Regvart 
>  wrote:
> >>> Hi Cameleers,
> >>> the first iteration of the build[1] of the new website is up on the
>  staging URL:
> >>> https://camel.apache.org/staging/
> >>>
> >>> it took a while to get all the kinks worked out but it seems OK
> now.
> >>>
> >>> Bare in mind that this is still very early, rough version: links
> will
> >>> be broken or point to wrong places, layout and styling is almost
> >>> non-existant.
> >>>
> >>> This at least gives us the opportunity to see any changes we make
> >>> really quickly online.
> >>>
> >>> I'll work on adding some READMEs to explain how to contribute and
> >>> cleanup JIRA issues around the new website next.
> >>>
> >>> zoran
> >>>
> >>> [1]
> 
> https://builds.apache.org/blue/organizations/jenkins/Camel.website/activity
> >>> --
> >>> Zoran Regvart
>  --
>  Zoran Regvart
> 
> >
> >
>

Re: Create an Apache Camel Twitter Account

[Tadayoshi Sato]

So @cameltweet is only for dev, right?

+1 for acquiring @ApacheCamel.

On Fri, Dec 14, 2018 at 7:24 AM Onder SEZGIN  wrote:

> +1
>
> On Thu, Dec 13, 2018 at 8:26 PM  wrote:
>
> > +1. A twitter account and especially that account name would be nice.
> > Am 13. Dez. 2018, 15:49 +0100 schrieb Willem Jiang <
> willem.ji...@gmail.com
> > >:
> > > +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: Hosted web site

[Tadayoshi Sato]

Awesome stuff, Zoran!  Thank you.

I'll peek into the asf-site branch and try to polish it.

Best regards,
Tadayoshi

On Tue, Oct 30, 2018 at 10:13 PM Andrea Cosentino
 wrote:

> Great stuff!
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Tuesday, October 30, 2018, 2:05:04 PM GMT+1, Zoran Regvart <
> zo...@regvart.com> wrote:
>
>
>
>
>
> Hi Tadayoshi & Cameleers,
> so the staging site now works* it's at:
>
> https://camel.apache.org/staging/
>
> *and by that I mean: the content of camel-website's asf-site branch is
> published there. It is pretty much broken at the moment, CSS and links
> are generated with absolute values, I need to take a look and make
> them relative so that the website can be nested in that /staging
> directory.
>
> zoran
>
> On Tue, Oct 30, 2018 at 11:40 AM, Zoran Regvart  wrote:
> > Hi Tadayoshi,
> > I'm really sorry I had little time to look into this, the process
> > should look like this:
> >
> > We make changes on the camel.git gitbox repository (or GitHub mirror)
> > to the `website` branch (till it's merged over to `master`), Jenkins
> > builds the website (Jenkinsfile on `website` branch does this[1]) and
> > pushes to the camel-website.git repository's `asf-site` branch. Then a
> > script provided by the INFRA[2] should sync with the website's
> > /staging directory.
> >
> > I think we need a `asf-site-staging` and a `asf-site` branches on
> > `camel-website.git` repository and a way to merge from one repository
> > to the other (Jenkins job?), but let's make some smaller steps first.
> >
> > zoran
> >
> > [1]
> https://gitbox.apache.org/repos/asf?p=camel.git;a=blob;f=Jenkinsfile;h=f094a624332bed955c686ec4a9951aeaa004c258;hb=refs/heads/website#l47
> > [2] https://issues.apache.org/jira/browse/INFRA-15969
> >
> > On Tue, Oct 30, 2018 at 9:59 AM, Tadayoshi Sato
> >  wrote:
> >> Hi all,
> >>
> >> I've been working on migrating docs, and while there are still a number
> of
> >> pages to be migrated yet it's also becoming in good shape. I think it's
> >> good time to host the docs somewhere so that everyone can read and
> further
> >> contribute to the site.
> >>
> >> I'm aware that recently Francois and Zoran worked on doc site generation
> >> and https://github.com/apache/camel-website. Is it currently accessible
> >> online?  Can we publish the static site somewhere like GH Pages,
> surge.sh,
> >> or Netlify?
> >>
> >> The docs are already available on GH as asciidoc but the problem is that
> >> links of reference style i.e. <> do not work on the
> >> plain GH. I believe we need some place where those reference style links
> >> are also rendered.
> >>
> >> Best regards,
> >> Tadayoshi
> >
> >
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Zoran Regvart
>

Hosted web site

[Tadayoshi Sato]

Hi all,

I've been working on migrating docs, and while there are still a number of
pages to be migrated yet it's also becoming in good shape. I think it's
good time to host the docs somewhere so that everyone can read and further
contribute to the site.

I'm aware that recently Francois and Zoran worked on doc site generation
and https://github.com/apache/camel-website. Is it currently accessible
online?  Can we publish the static site somewhere like GH Pages, surge.sh,
or Netlify?

The docs are already available on GH as asciidoc but the problem is that
links of reference style i.e. <> do not work on the
plain GH. I believe we need some place where those reference style links
are also rendered.

Best regards,
Tadayoshi

Re: CamelBeanValidatorTest is failing

[Tadayoshi Sato]

Hi Andrea,

Yeah, it doesn't reproduce locally in my laptop, either.

The last commit that the camel-itest-karaf ran successfully on Jenkins was
this on Aug 1:
https://github.com/apache/camel/commit/0b243a48aea3f30fba8460c7b26f7b184b3c6456
so it could be that any changes that were committed right after the commit
may have caused the itest failures. (It's also possible that any external
factors such as changes on the maven central repo that happened right after
Aug 1  could have caused it though.)

However the original failed build history #2210 is already gone on Jenkins:
https://builds.apache.org/job/Camel.trunk.itest.karaf/
so it's hard to detect which one is the culprit.

I found this ticket. Was this itest failure the original motivation for the
task?
https://issues.apache.org/jira/browse/CAMEL-11650


On Thu, Sep 7, 2017 at 10:24 AM, Tadayoshi Sato <sato.tadayo...@gmail.com>
wrote:

> Filed the JIRA: https://issues.apache.org/jira/browse/CAMEL-11758
> I'll look into it.
>
> On Wed, Sep 6, 2017 at 3:02 PM, Andrea Cosentino <ancosen1...@yahoo.com>
> wrote:
>
>> Tested locally it seems to work.
>>
>> [org.ops4j.store.intern.TemporaryStore] : Exit store():
>> 8e7251cf3141ec0862eb074f2466f6df6820a6d0
>> [org.ops4j.pax.exam.container.remote.RBCRemoteTarget] : Preparing and
>> Installing bundle (from stream )..
>> [org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient] : Packing
>> probe into memory for true RMI. Hopefully things will fill in..
>> [org.ops4j.pax.exam.container.remote.RBCRemoteTarget] : Installed bundle
>> (from stream) as ID: 80
>> [org.ops4j.pax.exam.container.remote.RBCRemoteTarget] : call
>> [[TestAddress:PaxExam-d99f7da4-022e-4e50-8778-4ec519603761
>> root:PaxExam-5408707c-548d-485f-b49e-98d07bdbbdfc]]
>> [org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer] :
>> Shutting down the test container (Pax Runner)
>> [org.ops4j.pax.exam.spi.reactors.ReactorManager] : suite finished
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.461
>> sec - in org.apache.camel.itest.karaf.CamelBeanValidatorTest
>>
>>
>>
>> --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix PMC Member
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>>
>>
>>
>>
>> On Wednesday, September 6, 2017, 6:43:22 AM GMT+2, Tadayoshi Sato <
>> sato.tadayo...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> Looks like CamelBeanValidatorTest in camel-itest-karaf is failing:
>>
>> https://builds.apache.org/job/Camel.trunk.itest.karaf/2397/console
>>
>>
>> Tests in error:
>>   CamelBeanValidatorTest.test » WrappedTestContainer
>> [test(org.apache.camel.ites...
>>
>>
>> Best regards,
>> Tadayoshi
>>
>>
>

Re: CamelBeanValidatorTest is failing

[Tadayoshi Sato]

Filed the JIRA: https://issues.apache.org/jira/browse/CAMEL-11758
I'll look into it.

On Wed, Sep 6, 2017 at 3:02 PM, Andrea Cosentino <ancosen1...@yahoo.com>
wrote:

> Tested locally it seems to work.
>
> [org.ops4j.store.intern.TemporaryStore] : Exit store():
> 8e7251cf3141ec0862eb074f2466f6df6820a6d0
> [org.ops4j.pax.exam.container.remote.RBCRemoteTarget] : Preparing and
> Installing bundle (from stream )..
> [org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient] : Packing probe
> into memory for true RMI. Hopefully things will fill in..
> [org.ops4j.pax.exam.container.remote.RBCRemoteTarget] : Installed bundle
> (from stream) as ID: 80
> [org.ops4j.pax.exam.container.remote.RBCRemoteTarget] : call
> [[TestAddress:PaxExam-d99f7da4-022e-4e50-8778-4ec519603761
> root:PaxExam-5408707c-548d-485f-b49e-98d07bdbbdfc]]
> [org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer] :
> Shutting down the test container (Pax Runner)
> [org.ops4j.pax.exam.spi.reactors.ReactorManager] : suite finished
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.461 sec
> - in org.apache.camel.itest.karaf.CamelBeanValidatorTest
>
>
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
>
> On Wednesday, September 6, 2017, 6:43:22 AM GMT+2, Tadayoshi Sato <
> sato.tadayo...@gmail.com> wrote:
>
>
>
>
>
> Looks like CamelBeanValidatorTest in camel-itest-karaf is failing:
>
> https://builds.apache.org/job/Camel.trunk.itest.karaf/2397/console
>
>
> Tests in error:
>   CamelBeanValidatorTest.test » WrappedTestContainer
> [test(org.apache.camel.ites...
>
>
> Best regards,
> Tadayoshi
>
>

CamelBeanValidatorTest is failing

[Tadayoshi Sato]

Looks like CamelBeanValidatorTest in camel-itest-karaf is failing:

https://builds.apache.org/job/Camel.trunk.itest.karaf/2397/console


Tests in error:
  CamelBeanValidatorTest.test » WrappedTestContainer
[test(org.apache.camel.ites...


Best regards,
Tadayoshi

Re: Request for Wiki permissions

[Tadayoshi Sato]

Thank you, Claus!

On Wed, Jun 7, 2017 at 3:27 PM, Claus Ibsen <claus.ib...@gmail.com> wrote:

> Hi Tada
>
> I have granted you karma to edit the wikis
>
> On Wed, Jun 7, 2017 at 2:54 AM, Tadayoshi Sato <sato.tadayo...@gmail.com>
> wrote:
> > Hello Camel Dev,
> >
> > I'd like to edit the 2.20.0 release notes so give me permissions for
> > editing the wiki please.
> > https://cwiki.apache.org/confluence/display/CAMEL/Camel+2.20.0+Release
> >
> > My Confluence ID is: tsato
> >
> > Thank you,
> > Tadayoshi
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Request for Wiki permissions

[Tadayoshi Sato]

Hello Camel Dev,

I'd like to edit the 2.20.0 release notes so give me permissions for
editing the wiki please.
https://cwiki.apache.org/confluence/display/CAMEL/Camel+2.20.0+Release

My Confluence ID is: tsato

Thank you,
Tadayoshi

Re: Apache Camel 2.19 release blog posts and help spread the word

[Tadayoshi Sato]

Hi,

I'll write an article summarising the 2.19 features/highlights in Japanese
at qiita.com. qiita.com is the hottest knowledge sharing service for
techies in Japan.

On Wed, Apr 26, 2017 at 4:36 PM, Claus Ibsen  wrote:

> Hi Jens
>
> Yes this sounds good. You can post on your personal blog.
> And then we can link to it when we help spread the word.
>
> On Tue, Apr 25, 2017 at 5:18 PM, Jens Reimann  wrote:
> > If you like I can write up something for the Milo component.
> >
> > I can publish this either on my personal blog or somewhere else. Whatever
> > you prefer.
> >
> > On Mon, Apr 24, 2017 at 2:24 PM, Andrea Cosentino <
> > ancosen1...@yahoo.com.invalid> wrote:
> >
> >> Great idea! I can write something :-)
> >>
> >> --
> >> Andrea Cosentino
> >> --
> >> Apache Camel PMC Member
> >> Apache Karaf Committer
> >> Apache Servicemix PMC Member
> >> Email: ancosen1...@yahoo.com
> >> Twitter: @oscerd2
> >> Github: oscerd
> >>
> >>
> >> On Monday, April 24, 2017 2:15 PM, Claus Ibsen 
> >> wrote:
> >>
> >>
> >>
> >> Hi
> >>
> >>
> >> When the new 2.19 release is out the door, it would be good if we
> >>
> >> could spread the word about this release with a number of blogs posts,
> >>
> >> twitter, and publish articles on websites etc.
> >>
> >>
> >> For that we may need a general blog post with the news and a summary
> >>
> >> of the top 10 most noteworthy features/changes. I have done some of
> >>
> >> those in the past (such as
> >>
> >> http://www.davsclaus.com/2016/10/apache-camel-218-released-
> >> whats-included.html).
> >>
> >>
> >> And then maybe some blog posts that are a specific about one
> >>
> >> functionality, such as Luca's recent about service call for cloud,
> >>
> >> etc.
> >>
> >>
> >> Any thoughts?
> >>
> >>
> >>
> >> --
> >>
> >> Claus Ibsen
> >>
> >> -
> >>
> >> http://davsclaus.com @davsclaus
> >>
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
> >
> >
> >
> > --
> > Jens Reimann
> > Senior Software Engineer / EMEA ENG Middleware
> > Werner-von-Siemens-Ring 14
> > 85630 Grasbrunn
> > Germany
> > phone: +49 89 2050 71286
> > 
> _
> >
> > Red Hat GmbH, www.de.redhat.com,
> > Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
> HRB
> > 153243,
> > Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> > Michael O'Neill
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Build using Maven 3.5.0

[Tadayoshi Sato]

Hi,

I've started using Maven 3.5.0 recently and so far I haven't found any
issues with it on Camel development (I'm using macOS). Once you switch to
it you should be amazed that Maven output gets colorful :-)

On Sat, Apr 22, 2017 at 5:14 PM, Claus Ibsen  wrote:

> Hi
>
> I have been using the old/stable Maven 3.2.5 for a rather long time.
> And Maven 3.3.3 should be good as well since that is what the CI
> servers are using.
>
> Anyone tried using the new Maven 3.5.0 and build the Camel source code
> with that. And if so any feedback?
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

camel-itest-karaf is now GREEN

[Tadayoshi Sato]

Wow, all camel-itest-karaf tests pass green. Awesome!
https://builds.apache.org/blue/organizations/jenkins/Camel.trunk.itest.karaf/activity/

Best regards,
Tadayoshi

Re: Most of camel-itest-osgi removed

[Tadayoshi Sato]

Thanks Claus. I understand that maintaining tests can be burden, and especially 
for flaky OSGi tests.

Thanks,
Tadayoshi

> On Mar 9, 2017, at 15:38:06, Claus Ibsen <claus.ib...@gmail.com> wrote:
> 
> Hi
> 
> We dont have interrest in maintaining those tests. They sit there for
> years going untouched and break from time to time.
> 
> We only want a limited few set of tests that does a coarse grained
> sanity check of osgi.
> 
> 
> 
> 
> On Thu, Mar 9, 2017 at 1:48 AM, Tadayoshi Sato <sato.tadayo...@gmail.com> 
> wrote:
>> Hi Camel Devs,
>> 
>> I just noticed that most of camel-itest-osgi were removed nearly a year
>> ago. I understand it was due to migration of old itests to the new
>> camel-test-karaf module. But I also suspect that there were indeed some
>> useful itests that had ensured a critical regression wouldn't happen.
>> 
>> Are there any thoughts on recovering those removed itests eventually?  Or
>> doesn't it just make sense?
>> 
>> Thank you,
>> 
>> Tadayoshi
> 
> 
> 
> -- 
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Most of camel-itest-osgi removed

[Tadayoshi Sato]

Hi Camel Devs,

I just noticed that most of camel-itest-osgi were removed nearly a year
ago. I understand it was due to migration of old itests to the new
camel-test-karaf module. But I also suspect that there were indeed some
useful itests that had ensured a critical regression wouldn't happen.

Are there any thoughts on recovering those removed itests eventually?  Or
doesn't it just make sense?

Thank you,

Tadayoshi

Re: 3rd party jars not in Maven central, add them to git repository?

[Tadayoshi Sato]

Hi Zoran,

As Pontus pointed out, for an Apache project 3rd party jars need to be ASL
compatible in order to include them into the source repository. To my
knowledge, that was the reason why Camel officially doesn't have
camel-paypay component:
https://issues.apache.org/jira/browse/CAMEL-5093

FWIW, camel-box component has a similar situation with regard to
integration tests, where it needs some proprietary information to run
itests. So the component keeps out the itests to a separate Maven profile
("box-test") and developers need to run them manually.
https://github.com/apache/camel/tree/master/components/camel-box

Best regards,
Tadayoshi

On Tue, Feb 21, 2017 at 6:24 AM, Pontus Ullgren  wrote:

> Hi,
>
> You can always try to incourage Salesforce to do it since ofcourse that
> would be better.
> However failing to convince them there is no problem that you/we do it
> ourself. As I wrote it's beeing done for other projects.
> One example is the JCIFS library used in camel-extra. The official project
> has for a long time refused to publish the artifact to
> maven central so as such we do it ourself as individuals.
>
> I agree it is "wrong" but IMHO it's better, or at least just as wrong, as
> keeping the jars commited into the git repo.
> Both ways will put the coordination/maintance work on the camel project but
> keeping it in a artifact repo makes more sense than in the source repo (at
> least to me).
>
> // Pontus
>
> On Mon, 20 Feb 2017 at 22:02 Zoran Regvart  wrote:
>
> > Hi Pontus,
> > first of all, thank you :)
> >
> > Yeah, I would love to do that, but it brings along another set of
> > other questions: is it up to me/us or Salesforce to publish the jar in
> > Maven central? And to what coordinates, Camels?
> >
> > That kinda feels more wrong to me :(
> >
> > zoran
> >
> > On Mon, Feb 20, 2017 at 9:48 PM, Pontus Ullgren 
> wrote:
> > > Hi,
> > >
> > > Would it not be a better solution to publish the jar ourself to maven
> > > central ?
> > > Similare to what SMX project does for other 3rd party libraries that
> are
> > > not osgi compatible bundles ?
> > >
> > > Just my $0.02
> > > // Pontus
> > >
> > >
> > > On Mon, 20 Feb 2017 at 15:07 Zoran Regvart  wrote:
> > >
> > >> Hi Cameleers,
> > >> what do you think about adding 3rd party jars to the git repo (as
> binary
> > >> blobs)?
> > >>
> > >> Background: integration tests for Salesforce component require
> > >> deployment of customizations to the your Salesforce instance, so in
> > >> order to run them you need to make a number of manual steps
> > >> beforehand[1].
> > >>
> > >> Salesforce publishes a Migration tool[2] as a set of Ant tasks. These
> > >> are packaged as a jar file that is not available on Maven central, so
> > >> in order to use them the user needs to download supply the jar to the
> > >> Maven build.
> > >>
> > >> I would like to automate that and to prescribe the way of managing
> > >> this customizations for future tests, so I think it would be best to
> > >> put that jar in our git repository.
> > >>
> > >> I think this would encourage contributions and allow everyone to run
> > >> the integration tests, for instance in CI.
> > >>
> > >> The license is very liberal, it just requires the inclusion of the
> > >> copyright & disclamer notice.
> > >>
> > >> What do you think?
> > >>
> > >> zoran
> > >>
> > >> [1]
> > >>
> > https://github.com/apache/camel/tree/master/components/
> camel-salesforce/camel-salesforce-component#running-the-integration-tests
> > >> [2]
> > >>
> > https://developer.salesforce.com/docs/atlas.en-us.daas.
> meta/daas/forcemigrationtool_install.htm
> > >> --
> > >> Zoran Regvart
> > >>
> >
> >
> >
> > --
> > Zoran Regvart
> >
>

Re: Time for an overhaul of the patterns symbols?

[Tadayoshi Sato]

Hi Francis,

I now fully understand your intention and personally like the idea. (I'm
one of the big fans of "flat design" :-) ) As no one else seems to have a
strong opinion about it, let me suggest one more idea.

As I said EIP diagrams are not proprietary to Camel, I think it's best to
provide your works to the broader EIP community. One of the great things
about EIP is the diagrams are provided by the authors as CC-BY license:
http://www.enterpriseintegrationpatterns.com/patterns/messaging/
so you can freely reuse and improve them so long as your works make the
original attribution clear.

So why don't you just go on your project and publish them on somewhere like
GitHub?  If your work is great and people in the EIP community like it,
then I'm sure your work will prevail!

Best regards,
Tadayoshi

On Thu, Nov 10, 2016 at 7:26 PM, Francis Vila  wrote:

> Hi Tadayoshi,
>
> Thanks for your feedback.
> Maybe I was hasty in implying there might be differences in style. Looking
> again I see the logic to the different forms in the patterns. Initially I
> saw differences in line widths and colors, differences in types of coloring
> (gradient vs flat, border vs no border, shadow vs no shadow), but these
> differences do seem to be justified by the semantics of the icons.
>
> What I really meant is that they look dated now in 2016. That's inevitable
> because people's expectations change very fast. For a technology that has
> such a future ahead of it, I think some investment in image is worthwhile.
>
> I looked for some sites offering icon sets :
> https://icomoon.io/#icons or search for icons on  Google
>  channel=fs=1376=776=qdr:y=isch=
> information+technology+icon+set=information+technology+
> icon+set_l=img.3...25490.30110.0.30494.22.20.0.0.0.0.
> 92.824.19.19.00...1c.1.64.img..4.10.414...
> 0i7i30k1j0i7i5i30k1j0i8i30k1j0i5i30k1.5hSHYE1O_W0=on.2,
> or.r_cp.=bv.138169073,d.d2s=1.4_rd=cr=K0ckWMWyLsS9aaGksYgG>
> (the icon sets appear black, but people using them can change their color)
>
> Most sets use either flat areas (no borders, single color) or lines with
> uniform width (giving the "twisted paperclip" feel). When gradients or
> shadows are used (mostly they are not), they are used uniformly throughout
> the icon set. Some sets are colorful or festive, but they mostly refer to
> Christmas or the like.
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Suggestions-for-new-set-of-integration-pattern-
> symbols-tp5789901p5789995.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

Re: Time for an overhaul of the patterns symbols?

[Tadayoshi Sato]

Hello,

Let me offer my thoughts. I think it's a good idea to somehow refresh the
EIP icons/diagrams and contribution is always great. However:

> the diagrams symbolize the essence of what Camel does.

Yes, but it also has a broader context: They actually symbolize the essence
of what most of the current competitive ESB or integration frameworks do in
common. They are symbols of our shared wisdom and best practices on systems
integration.

> However the graphics don't all seem to be in the same style, and some are
missing.

I haven't thought they aren't in the same style. Which one do you think
so?  Please note that in the original EIP book there are good reasons why
some icons are rectangles and some are not (and maybe why some are missing
originally as well). For example, in my understanding the Control Bus
pattern doesn't have a rectangle icon because in the context of the
original book it's rather an architectural pattern, while most rectangle
patterns are a component-level one.

Note also that some are missing just because they are devised (or
discovered) after the EIP book. So it might be a good idea to fill the gap
and devise a new icon for those new patterns, in the same style as in the
EIP book.

So, refreshing the icons is a good idea but I hope they won't diverge too
far from the original ones, because identity is the key for software
patterns in general.

Best regards,
Tadayoshi

On Tue, Nov 8, 2016 at 9:06 PM, Francis Vila  wrote:

> Hi,
>
> I am new to both Camel and to open-source contributing, so forgive any
> breaches of protocol...
>
> The page on  http://camel.apache.org/enterprise-integration-patterns.html
>    shows an
> impressive list of patterns. However the graphics don't all seem to be in
> the same style, and some are missing. To me (although I don't have an
> in-depth understanding of Camel), the diagrams symbolize the essence of
> what
> Camel does. Maybe a homogeneous, updated styleset would be a good idea?
> I think I can contribute to such an task. I've done some tests of different
> approaches for the /Message router /pattern. If this effort is deemed
> worthwhile by the community, I can go on with the rest. The graphics were
> done using Inkscape and are available in svg format.
>
> This is the simplest version:
> 
>
> This version has added endpoints symbolizing the input and output locations
> for the origin and destination of the messages :
> 
>
> This version encloses the pattern:
> 
>
> This version puts emphasis on the the most important part of the diagram,
> namely the currently active path:
> 
>
> This version targets the emphasis more closely, to just the "mobile" part
> of
> the diagram:
> 
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Time-for-an-overhaul-of-the-patterns-symbols-tp5789901.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

Re: Why are UnsafeUriCharactersEncoder duplicated?

[Tadayoshi Sato]

Understood. Thank you for your clarification, Claus!

Best regards,
Tadayoshi

On Fri, Feb 26, 2016 at 3:11 PM, Claus Ibsen <claus.ib...@gmail.com> wrote:

> camel-catalog is 100% standalone and has no dependency on camel-core.
> Its intended to be a small library for tooling and independent from
> the camel-core.
>
>
>
> On Fri, Feb 26, 2016 at 4:09 AM, Tadayoshi Sato
> <sato.tadayo...@gmail.com> wrote:
> > Hello Camel experts,
> >
> > I found that there are two UnsafeUriCharactersEncoder classes in the
> Camel
> > codebase, one is in camel-core and another is in camel-catalog, and they
> > are almost identical.
> >
> > Is there any reason these classes need to be duplicated?  I like DRY :-)
> >  Is it possible to remove the camel-catalog version (or perhaps annotate
> it
> > @Deprecated) and solely use the camel-core version in the codebase?
> >
> > I appreciate your advices. Thanks!
> >
> > Tadayoshi
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Why are UnsafeUriCharactersEncoder duplicated?

[Tadayoshi Sato]

Hello Camel experts,

I found that there are two UnsafeUriCharactersEncoder classes in the Camel
codebase, one is in camel-core and another is in camel-catalog, and they
are almost identical.

Is there any reason these classes need to be duplicated?  I like DRY :-)
 Is it possible to remove the camel-catalog version (or perhaps annotate it
@Deprecated) and solely use the camel-core version in the codebase?

I appreciate your advices. Thanks!

Tadayoshi