Is there any way to use RAML specifications without Mule?


I am working on a full fledged java project which is in production. I wanted to implement REST webservices inside it and for that I chose RAML. After I created RAML specifications and added it in my project I had to add mule support also. And Mule bloated my application badly because of added transitive dependency by IVY. It increased my application’s startup time and memory footprint. I’ve debloated my application at some extent by excluding unwanted jars that were being added transitively, but still there are complications like if I have to add database connector in Mule then I have to add mule-module-db dependency in IVY and it will again download transitive dependencies, and again there will be manual work to exclude those dependencies. Is there any alternative to use RAML specifications with technology other than mule? Please share your ideas.


What do you mean you had to add Mule support and you added support to your project? What are you using?


I mean my project is not mule based, its java based. So, I had to add mule support by adding mule jars in my project. For doing so i used Apache Ivy that is a tool for dependency management.


hi @AnkushSharma, thanks again. What I mean is what tools do you use? I cannot recall to have used any Mule related jars before.


Hi @AnkushSharma,

RAML is a tool independent spec for web API . It describes your API for the implementation you are doing.
For your requirment If I understand it correctly, You want to use the RAML for an implementation other that using mule(Correct me if I am wrong.).
If that is the case then you could use the RAML for JAX-RS utlity to generate your backend implementation from the RAML you have created.

JAX-RS is mule independent purely based on java annotations. You can leverage it for your implementation.



Hi @christian_vogel, for your question about what tool do I use? I’ll explain you. If we use anypoint studio or eclipse with mule support to create a new mule application then it automatically add mule runtime server and all necessary jar. There is no need to add them in classpath of project manually. But when we need to use mule inside another technology based project e.g. JAVA based, then we have to add mule runtime server and other necessary jars manually, and for that we can use available building tools like maven and ivy. So thats kind of setup i’m using.


Hi @arubalac, yes I want to use RAML implementation other than in mule. And also i’ve looked into the RAML to JAX-RS utility and it worked at an extent for me. But still I was looking for more alternatives. Thanks.


As a technical writer, I’m writing my RAML specs in Atom with the RAML plugin. This is on my laptop. I’m trying to figure out a way to serve the resulting documentation from my RAML file internally so co-workers can test, etc. Not sure if I answered your question but it feels like we want the same thing.



@AnkushSharma Can you detail a bit what worked/didnt work for you with the RAML2JAXRS? Why are you looking for more alternatives?

I am also confused as to how you ended up adding Mulesoft specific libraries? From the projects page, the projects I have looked at or used do not have any direct ties to Mulesoft. What projects/libraries are you talking about that get inserted into your application and how are you doing that?


@justjacksonn everything worked just fine with RAML2JAXRS, but the thing is if I’m going to use JAX-RS i won’t be able to use features of RAML like version controlling, automatic flow generation using mule etc. I’ll have to do everything manually. RAML2JAXRS will only generate Classes and Interfaces using that RAML. Also if there is any change in my RAML file in future I’ll have to re run this tool and so this is an external tool, it will override already generated classes/interfaces, so to avoid this I’ll have to generate JAX-RS implementation from new RAML store it somewhere else. Then compare old and new classes/interfaces and copy paste things that were added newly. It will waste a lot of time. These are some of the concerns which are compelling me to find another alternative.


@justjacksonn and please read my query once again. I’ve described pretty much simply that how and why I ended up adding Mulesoft specific libraries. Thank you.


@AnkushSharma First…I read all the posts/replies here. I am still not clear at all how you pulled in Mulesoft libraries. Sorry, just doesnt make sense to me.

The RAML2JAXRS, which I use, has a couple helper classes but otherwise it generates interfaces for the actual JAXRS resources. It does generate the POJO JSON classes from json schema as well, but you would do that anyway. In other words, if you were to model in JSON Schema, and use JSONSchema2Pojo, every time you changed a schema, you would regenerate the files. You would NEVER modify those classes. Otherwise, what is the point of using the JSON Schema to act as your modeling single source of truth?

The same can be said for using RAML2JAXRS. It generates interfaces, thats it. You implement the interfaces in your own classes. If you add/change/etc the RAML file(s), it regenerates the interfaces. It doesnt overwrite any of your own class implementations of those. If anything, you should get instant notification if a change in RAML now breaks your implementation. For example, if I define a /users resource in RAML, I get an interface with something like @Path(“users”), @GET, etc. I then implement that interface, and fill in some code in the method, returning the response. If I add query parameters to the RAML file, regenerate the interfaces, what will typically happen is my IDE lets me know I need to implement the interface methods. If I use my auto generate feature, it adds a new empty stub method that would cause two methods with the same names, just different signatures to show up. Now ideally what I do since I know this is going to happen, is I update my existing method implementation of the interface method that has changed. Thats it. Done. No merging/diffing of code, no concern of losing any code I added. So I am unclear about your rerunning the tool and it overriding already generated classes? I am also unclear why there is concern to rerun the tool? If you are using this to design an API with the concept of API First and Single source of truth in mind, then yes, every time you do ANY API changes, you would do so via the RAML file and JSON Schemas, then run the tool to regenerate the code, and update your implementation locally. Run some tests, then push your changes to source control. You duplicate the exact same steps your nightly build process (or whatever you use to build/deploy to stage, qa, production, etc) would do. What am I missing? There is no compare old/new classes needed. I do this every day, and never take the steps you have said, so maybe you dont quite understand how to use the tooling to make it work for you? Happy to help if that is the case. Also, I put my stuff in Docker, so that the same process I use locally can run via a nightly process, exactly the same. That way I am assured that what we run for testing, production, etc is identical to the steps we take locally before we commit changes. Works very well.

Incidentally, this process is the reverse of wasting a lot of time. I have reduced my work load by a huge amount doing this RAML API First process. Plus, I pick up ALL the other benefits, such as immediate documentation of my changes, automated tests if I want, and far easier sharing/diffing capabilities by simply using the RAML file vs lots of different source files. With the right tooling, you can test/mock the service before you even write a line of code. A lot of that isnt quite in place yet, but it is all coming soon!


@AnkushSharma, I think we are a bit confused about what technologies or toolings you are using :wink:

Can you quickly list out what you are using for what purpose? With regards to your latest post, I am seeing that you are using Anypoint Studio + APIKit to stub out flows based on your RAML API definition. Am I right?