---
Luca Burgazzoli
On Thu, Aug 2, 2018 at 8:09 AM, Guillaume Nodet wrote:
> In order to actually start the route, I forgot to add the required
> parameter:
>
> gnodet•camel/platforms/graalvm*(*graalvm*)*»
> ./example/target/org.apache.camel.graalvm.main -r
>
On Thu, Aug 2, 2018 at 12:17 AM, Luca Burgazzoli wrote:
> That’s very nice start, thx Guillaume
>
Yes this is really awesome to see this prototype in action.
> On Wed, 1 Aug 2018 at 20:15, Guillaume Nodet wrote:
>
>> I've pushed a branch with graalvm experiments.
>>
In order to actually start the route, I forgot to add the required
parameter:
gnodet•camel/platforms/graalvm*(*graalvm*)*»
./example/target/org.apache.camel.graalvm.main -r
org.apache.camel.graalvm.example.SimpleCamelRouteBuilder
[main] INFO org.apache.camel.graalvm.FastCamelContext - Apache
That’s very nice start, thx Guillaume
On Wed, 1 Aug 2018 at 20:15, Guillaume Nodet wrote:
> I've pushed a branch with graalvm experiments.
>https://github.com/apache/camel/tree/graalvm
> In order to build the project, you need to use the GraalVM jdk and use the
> following
I've pushed a branch with graalvm experiments.
https://github.com/apache/camel/tree/graalvm
In order to build the project, you need to use the GraalVM jdk and use the
following ~/.m2/toolchains.xml adapted to your path:
jdk
1.0.0-rc4
oracle
Hi Nicola,
very nice idea +1!
On Mon, Jul 30, 2018 at 5:49 PM Nicola Ferraro wrote:
> Hi Cameleers,
> it seems from the comments that this "Kamel" subproject is something we
> want to start and I think that also the main camel core will benefit from
> the new features it will bring.
>
> I
Hi
About GraalVM then I just spotted this tweet about Spring Framework
5.1 being compatible
https://twitter.com/java/status/1023632246325035008
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Hi
+1 for me
On Mon, Jul 30, 2018 at 5:49 PM, Nicola Ferraro wrote:
> Hi Cameleers,
> it seems from the comments that this "Kamel" subproject is something we
> want to start and I think that also the main camel core will benefit from
> the new features it will bring.
>
> I would like to donate
++1
---
Luca Burgazzoli
On Tue, Jul 31, 2018 at 9:47 AM, Andrea Cosentino
wrote:
> This is a wonderful idea and I believe we can improve our community with a
> subproject like this.
>
> So +1 for me.
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Chair
>
This is a wonderful idea and I believe we can improve our community with a
subproject like this.
So +1 for me.
--
Andrea Cosentino
--
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Le lun. 30 juil. 2018 à 17:49, Nicola Ferraro a
écrit :
> Hi Cameleers,
> it seems from the comments that this "Kamel" subproject is something we
> want to start and I think that also the main camel core will benefit from
> the new features it will bring.
>
> I would like to donate the current
Hi Cameleers,
it seems from the comments that this "Kamel" subproject is something we
want to start and I think that also the main camel core will benefit from
the new features it will bring.
I would like to donate the current "Kamel" code to Apache Camel, in order
to have a initial brick to
It's clear to me that we need to add support for our existing XML DSL, that
is powerful. But there are multiple reasons why I'd like to also "add" a
limited yaml/json notation to "Kamel".
The first one (and simplest) is that json/yaml is the primary encoding for
all resources exchanged with the
I also like the idea but with some comments.
As Hiram Chirino I'm not sure YAML/JSON is the best language for this.
Perhaps a more fluent DSL like the Camel Java DSL or perhaps something like
Ballerina language would be better suited ?
Also in my experience even simple integrations, that is
Love the idea.
Personally, I'd keep using the existing Camel XML DSL if possible. You can
still embed it in the CRD. The operator that deploys it could inspect it
and figure whats the most optimized runtime that can support the DSL.
Perhaps if it's only using the restricted set of camel
Hi!
Awesome idea. Seeing this being viable in a platform like Apache OpenWhisk
would be great too. I keep hearing customers asking about lightweight
containers to run Camel context. :)
+++1
Zanini
On Fri, Jul 13, 2018 at 5:31 AM, Antonin Stefanutti
wrote:
> Hi Nicola,
>
> I love the idea.
Hi Nicola,
I love the idea.
I just wonder whether YAML/JSON is an expressive enough format in the long
term. But as you’ve mentioned, starting simple would enable experimenting some
very interesting / promising optimisations. So it seems worth taking that path,
instead of trying to embed a
Of course you need to port them to go lang, the project is not intended to
be a drop in replacement for camel but a companion for integration that do
not require all the power and flexibility the jvm implementation provide
On Fri, 13 Jul 2018 at 08:55, Willem Jiang wrote:
> Hi Luca,
>
> You are
Hi Luca,
You are building Go version of Camel by implement the DSL in Go.
Now we can start the camel context by using camel-go to load the route,
but here are some missing points that I want fill such as how to reuse the
Camel components?
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
Love it so ++1
Btw, I did start some (early) experiments around alternative canel runtime
in my spare time:
- https://github.com/lburgazzoli/camel-go
- https://github.com/lburgazzoli/camel-go-examples/tree/master/example-yaml
Happy to make it part of the kamel initiative if you find it
Hi Nicola,
+1
Great idea, do you already have a concept/idea/sketch on how to deal
with complex configurations? i.e. SSL certs for outgoing calls, XSLT
transformations, etc.
When I think about it, you could probably use configmaps/secrets to
mount these config in the container an then reference
+1
Great idea!
Il ven, 13 lug, 2018 alle 7:53, Claus Ibsen ha
scritto: +1
Great idea and love the Kamel name.
On Fri, Jul 13, 2018 at 1:30 AM, Nicola Ferraro wrote:
> Hi Cameleers,
> it's now passed some time since I started thinking about a new project that
> we can begin here at
+1
Great idea and love the Kamel name.
On Fri, Jul 13, 2018 at 1:30 AM, Nicola Ferraro wrote:
> Hi Cameleers,
> it's now passed some time since I started thinking about a new project that
> we can begin here at Apache Camel, and I'd like to have your opinion.
>
> We've already been targeting
Hi,
This can make Kamel language, dsl agnostic and will give more room to
integrate faster.
Definitely +1.
On Fri, Jul 13, 2018 at 3:54 AM Willem Jiang wrote:
> Yeah, it's a really good idea to combine the K8S with Camel.
> In my mind if we want to host a camel application on the cloud, it
Yeah, it's a really good idea to combine the K8S with Camel.
In my mind if we want to host a camel application on the cloud, it could
be first step that we can run the camel engine on demand in K8S.
So I really like the project idea *making Camel integrations first-class
citizens in Kubernetes,
Jeff Genender, I and James Carman long ago were tossing
around the idea of Ibex, it would have been a Scala based AKKA
eco system for putting in routes. You’d just say run in this namespace, conform
to these Actor roles and we compose the tree for you.
What you propose is a bit easier and more
I find it super +1 - If not only for your awesome narrative.
> On Jul 12, 2018, at 5:30 PM, Nicola Ferraro wrote:
>
> Hi Cameleers,
> it's now passed some time since I started thinking about a new project that
> we can begin here at Apache Camel, and I'd like to have your opinion.
>
> We've
Hi Cameleers,
it's now passed some time since I started thinking about a new project that
we can begin here at Apache Camel, and I'd like to have your opinion.
We've already been targeting cloud-native applications with Camel,
especially on top of Kubernetes, that is becoming "the standard" cloud
28 matches
Mail list logo