On Thu, Jul 25, 2019 at 11:28 AM Guillaume Nodet <gno...@apache.org> wrote: > > Le jeu. 25 juil. 2019 à 10:47, Claus Ibsen <claus.ib...@gmail.com> a écrit : > > > Hi > > > > Good to see more experiments, but as others have said in this mail > > thread, its too overwhelming to dive into and understand. > > > > Yes, I definitely get that, especially as it's still work in progress. > > On the java dsl side, the goal is to be 100% compatible, i.e. i'm trying to > generate the DSL without changing all the tests in camel-core. > However, this opens new possibilities, mainly about having a consistent way > to inject references and use property placeholders, especially in places > where this was not possible. >
Ah okay so you are doing the same generating as endpoint dsl, where an option that is eg a integer, you generate a builder for both - integer - string Where the latter can be used for property placeholders. > > > > 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. > Okay so with these vm and xslt files then they seem a bit hardcore. I am a little worried how we can maintain this. But I can see they do the "hard" work of code generating from the metamodel. > > > > Also I fail to see how it would understand if we add a new EIP today - > > how would you go about doing that? > > > > So if the xml metamodel becomes the real input (see below), then the > developer would have to modify the metamodel to add an element to it (a > processor, language, dataformat, or maybe a property on an existing > element). > You'd build the camel-metamodel, then build camel-core which re-generates > all the data structures. At this point, the property will be added to the > java code, so the next step is to actually create or modify the reifier and > the runtime bits to actually use it. > Okay that is a fairly easy process. > > > > > 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. > > > > Yes. > > > > 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. > > > > Yes, though this is temporary in my mind. I think the main input should > be the xml metamodel which would be "manually" maintained. From this file, > we should generate everything that we need, including the json files for > the catalog. > Ah okay so we have this single xml file. Well frankly this file seems reasonable straightforward to understand and edit. The only point is that for endpoints such jms etc, that has many options and whatnot. Then we have a build tool that generate and update the XML file with all these endpoints? And the same for components, eg we have component level options also. And speaking of that, we may also consider a fluent builder DSL for that too - like we have for endpoint DSL. > > > 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 > > > > > -- > ------------------------ > Guillaume Nodet -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
