Le jeu. 25 juil. 2019 à 20:28, Zoran Regvart <zo...@regvart.com> a écrit :
> Hi Guillaume, > since we're all piling up on you :) One more thing I'd like you to > consider :) > > I find Velocity templates a bit brittle and hard to maintain, would > you consider a Java code generator to create the Java source code? > Lol ! I usually find those harder to use for the use cases we have and when you want tight control over the written code. I'd rather move all the smart things into a helper class and keep velocity with almost only simple iterations on variables. You can compare the code used to generate the endpoint DSL: https://github.com/apache/camel/blob/master/tooling/maven/camel-package-maven-plugin/src/main/java/org/apache/camel/maven/packaging/EndpointDslMojo.java https://github.com/gnodet/camel/blob/model/core/camel-core/src/generator/resources/endpoint.vm If you really want the main executed code to be java, I'd rather use a simple java writer rather than a java code generator. That may be because of the way I'm working, but I usually work with the generated source code when I need to change something it, and when I'm happy, I'm changing the generator to reflect those changes, and this is usually way easier when you're working on a template which actually looks like the output. > > I've found JavaPoet[1] pretty nifty in this regard. I've used it for > the OpenAPI to Rest DSL code generator we have[2]. > > Thanks :) > > zoran > > [1] https://github.com/square/javapoet > [2] > https://github.com/apache/camel/tree/master/tooling/swagger-rest-dsl-generator/src/main/java/org/apache/camel/generator/swagger > > On Wed, Jul 24, 2019 at 4:45 PM Guillaume Nodet <gno...@apache.org> wrote: > > > > Hey everyone ! > > > > The last weeks, I've spend quite some time working on a camel metamodel. > > The idea is to invert the way things are built in camel so instead of > > generating the metamodel from the classes, the metamodel would be > > maintained manually and used to generate a bunch of things. > > > > This would bring the following benefits: > > - the metamodel would necessarily be up to date > > - generate the model classes (XyzDefinition classes) with an > homogeneous > > fluent api (similar to the new endpoint DSL) > > - get rid of some round tripping between java -> json -> java, copying > > json files everywhere , so great simplification of the build process > > - the DSL allows type-safe + property placeholders / references > everywhere > > - generate xml readers / parsers without relying on JAXB > > - brings extensibility of the DSL as it would be much easier to create > > DSLs based on other languages from the metamodel (yaml for example) > > > > I've pushed a branch that shows my experiments. It's not fully working > > yet, but it gives a good idea. It's available at > > https://github.com/gnodet/camel/tree/model > > I'm progressing a bit slowly as there are lots of step by step > adjustements > > to do in order to keep compatibility of the DSL. > > > > Currently the model is generated from the json files, but the idea is to > > reverse this process and have the metamodel the real primary input for > all > > generation. > > The model currently looks like: > > https://gist.github.com/gnodet/75457febcca9a893c3c1a2b8499189b2 > > > > The current JAXB model will need to be moved into a separate module so > that > > it can be kept for compatibility without interfering with the new > generated > > java DSL. > > > > So, still quite some work left, but I wanted to bring it to the community > > sooner rather than later, especially before I go on PTO for a few weeks > > where I'll be mostly offline. > > Happy to discuss anything or provide more infos. > > > > Cheers, > > Guillaume Nodet > > > > -- > Zoran Regvart > -- ------------------------ Guillaume Nodet
