Time to introduce a real templating engine.

How-to:

• Gather all the conventions we rely on in JVPP generator
• Check all the exceptions from util.py and consider them in new design (e.g. message reused as request and notification) or fix them in api file (e.g. unused message, or just violating conventions)
• Start developing the new generator with the old one still in place. Make sure to only replace the old one when new one is capable of generating same classes.
• Put vpp-core, vpp-registry, vpp-common to separate projects (ensure VPP-452 is addressed).
• Include requirements from other jvpp related tasks in the design (especially VPP-120).
• Guidlines for new generator:
  • Use a real templating engine
  • First parse input into a multimap(because one request can get multiple responses, responses can be reused etc. basically there's no 1-1 mapping, but N-N mapping has to be considered ...for reused structures we might have to update the APIs of JVPP or use artificial naming suffixes for reused cases... ) where request->reply, dump->details, triggers->notifications are mapped. This allows for easier handling of non-conventional mappings from vpe.api. So this should be created from vpe.api + conventions + exceptions defined externally from the script.
  • Then for each structure create 1 or more metadata object
  • Then push the metadata into 1 or more generators based on the metadata object type (request, reply, dumpRequest, dumpReply, notification, notificationTrigger(maybe same as request))

Note1: Consider using Streams for dump replies instead of aggregated list in a future