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
>
