Your point is really interesting. However, I think one of the main problem right now is that the metamodel information is spread in the whole source tree (some bits in camel-core, and lots in the various components). This leads to a lot of hacks and round trips in the build system (copying json files from various locations, etc...). Getting out of sync is already somehow a problem with dataformats and languages, where the XyzDefinition are mapped to the actual dataformat / language properties using introspection. This is even more the case in Camel 3 with the new endpoint DSL which basically does the same thing (though it was already done using uri parameters). I think if we have the metamodel from the beginning of the build, we should be able to validate that the properties do exist in the final java classes (components, endpoints, dataformats and languages).
The only way to have all the information from the java code and have a clean build would be to generate the DSL (java + xml) after all components / langauges / dataformats would have been built, i.e. build camel-core at the end, so that we could use the real java classes and use them. However, I'm not sure that this woud be a good idea, given the length of the build... Le jeu. 25 juil. 2019 à 11:11, Zoran Regvart <zo...@regvart.com> a écrit : > Hi Guillaume & Cameleers, > I like that there's an effort to make the code more maintainable. I do > however feel that the source of truth is best kept in the Java code, > and perhaps this new model can be generated from that. I understand > the need for having a single strictly typed source of truth. > > Could we have the flow somehow like Java -> (XML?) meta model -> code > generation of XML readers/writers and DSL? > > I have an inkling that we could even generate the meta model in Java > and code generate from there without the model being in XML format, we > are kinda, while awkwardly, doing it right now. > > I fear that unless we add more strict checking that if the XML meta > model is the source of truth that we'll easily diverge from the Java > code. For example, if we remove a property from the endpoint we need > tooling that'll fail the build if the meta model is not updated and > the property is removed there as well. > > > zoran > > 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
