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