Thanks for spotting this. Il giorno mer 19 giu 2019 alle ore 12:22 Peter Palaga <ppal...@redhat.com> 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 <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 > >>>> > >>> > >> > >> > > > >
