When we deploy the camel routes with the help camel-k into k8s, we
still need to leverage the camel-catalog to find out the dependencies.
Otherwise we need to specify the dependency by using command line
options for camel-k to create the project with right third party
dependencies.
I think the challenge part is how can we do it with the endpoint-dsl
without specifying the dependencies.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Jun 12, 2019 at 1:16 PM Guillaume Nodet <gno...@apache.org> wrote:
>
> Le mer. 12 juin 2019 à 02:37, Willem Jiang <willem.ji...@gmail.com> a
> écrit :
>
> > Hi Guillaume,
> >
> > The endpoint-dsl is really helpful for camel to verify the endpoint
> > setting in the compile time.
> > Now I just have a quick question about how does the camel runtime
> > detect the dependencies of camel route?
> > With the endpoint URI we could use the camel-catalog do this kind of
> > work, with the endpoint-dsl we need to figure out another way to do
> > it.
> >
>
> Are you talking about the fact that the blueprint namespace handler
> try to find all the component dependencies ? Or is there any other
> place in the code that does a similar thing ?
> For the blueprint, I agree that could be a problem, but in reality it
> should
> not because blueprint uses the XML DSL which is not supported by
> the endpoint DSL we're talking.
> If there is something else, I could make sure it works too. The endpoint
> builders are aware of the scheme, so we'd just need to add a getter
> so that it can be checked.
>
> Cheers,
> Guillaume
>
>
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Jun 12, 2019 at 5:37 AM Guillaume Nodet <gno...@apache.org> wrote:
> > >
> > > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <aldettin...@gmail.com> a
> > > écrit :
> > >
> > > > Hey Guillaume, nice feature indeed.
> > > > Just a detail when reading the example, I think one could be surprised
> > to
> > > > have x2 from/to at first glance, I mean:
> > > > from(fromFile(... and to(toFile(...
> > > >
> > > >
> > > I do agree. My original idea was to only use file(xxx), but one
> > constraint
> > > is to have a different type for consumers and producers because they have
> > > different options, so we can't use the same method name. So the current
> > > design is a fallback because I haven't found anything better, but I'm
> > open
> > > to suggestions ...
> > >
> > >
> > >
> > > > My 2 cents,
> > > > Alex
> > > >
> > > >
> > > >
> > > > On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gno...@apache.org>
> > wrote:
> > > >
> > > > > I think I'm done with a first usable pass at the endpoint DSL.
> > > > > I've removed the getters/setters, added 2 flavors of fluent methods
> > (one
> > > > > with the real java type, another one with a String to allow
> > references
> > > > and
> > > > > property placeholder processing), renamed the generated classes to
> > > > > XxxEndpointBuilder and cleaned things a bit.
> > > > > In order to access this API, one would create an EndpointRouteBuilder
> > > > > anonymous class instead of the usual RouteBuilder (see below). The
> > only
> > > > > difference is that it gives immediate access to the fromXxx() and
> > toXxx()
> > > > > methods that are generated as default methods on the interface, so
> > > > there's
> > > > > no need to import anything else.
> > > > > Please have a look and let me know what you think or if we see
> > anything
> > > > to
> > > > > improve.
> > > > >
> > > > > Cheers,
> > > > > Guillaume
> > > > >
> > > > > protected RouteBuilder createRouteBuilder() throws Exception {
> > > > > return new EndpointRouteBuilder() {
> > > > > @Override
> > > > > public void configure() throws Exception {
> > > > > from(fromFile(start).initialDelay(0).delay(10).move(done
> > +
> > > > > "/${file:name}"))
> > > > > .to(toMock("result"));
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > >
> > > > > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gno...@apache.org> a
> > > > écrit :
> > > > >
> > > > > > I just pushed a branch called "endpoint-dsl".
> > > > > >
> > > > > > My goal is to experiment with an auto-generated DSL for endpoints,
> > > > mainly
> > > > > > to have a complete and type-safe java DSL for endpoints instead of
> > > > using
> > > > > > URI containing all the parameters. Right now, it compiles but
> > isn't
> > > > > really
> > > > > > usable at a DSL.
> > > > > > I'll get back as soon as I have something which can actually be
> > used so
> > > > > > that we can discuss further various options.
> > > > > > My rough goal is to be able to write something like:
> > > > > >
> > > > > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > > > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > > > > .to(mock("result"))
> > > > > >
> > > > > > instead of
> > > > > >
> > > > > > from(
> > > > > >
> > > > >
> > > >
> > "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > > > > )
> > > > > > .to("mock:result")
> > > > > >
> > > > > > Stay tuned !
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> >
>
>
> --
> ------------------------
> Guillaume Nodet
