[RAML to Code] Move Generation system used to generate Endpoints to a Templating Engine/ JCodeModel (Java Only)

[kurtpa]

Since we are already using Code Models in the project, it might be wiser to move to Code Model based generation, rather than templating for the improved engine

[aweisser]

Hi Kurt,

I just pushed a first stable version of the feature to my repo. Still have to do some code documentation but you can take a sneek preview if you want. ;)

The RamlGenerator.generateClassForRaml(..) method becomes obsolete. My idea is to use instances of com.phoenixnap.oss.ramlapisync.generation.rules.Rule instead. At the top level we have three rules that operates on top of a JCodeModel and a ApiControllerMetadata instance. These top level rules are plugged together out of more low level Rule instances, each one concerning another part of the generated artefact (e.g. package declaration, class declaration, class annotations, comments, method signatures, parameters ....).

I wrote a bunch of tests as well.

Finally I created a new maven parameter where the user can configure, which code generation rule should be used.

It should be easy for you to create completely new code generation rules to support older Spring-Versions or whatever.

Tell me what you think. I can also create a PR if you prefer.

br,

Armin

[kurtpa]

Hi Armin

Thanks for taking the time to move this project forward :)

I started looking at your code and i like the approach you took. My only comments would be to move some of the methods currently in the plugin to the parser so that the parser is self sufficient and can be used not through maven

From my understanding so far, it's going to be trivial to generate unit tests, rest clients ec just by adding rules to the system - correct?

br

Kurt

[aweisser]

Hi Kurt,

great to here that you like the approach. =)

It should indeed be very easy to setup new Ruleclasses and assemble other code generation variants (e.g. Rest-Clients). Unit tests for rules based on JCodeModelcan follow the exisiting unit tests I already wrote.

One could even use other code abstraction models than JCodeModel. The Ruleinterface is very generic.

The best way to find out if the approach is flexibel enough would be to create another code generation variant. You spoke about older Spring-Versions. Perhaps you should go ahead and write some of those.

I'm not sure what you mean with "move some of the methods from plugin to parser". Do you mean parts of the SpringMvcEndpointGeneratorMojo.generateEndpoints() stuff?

Cheers,

Armin

[kurtpa]

yes that's right: specifically maybe we can abstract away lines 130-142 into a method which offers to handle source generation.

I'll definitely try out writing a new rule. Shall you do a pull request and i'll put the code in a feature branch and code the new rules against it?

[aweisser]

Hey Kurt,

I just executed an extract method refactoring on those lines. Currently I'm not sure where to put the functionality. The RamlParser seems not the right place, because it would lack the single responsibility principle. In fact some of the main classes in parser module does. Perhaps I can do some refactorings here to clean up the code when I've time again.

Should I create a PR of the current version to master branch?

[kurtpa]

Thanks armin - re PR yes please :)

[kurtpa]

Ready to be released with 0.4.1. Massive Thanks to @aweisser