Hi Good to see more experiments, but as others have said in this mail thread, its too overwhelming to dive into and understand.
So what I can see is that the model is now more "coded" in velocity vm and xml xslt files, than what we had before with the java model classes with JAXB annotations. Also I fail to see how it would understand if we add a new EIP today - how would you go about doing that? I do like that if we can have a lighter XML parser that is stax based than JAXB. And also if we can generate the XML XSD without JAXB at all. And the meta-model that you link to is a XML file which seems like an aggregation of what we have today in camel-catalog in the various json files. As you are going on PTO for a while I think we should maybe keep this in mind that this work will not get completed or finished in the near future. We may consider getting the last other stuff done and get M5 out the door as the last milestone, and then close down on RC builds. Then this meta-model can maybe be introduced in "steps" for 3.1, 3.2 etc. to give it more time to be more stable and maintainable. 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 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
