Quarkus

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Quarkus

lburgazzoli
Hi,

In the past months some folks at Red Hat have been working on the
integration between Apache Camel and Quarkus. For those not familiar
with the topic, Quarkus is a new Apache 2 licensed Cloud Native Java
framework tailored for GraalVM and HotSpot that bring fast startup
and low memory footprint to Java based application by leverage clever
build time optimizations and AOT compilation through Substrate VM [1].

The result of the experimentation is available in the Quarkus
repository [2][3] and I’m also working on an experimental branch
on Camel K [4] to bring Quarkus on the K side based on my latest
blog “Adventures in GraalVM: polyglot Camel (k) native routes
with Quarkus”  [5]

I do believe that both communities can benefit from a collaboration:

Apache Camel can benefit from Quarkus to become
a) Even more suitable for microservices
b) Suitable for serverless workloads as Quarkus among others enables
   built-time warmup of the Camel Context, and elimination of dead-code
   (code that was only used during warmup) which is a key enabler for
   very fast start-up and low memory footprint Apache Camel can be on
   the innovative forefront with a cloud native Java stack for running
   modern serverless workloads on Kubernetes/Knative with Camel K and
   Camel Quarkus

So I’m proposing to officially support Quarkus in Apache Camel’s main
repository (or a dedicated one if it suits better) by creating a new
platform along with those we support as today (Spring Boot, Karaf).

Quarkus’ people is keen to donate the code related to Apache Camel
hosted in theirs repository to the Apache Software foundation.

There has been some other users in the community whom have tried
Quarkus and Camel together and written blogs [6] about their experience,
and Claus also posted a quick gif animation of native compiled Camel
with Quarkus starting up in 7 milliseconds and taking up only 15mb
of memory [7].

Thoughts ?

Luca

[1] https://quarkus.io/
[2] https://github.com/quarkusio/quarkus/tree/master/extensions/camel
[3] https://github.com/quarkusio/quarkus-quickstarts/tree/master/camel-java
[4]
https://github.com/lburgazzoli/apache-camel-k-runtime/tree/quarkus-runtime
[5] https://bit.ly/2HvOrh0
[6] https://bit.ly/2WDtCbW
[7]
https://www.linkedin.com/feed/update/urn:li:activity:6521869236153970688/

---
Luca Burgazzoli
Reply | Threaded
Open this post in threaded view
|

Re: Quarkus

Willem.Jiang
Administrator
+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 <[hidden email]> wrote:

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

Re: Quarkus

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

Re: Quarkus

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

Reply | Threaded
Open this post in threaded view
|

Re: Quarkus

Andrea Cosentino-3
In reply to this post by Andrea Cosentino-3
My fault about the ip-clearance. We must pass through that step. Thanks for
pointing this out Willem. The incubator name deceived me.

Il mar 4 giu 2019, 12:44 Andrea Cosentino <[hidden email]> ha scritto:

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

Re: Quarkus

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

Re: Quarkus

Hiram Chirino
In reply to this post by Willem.Jiang
I'm not sure this is much different from a new camel component
contribution.  The whole Quarkus project is not being donated, this just
the camel integration with Quarkus.  It was mostly worked on by camel
committers.  I think that a Red Hat employee that's a Camel comitter should
be able to contribute this code to camel like other components get donated
periodically.  If we can't find a committer that is confident it's 100% Red
Hat copyright, then yeah let's go through the ip-clearance.

On Tue, Jun 4, 2019 at 6:34 AM Willem Jiang <[hidden email]> wrote:

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


--
Hiram Chirino
Engineering | Red Hat, Inc.
[hidden email] | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: Quarkus

Peter Palaga
In reply to this post by tadayosi
Hi Again,

just a heads up that the topic of moving Camel extensions away from the
Quarkus source tree and generally how such externally developed
extensions can live within the Quarkus ecosystem is discussed on
quarkus-dev mailing list:
https://groups.google.com/forum/#!topic/quarkus-dev/yeo0yvC48zA

Thanks,

-- Peter

On 05/06/2019 07:15, Tadayoshi Sato wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: Quarkus

Andrea Cosentino-3
Thanks for spotting this.

Il giorno mer 19 giu 2019 alle ore 12:22 Peter Palaga <[hidden email]>
ha scritto:

