Hi… I am going to try to convince you to think the other way around on this. I hear you that you already started a first attempt using Jackson, etc. I am not entirely sure what that means… did you define JSON Schema for the entities? Did you implement it using JAXRS, or some other Rest framework? Are you using JAXB with your Jackson defined classes (assuming you are not using JSONScheam2Pojo to generate Jackson pojos)?
There is a reason for me saying this. I see a lot of teams with already built APIs with Jackson/JSON annotations, JAXRS code, etc. I worked with a group that had a decently sized API already working, and it took me only a few days of time to reverse it into a full RAML defined API with JSON Schema… that I then used the RAML 2 JAXRS project to generate the Jackson pojos, JAXRS interfaces, and implementation of those interfaces. Literally, a few days time. The result… I now had a single source of truth set of files… with documentation in place, and able to generate docs, service code, DTOs (Pojos), and if I wanted, could use ABAO to mock the service, and more. The great thing is, it is now super easy to add some resources, regenerate everything without any of my code breaking except any existing resources I already implemented that I modified the API for (e.g. perhaps I change the method type from GET to POST or added a query parameter to the definition of a resource).
If you are fortunate enough to do this with RAML 1.0, things are even nicer. More modular, custom annotations, RAML Types (instead of JSON Schema), re-usability and more.
It is, however possible to continue down the path you are on… use JAXRS to RAML, once you get it configured and set up your source files correctly to utilize it, then generate HTML docs, etc. I just find that the code is a much more difficult place to define API documentation, examples, and otherwise use as the single source of truth for the API itself. I also find that other than developers, sharing/explaining/teaching the API is not as easy… you cant just share the RAML file and work with the API designer and modify the file and see the changes occur in real time. You have to modify code, update javadoc, then generate a RAML file, etc. To each their own I guess, but having done it both ways, I can atest that RAML first, then code/doc/artifact generation is easier to work with, faster to collaborate with and easier to manage as well.