It should not be a problem, I've just pushed some changes which take care
about the endpoint dsl when retrieving the URI on the From/SendDefinition,
similar to what is used in the blueprint namespace handler.  From the uri,
you can safely extract the scheme and thus the endpoint.
If I'm missing something, please point me to the relevant code so that I
can add the missing bits.

Le mer. 12 juin 2019 à 15:38, Willem Jiang <[email protected]> a
écrit :

> 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 <[email protected]> wrote:
> >
> > Le mer. 12 juin 2019 à 02:37, Willem Jiang <[email protected]> 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 <[email protected]>
> wrote:
> > > >
> > > > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <[email protected]>
> 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 <[email protected]
> >
> > > 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 <[email protected]>
> 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
>


-- 
------------------------
Guillaume Nodet

Reply via email to