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.
[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
>>
>