> Hi Again,
>
> just a heads up that the topic of moving Camel extensions away from the
> Quarkus source tree and generally how such externally developed
> extensions can live within the Quarkus ecosystem is discussed on
> quarkus-dev mailing list:
> https://groups.google.com/forum/#!topic/quarkus-dev/yeo0yvC48zA
>
> Thanks,
>
> -- Peter
>
> On 05/06/2019 07:15, Tadayoshi Sato wrote:
> > Hi folks,
> >
> > I like Peter's idea on having a separate repository for camel-quarkus.
> >
> > In addition to his point, I would add that Quarkus is a newly born,
> cutting
> > edge technology, which itself should evolve fast and likely may not keep
> > how it works now for long as we see in, say, Node.js community. Having a
> > separate repository should let us experiment fast as well and catch up
> with
> > the rapid evolution in Quarkus without touching the main Camel codebase.
> >
> > On Tue, Jun 4, 2019 at 8:07 PM Peter Palaga <[hidden email]> 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 <
> >> [hidden email]>
> >>> 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 <[hidden email]
> >
> >>>> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> In the past months some folks at Red Hat have been working on the
> >>>>> integration between Apache Camel and Quarkus. For those not familiar
> >>>>> with the topic, Quarkus is a new Apache 2 licensed Cloud Native Java
> >>>>> framework tailored for GraalVM and HotSpot that bring fast startup
> >>>>> and low memory footprint to Java based application by leverage clever
> >>>>> build time optimizations and AOT compilation through Substrate VM
> [1].
> >>>>>
> >>>>> The result of the experimentation is available in the Quarkus
> >>>>> repository [2][3] and I’m also working on an experimental branch
> >>>>> on Camel K [4] to bring Quarkus on the K side based on my latest
> >>>>> blog “Adventures in GraalVM: polyglot Camel (k) native routes
> >>>>> with Quarkus”  [5]
> >>>>>
> >>>>> I do believe that both communities can benefit from a collaboration:
> >>>>>
> >>>>> Apache Camel can benefit from Quarkus to become
> >>>>> a) Even more suitable for microservices
> >>>>> b) Suitable for serverless workloads as Quarkus among others enables
> >>>>>      built-time warmup of the Camel Context, and elimination of
> >> dead-code
> >>>>>      (code that was only used during warmup) which is a key enabler
> for
> >>>>>      very fast start-up and low memory footprint Apache Camel can be
> on
> >>>>>      the innovative forefront with a cloud native Java stack for
> running
> >>>>>      modern serverless workloads on Kubernetes/Knative with Camel K
> and
> >>>>>      Camel Quarkus
> >>>>>
> >>>>> So I’m proposing to officially support Quarkus in Apache Camel’s main
> >>>>> repository (or a dedicated one if it suits better) by creating a new
> >>>>> platform along with those we support as today (Spring Boot, Karaf).
> >>>>>
> >>>>> Quarkus’ people is keen to donate the code related to Apache Camel
> >>>>> hosted in theirs repository to the Apache Software foundation.
> >>>>>
> >>>>> There has been some other users in the community whom have tried
> >>>>> Quarkus and Camel together and written blogs [6] about their
> >> experience,
> >>>>> and Claus also posted a quick gif animation of native compiled Camel
> >>>>> with Quarkus starting up in 7 milliseconds and taking up only 15mb
> >>>>> of memory [7].
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> Luca
> >>>>>
> >>>>> [1] https://quarkus.io/
> >>>>> [2]
> https://github.com/quarkusio/quarkus/tree/master/extensions/camel
> >>>>> [3]
> >>>>
> https://github.com/quarkusio/quarkus-quickstarts/tree/master/camel-java
> >>>>> [4]
> >>>>>
> >>>>
> >>
> https://github.com/lburgazzoli/apache-camel-k-runtime/tree/quarkus-runtime
> >>>>> [5] https://bit.ly/2HvOrh0
> >>>>> [6] https://bit.ly/2WDtCbW
> >>>>> [7]
> >>>>>
> >>>>
> >>
> https://www.linkedin.com/feed/update/urn:li:activity:6521869236153970688/
> >>>>>
> >>>>> ---
> >>>>> Luca Burgazzoli
> >>>>
> >>>
> >>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Quarkus

Willem.Jiang
Administrator
In reply to this post by Peter Palaga
Thanks for the information.
I saw there are some PRs from Peter in the camel-quarkus.
I'm not sure if Peter already signed the  iCLA[1], if not we need it
for mass code transferation.

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

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Wed, Jun 19, 2019 at 6:22 PM Peter Palaga <[hidden email]> wrote:

