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 >
