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
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)
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