>
> Hi Again,
>
> just a heads up that the topic of moving Camel extensions away from the
> Quarkus source tree and generally how such externally developed
> extensions can live within the Quarkus ecosystem is discussed on
> quarkus-dev mailing list:
> https://groups.google.com/forum/#!topic/quarkus-dev/yeo0yvC48zA
>
> Thanks,
>
> -- Peter
>
> On 05/06/2019 07:15, Tadayoshi Sato wrote:
> > Hi folks,
> >
> > I like Peter's idea on having a separate repository for camel-quarkus.
> >
> > In addition to his point, I would add that Quarkus is a newly born, cutting
> > edge technology, which itself should evolve fast and likely may not keep
> > how it works now for long as we see in, say, Node.js community. Having a
> > separate repository should let us experiment fast as well and catch up with
> > the rapid evolution in Quarkus without touching the main Camel codebase.
> >
> > On Tue, Jun 4, 2019 at 8:07 PM Peter Palaga <[hidden email]> 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 <
> >> [hidden email]>
> >>> 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 <[hidden email]>
> >>>> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> In the past months some folks at Red Hat have been working on the
> >>>>> integration between Apache Camel and Quarkus. For those not familiar
> >>>>> with the topic, Quarkus is a new Apache 2 licensed Cloud Native Java
> >>>>> framework tailored for GraalVM and HotSpot that bring fast startup
> >>>>> and low memory footprint to Java based application by leverage clever
> >>>>> build time optimizations and AOT compilation through Substrate VM [1].
> >>>>>
> >>>>> The result of the experimentation is available in the Quarkus
> >>>>> repository [2][3] and I’m also working on an experimental branch
> >>>>> on Camel K [4] to bring Quarkus on the K side based on my latest
> >>>>> blog “Adventures in GraalVM: polyglot Camel (k) native routes
> >>>>> with Quarkus”  [5]
> >>>>>
> >>>>> I do believe that both communities can benefit from a collaboration:
> >>>>>
> >>>>> Apache Camel can benefit from Quarkus to become
> >>>>> a) Even more suitable for microservices
> >>>>> b) Suitable for serverless workloads as Quarkus among others enables
> >>>>>      built-time warmup of the Camel Context, and elimination of
> >> dead-code
> >>>>>      (code that was only used during warmup) which is a key enabler for
> >>>>>      very fast start-up and low memory footprint Apache Camel can be on
> >>>>>      the innovative forefront with a cloud native Java stack for running
> >>>>>      modern serverless workloads on Kubernetes/Knative with Camel K and
> >>>>>      Camel Quarkus
> >>>>>
> >>>>> So I’m proposing to officially support Quarkus in Apache Camel’s main
> >>>>> repository (or a dedicated one if it suits better) by creating a new
> >>>>> platform along with those we support as today (Spring Boot, Karaf).
> >>>>>
> >>>>> Quarkus’ people is keen to donate the code related to Apache Camel
> >>>>> hosted in theirs repository to the Apache Software foundation.
> >>>>>
> >>>>> There has been some other users in the community whom have tried
> >>>>> Quarkus and Camel together and written blogs [6] about their
> >> experience,
> >>>>> and Claus also posted a quick gif animation of native compiled Camel
> >>>>> with Quarkus starting up in 7 milliseconds and taking up only 15mb
> >>>>> of memory [7].
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> Luca
> >>>>>
> >>>>> [1] https://quarkus.io/
> >>>>> [2] https://github.com/quarkusio/quarkus/tree/master/extensions/camel
> >>>>> [3]
> >>>> https://github.com/quarkusio/quarkus-quickstarts/tree/master/camel-java
> >>>>> [4]
> >>>>>
> >>>>
> >> https://github.com/lburgazzoli/apache-camel-k-runtime/tree/quarkus-runtime
> >>>>> [5] https://bit.ly/2HvOrh0
> >>>>> [6] https://bit.ly/2WDtCbW
> >>>>> [7]
> >>>>>
> >>>>
> >> https://www.linkedin.com/feed/update/urn:li:activity:6521869236153970688/
> >>>>>
> >>>>> ---
> >>>>> Luca Burgazzoli
> >>>>
> >>>
> >>
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Quarkus

Willem.Jiang
Administrator
In reply to this post by Hiram Chirino
Hi,

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

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

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

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

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Jun 6, 2019 at 11:06 PM Hiram Chirino <[hidden email]> wrote:

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

Re: Quarkus

Peter Palaga
Hi Willem,

I signed the ICLA on 2012-02-20 when I was active in another ASF
project. So I hope there is nothing else I should do now?

Thanks,

-- Peter

On 01/07/2019 03:57, Willem Jiang wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: Quarkus

Willem.Jiang
Administrator
Hi Peter,

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

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jul 1, 2019 at 5:54 PM Peter Palaga <[hidden email]> wrote:

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