On Wed, Feb 24, 2021 at 5:08 PM Luca Burgazzoli <lburgazz...@gmail.com> wrote:
>
> I've opened an PR with some initial code [1] and it is failing for a
> circular dependency as the DSL need the camel-catalog to support a sort of
> EndpointDSL for YAML which allow to write something like:
>
> - from:
> direct:
> name: "start"
> steps:
> - telegram:
> type: bots
> token: {{auth-token}}
>
> So I wonder if we should bring the DSL as part of the code modules so it
> can run after camel-allcomponents.
>
Yeah that is a good idea. The light XML is already there (which we
could rename to camel-xml-dsl instead of camel-xml-io)
And if/when the core folder gets "too crowded" we can move some of
them into a core-extra folder.
> [1] https://github.com/apache/camel/pull/5119
>
> ---
> Luca Burgazzoli
>
>
> On Wed, Feb 24, 2021 at 9:42 AM Luca Burgazzoli <lburgazz...@gmail.com>
> wrote:
>
> > On Wed, Feb 24, 2021 at 9:33 AM Claus Ibsen <claus.ib...@gmail.com> wrote:
> >
> >> Hi
> >>
> >> Dont you have a "problem" with the flow style that you can't "end" the
> >> split and do something after it
> >>
> >> For example having a split in the middle, where a and b are outside
> >> the splitter then you can do in Java as
> >>
> >> from x
> >> to a
> >> split
> >> to sub 1
> >> to sub 2
> >> end
> >> to b
> >>
> >
> > Yes absolutely and that's why I have not re-implemented it.
> > It also make the json schema validation a little weak as you cannot mark
> > steps as required.
> >
> > Just for reference, this feature is an inheritance of the first
> > implementation of the DSL that was without branches so just a linear
> > sequence of steps and assumed that as example, you just want to deal with
> > the individual items that are the result of the split.
> >
> >
> >> And this is a bit "tricky" for new users to Camel DSL to learn.
> >>
> >> So I think maybe it's okay to not have the flow and keep the yaml dsl
> >> as-is (although it can be verbose with those nested steps)
> >>
> >>
> > Fine with me and if we'll find that having something like this in the
> > future, we may introduce a dedicated "flow" definition.
> >
> >
> >>
> >> On Wed, Feb 24, 2021 at 9:16 AM Luca Burgazzoli <lburgazz...@gmail.com>
> >> wrote:
> >> >
> >> > Additional question: should we support "flow" like route definition ?
> >> > To give an example of what a "flow" is, here a simple route that split
> >> and
> >> > process each item individually:
> >> >
> >> > - from:
> >> > uri: "direct:route"
> >> > steps:
> >> > - split:
> >> > tokenize: ","
> >> > steps:
> >> > - to: "mock:split"
> >> >
> >> > A "flow" variant would be:
> >> >
> >> > - from:
> >> > uri: "direct:route"
> >> > steps:
> >> > - split:
> >> > tokenize: ","
> >> > - to: "mock:split"
> >> >
> >> > So in essence, if steps are not explicit configured on an OutputNode (in
> >> > this case "split"), then such processor is the one to which each
> >> subsequent
> >> > steps is attached. This helps to mimics the Java DSL but at the same
> >> time,
> >> > it may be confusing so the new YAML DSL does not support this pattern
> >> out
> >> > of the box: should I enable it ?
> >> >
> >> > ---
> >> > Luca Burgazzoli
> >> >
> >> >
> >> > On Wed, Feb 24, 2021 at 7:09 AM Claus Ibsen <claus.ib...@gmail.com>
> >> wrote:
> >> >
> >> > > Hi Luca
> >> > >
> >> > >
> >> > > On Tue, Feb 23, 2021 at 8:16 PM Luca Burgazzoli <
> >> lburgazz...@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > Hi,
> >> > > >
> >> > > > over the past weeks I've worked to clean up the YAML DSL I've
> >> created for
> >> > > > camel-k [1] which ended up in a complete rewrite [2].
> >> > > >
> >> > > > The new implementation is in large part auto generated out of the
> >> camel
> >> > > > model (with some minor manual adjustments), it does not use
> >> reflection,
> >> > > it is
> >> > > > based on the SnakeYAML Engine [3] and it includes a much simpler
> >> > > generator
> >> > > > for the JSON schema as all the information are attached to the
> >> generated
> >> > > > code.
> >> > > >
> >> > > > The engine behind the DSL is pretty much stable and there are some
> >> tasks
> >> > > > I'd still have to do but as they are pretty much internal and may
> >> require
> >> > > > some change to the Camel model, I'd like to merge my work on Camel
> >> as
> >> > > soon
> >> > > > as possible hence, I have some question about the process:
> >> > > >
> >> > >
> >> > > Yeah its great work and we should get it into Camel 3.9.
> >> > > This new DSL will also help us in the future to keep the DSL model
> >> > > more stable and useable for more languages.
> >> > >
> >> > >
> >> > > > - the engine leverages some new APIs from Java 11 (var is pretty
> >> useful
> >> > > for
> >> > > > code generation), I don't remember what was our plan to move Camel
> >> to
> >> > > Java
> >> > > > 11 so wonder if I need to migrate the code to Java 8 or if we'll
> >> move to
> >> > > > Java 11 soon
> >> > >
> >> > > Yes var is much greater for code generation. I hit roadblocks with the
> >> > > cimple code generator
> >> > > where using var would benefit greatly. And therefore the current
> >> > > implementation lacks some
> >> > > features that are in the regular simple language.
> >> > >
> >> > > About Java 11 then we have some components today that requires Java 11
> >> > > at runtime, like camel-joor.
> >> > > I am fine with the yaml dsl being Java 11 only. In the maven pom.xml
> >> > > we can make some way to skip this module if you use Java 8 compiler.
> >> > > And for releasing we can use Java 11 compiler with target 1.8 for all
> >> > > other modules, and then 1.11 for this module.
> >> > >
> >> > > > - the code generation is based on JavaPoet [4] and I have plans to
> >> > > migrate
> >> > > > to the camel own tool but since it does not affect the correctness
> >> of the
> >> > > > code, I think I could delay the migration to a later stage.
> >> > >
> >> > > Yeah that is okay as the code generator is a one process and part of
> >> > > building. the Camel project,
> >> > > and not for end users to run.
> >> > >
> >> > > > - I could make the YAML DSL part of a new camel-snakeyaml component
> >> but
> >> > > for
> >> > > > modularity, I wonder if we should introduce specific artifacts like
> >> > > > camel-dsl-yaml, camel-dsl-xml-io, etc.
> >> > > >
> >> > >
> >> > > Yes I would like to have this in its own module name.
> >> > > We use camel-endpointdsl and camel-componentdsl today, so it could
> >> > > also be named camel-yaml-dsl
> >> > >
> >> > >
> >> > >
> >> > > > Let me know,
> >> > > > Luca
> >> > > >
> >> > > > [1]
> >> > > >
> >> > >
> >> https://github.com/apache/camel-k-runtime/tree/master/camel-k-loader-yaml
> >> > > > [2] https://github.com/lburgazzoli/camel-yaml-dsl
> >> > > > [3] https://bitbucket.org/asomov/snakeyaml-engine/
> >> > > > [4] https://github.com/square/javapoet
> >> > > >
> >> > > >
> >> > > > ---
> >> > > > Luca Burgazzoli
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Claus Ibsen
> >> > > -----------------
> >> > > http://davsclaus.com @davsclaus
> >> > > Camel in Action 2: https://www.manning.com/ibsen2
> >> > >
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
> >
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
