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 <lburgazz...@gmail.com>
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
