You said the project just started… so it may not be too late to offer an alternative method of using RAML for not just documentation, but as your single source of truth. Rather than using JAX-RS to RAML, spin it around, use RAML to define the API first, with JSON Schema for the models (that turn in to Java POJOs and can be used as DTOs and backing models to entity beans). In this way, your front end API, documentation, even testing and mocking capabilities are all automated from your RAML API first design.
RAML 1.0 would be ideal, but I am not sure of the state of things with RAML 1.0 to JAXRS (or vice versa if you are stuck on going it that way). RAML 0.8 is well enough for most API scenarios, however, and the JAX-RS 2.x generated works quite well.
I could give a number of reasons why this path is better, but mostly they are my own experience and opinion. However, if you are building an application that is going to have an API, then the API becomes your contract to anyone consuming it. You can build SDKs from the RAML and JSON Schema files as well for many languages, but mostly, for me it is about using a single source of truth to build everything else from. From the API endpoint implementation, to the documentation, to testing and more. Postman, probably the best API testing product available, imports RAML as well, to some degree and with a bit more work, it is not difficult to quickly turn a RAML defined set of API endpoints in to a 1 to 1 API testing collection in Postman, that can then be used to quickly assemble tutorials and end to end API tests scenarios. All of which can be run using Newman with nightly builds (we do this now by spinning up our entire environment with docker containers and then running the automated Postman tests with Newman against the APIs).
Anyway, I have done projects both ways, and frankly trying to keep code in sync, with javadoc, and tests, etc… is much more difficult than starting from RAML (and JSON Schema) with documentation in the RAML files, than the way you are currently going about it.