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 <ppal...@redhat.com> 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 <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 > >> > > > >
