Upgrade to RAML Module Builder 33.2.x

@Kyle Felker

mod-inventory-storage generates abstract interfaces from it’s raml files, which means if you want to add/subtract arguments from endpoint CRUD methods, the RAML files must be changed. Otherwise you will get compilation errors, since the arguments in the interfaces and the methods that implement them do not match.

Sure, that is a trade off to the code generation approach RMB uses.

The problem with that is that files in the raml/raml-util subrepository refer to the language attribute, causing the module not to compile if the language attribute is removed from the raml files. So if I leave it, the module won’t compile. if I remove it, the module won’t compile.

I'm not sure I follow this. I think you are saying that if you change the code without changing the RAML or vice versa, then they get out of sync and the module won't compile.

What do I do?

As I understand it, the outcome of this thread, is that updating the raml-util sub-module is an optional step for upgrading.

I believe that means that the RAML files for the module also do not need to change (and hence, the language attribute does not need to be removed).

I think we should not update the raml-utils sub-module and that means that none of the rest of the upgrade notes apply either and the only change is to update the RMB version in the pom.xml.

Does that make sense?

@Marc Johnson

mod-inventory-storage generates abstract interfaces from it’s raml files, which means if you want to add/subtract arguments from endpoint CRUD methods, the RAML files must be changed. Otherwise you will get compilation errors, since the arguments in the interfaces and the methods that implement them do not match. The problem with that is that files in the raml/raml-util subrepository refer to the language attribute, causing the module not to compile if the language attribute is removed from the raml files. So if I leave it, the module won’t compile. if I remove it, the module won’t compile.

What do I do?