RAML generator


#1

Hi there,

I’m just wondering what the future roadmap for client generation might look like. There is the raml-javascript-generator which depends on the raml-generator. The last tool has been inactive since half a year. And it’s initiator seems to have no access anymore. And then there is the raml-java-client-generator. Written in pure java.

When I take a look at the swagger community, there is only one tool chain for generating clients. And this is using Java. As I spend a lot of time building a generator for PHP I would really like to know which tool chain will be the one supported in the future. If the future tool chain will be javascript I would like to see some traction at the related tools. Cause it’s very annoying to be dependent on a raml-generator using a really outdated raml-parser (using 0.10.x, actual version: 1.14).


#2

I mentioned this in another thread, but I’m underway on a Go based RAML 1.0 tool here: https://github.com/mattbaird/RAMbLOn

I’m making good progress, not quite 100% on the parser yet.


#3

Really the client (and any generator) is expected to be done by the community. Mulesoft as far as I know is helping with some of it, besides the RAML spec, this site, and other things, they have some people dedicated to RAML that I know of. If you think of what Swagger has done… most of their stuff is all community contributed. The problem with waiting on the community is everyone has different ideas of how a generator should be implemented, and what it should produce. There is no one project that aims to generate all the SDKs, CLIs, documentation, tests, etc. Even if there was, given the community process, it would probably still require quite some time to get groups of people to meet/chat/email one another and come to some agreement on the direction of the generated output, language to write it in, etc. For a spec like RAML or Swagger, thats a pretty big undertaking.

Having said that, while I am largely a Java (and like to think NodeJS) developer, I really really like the idea of using Golang as the primary generator project. That it compiles on any platform and for any platform, native code, and is from what I have been told and reading up on a kind of uber language of Java, NodeJS, C and C#, it just seems to have all the right elements to produce a solid RAML to ?? generator. To that end, I think Matthews project is very promising. I have asked that he is able to break out the parser to its own project at some point, and if I was confident with Go and able to help, I would love to dive in on his project right now. So take a look at his tool, and see if you can maybe help with that.

Another good project is the RAML2HTML. It is almost 1.0 capable… although it is a doc generator. Me personally… I would love to see a single tool, specifically Mathews toold, become the standard tool that we build generators off of… and that includes doc generators, language generators, etc. This would fit well with my idea (that I responded to here (http://forums.raml.org/t/back-end-behaviors-where-to-describe-specifiy/1615/3) in having a way to provide a common set of annotations that generators would all agree (or try to agree) to support. Things like deprecation, HATEOAS, and more wild ideas could be handled in one tool (at least parsing) in a manner that add on generators could take advantage of more easily.

What I would REALLY like to see though, is some sort of consortium/community agreement on the direction of generators. The problem I have with the central Swagger generator is it is a crap shoot of whoever decides to work on it… and every generator has different output capabilities. Some support the full spec, some a subset of it, some dont work well with parts of the spec, some ignore things in the spec they shouldnt. Most seem to be one off developed projects out of some need, that often seem to eventually lack support and/or continued improvement and fixes. And somehow, companies seem to jump on board with this idea of using Swagger because they have all these code generators they can provide SDKs and such with. No thank you. Give me a set of generators that put out good code in different languages that are all at the same completion level. Same with documentation output, tests, etc.

Anywho… I do hope to see @Matthew_Baird project become the primary way in which we generate SDKs, CLIs, docs, etc in the near future and more people will jump on board to help him with that.


#4

I can just backup what @Kevin_Duffey already said; it would be very cool to see one single project that uses a template-like approach to generate all sorts of things. @Matthew_Baird is definitely going in the right direction, and there are also some NodeJS approaches, but the community needs to come together and we all need to contribute. If there is one project where we only have to provide templates, that would make a lot easier.

@Matthew_Baird could your project be used for something like that? So it has a main project that generates the object for the templates (not sure if there is something like handlebars and such for Go) where people could add their own templates?


#5

Additionally, if we go for handlebars or another standard; these templates can be reused for other languages or projects.


#6

Yeah. I also don’t mind whatever language it will be. When I started, there was the NodeJS client generator. Which was also using handlebars templates. Half a year later it’s now using typescript. Personally i liked the handlebars approach better. But for additional features the Typescript approach can be easier extended. When I find some time I may have a look at the Go-Tooling


#7

I saw your PR on the raml-generator project which is the foundation for the handlebars / template-like generator approach. Still need to review your last response though :stuck_out_tongue: