[Rock-dev] Reorg of modelling-related packages

[Sylvain Joyeux]

In the course of the last two years, I've grown extremely frustrated
with the way Ruby code is distributed within rock-core packages.

As an example, let's look at the transformer:

 drivers/transformer is the *implementation* of a transformer-like
functionality in C++
 drivers/orogen/transformer/rock/transformer.rb is the orogen plugin
that gives access to drivers/transformer in oroGen
 drivers/transformer/ruby implements a *model* of a transformer tree
in Ruby, which has no relationship whatsoever with the C++ library
(apart from the name)
 drivers/transformer/ruby/syskit is both a generic implementation of
frame annotations in a component network *and* the runtime setup of
oroGen components that use the transformer orogen plugin

What I'd like to do first and foremost is split the ruby code out of
the C++ library. This would make the development cycle in Ruby that
much more streamlined (documentation, gemification & tests)

Moreover, I'd like to split the ruby "framework-free" library from the
Syskit and oroGen bits. I've wanted to do the same for typelib and
oroGen at some point, and was thinking about getting all the
"modelling" bits under the modelkit- umbrella, the component-level
runtime bits under the runkit- umbrella and then orogen- and syskit-,
e.g.

  tools/modelkit-transformer: what's currently the non-syskit bits of
drivers/transformer/ruby
  tools/syskit-transformer: drivers/transformer/ruby/syskit/*
  tools/orogen-transformer: the transformer/orogen plugin

This would give me a frame into which the Gazebo integration (which
follows the same kind of mess than the transformer) could be finally
organized:

  tools/modelkit-sdf: modelling related to SDF (orogen modelling of a
Gazebo instance, SDF loader for the transformer)
  tools/runkit-sdf: loading a SDF file into a vizkit3d instance,
optionally linking to a running Gazebo instance.
  tools/syskit-sdf: using SDF to auto-configure a system in Syskit,
integration of Gazebo in Syskit.

While the namespaces would change, getting backward-compatible aliases
won't be a big deal since the code/APIs won't change (at least, not
right away)

I'm open for better ideas. It does split the code in smaller units -
against which there was a strong feeling at the origin of Rock - but
I've seen that explaining where is everything is REALLY hard right
now, simply because loosely-related things ended up being bundled
together.

Sylvain