Project refactoring broke future gradle support

[tburny]

Hello everyone, I took a look into Gradle support with https://github.com/netfalo/gradle-raml-plugin as a working base. In v1 the springmvc-raml-plugin had a structure that allowed only to include the required parts as a dependency to the gradle plugin, whereas for v2 there is only the maven plugin as artifact.

Additionally due to renamings the code is not quite portable. In summary the refactoring of V2 as in the current state of the project architecturally breaks gradle support for the near future, as

• the generation code is in the Maven Mojo and is tightly coupled to that
• the plugin jar is tightly coupled to the Maven infrastructure
• the plugin has a direct dependency on maven an lots of other classes
• there does not seem to be an easy way to use other "drivers", such as a command line interface, instead of Maven

I understand that this is still work in progress (as in https://github.com/phoenixnap/springmvc-raml-plugin/projects/1), so maybe we can adjust the whole thing a little?

I would like to suggest something along the lines of

• springmvc-raml as a technology platform for RAML <-> code, RAML validation and Documentation generation
• springmvc-raml-plugin as the maven plugin that drives the platform (and does nothing more)
• springmvc-raml-gradle as the gradle equivalent that also drives the very same platform

Figuratively speaking springmvc-raml would be the car and there are different kinds of drivers (such as Maven, Gradle, Ant(?!), Integration tests or a simple console application).

Otherwise I think the Maven Plugin is great and stands for itself, so thanks a lot for all the time and effort! :)

[stojsavljevic]

Hi,

Thanks for reaching us.

Gradle support would be great addition to this project. IIRC, the main problem with 2.0 is that is distributed as single jar tightly coupled with maven. So splitting project in two modules where one contains main parsing logic without being dependent on maven would help.

Is that correct?

[tburny]

Basically, yes. There is also lot of code thats currently in the Maven Mojo itself which could probably be refactored into a common foundation. Currently the Mojo is the main entry point as far as I can see, we need to change that so that the mojo is one entry point of many and they all delegate to a common base.

My main goal is the RAML 1.0 -> Java Path (which is not supported by https://github.com/netfalo/gradle-raml-plugin yet). I would help porting the plugin's code to the RAML Plugin 2.0 "core" and add the RAML to Code path.

[stojsavljevic]

I will start refactoring master branch as soon as I find some time.

I would help porting the plugin's code to the RAML Plugin 2.0 "core" and add the RAML to Code path.

Yes please. RAML to Code path is the only one supported in 2.0 and will probably stay like that.

[stojsavljevic]

Relates to #65

[tburny]

Do you think it is possible to allow customized code generation? Architecturally speaking I'm thinking about a more general framework for transforming RAML into Java Code, where the Models, Controllers and Interfaces are just three implementations (but more are easily possible).

Also it would be great to apply the plugin repeatedly with a set of generation rules (Models, Controllers, Clients) :)

[tburny]

I spent a few hours trying to split apart the Maven stuff from the generation stuff (still work in progress), here is what I found so far:

• A root project that contains a core and a maven module is doable, but not with lots of compiler errors because of the tight coupling to the configuration and many other methods
• There are dependencies to utility methods of the spring framework everywhere (StrinUtils.hasText() etc.)
• Config is a kind of global object that is used almost everywhere. Because the properties in Config are static, there are some indirect immediate dependencies with classes that are mostly unrelated.
• JCodeModel is the same, probably due to its nature
• Naming is done in a hell of utility classes, violating the single responsibility principle.
• Configuration and Naming is tightly coupled, naming is directly built-in the generation code, so Configuration and code generation are closer than they have to be
• There is a lot of "if-elseif-elseif-else"-code, which makes it kind of hard to read
• The Mojo Code itself is Spaghetti
• Can we use somthing like https://google.github.io/dagger/ for dependency injection?

Not that I meant this as a "everything is bad" thing, there has been a lot of great work by many people which is really amazing! I just wanted to point out that it won't be an easy thing to do.

I think that the rule approach is quite powerful and - if one understands it - allows writing new generation rules easily. Progressing further, I changed the rules so that instead of asking the configuration, they are told via constructor parameters. This still leaves a gap between rule parameters and the global configuration, which I currently solved by introducing factories that know the configuration and that can create preconfigured rules using that (blending in more parameters).

[tburny]

@stojsavljevic I did a first shot, basically I refactored the configuration quite a lot (and its still quite dirty) and split up the project.

[tburny]

I updated my fork as requested :)