First class ros message generator for Java

[stonier]

We're not far off being able to do this I think.

We'd just have to use the code in here (message_generation) and write our own gengava generator which dumps artifacts in xxx/share/maven.

Compare with genpy and gencpp.

[stonier]

ros/message_generation#1 (comment)

[stonier]

There are alot of ways we could do this, however it's important to note that rosjava has quite a few workflows that would be interesting to supoport. This constrains what is possible.

Standard Style

Create a genjava package that hooks into message_generation and genmsg to automatically build
artifacts along with cpp/python/lisp.

• Compared with genpy, gencpp, java requires a compile step, this will slow things down
  • It's not significant except when there is no gradle daemon being utilised.

Source Jars

Evolving the former method - instead of compiling the created .java files, just pack them into
a jar for later consumption by java packages. Lots of unanswered questions:

• Can we legitimately store these in an external maven repo?
• How do other gradle projects 'depend' on these jars
• How do other gradle projects 'compile' these jars
• Even if we can, there is multiplicity if every package that depends on a msg source jar has to separately compile them

On the Fly

Use the cmake to spin up an artifact for whatever version it finds on the ROS_PACKAGE_PATH.

• Defer to always spinning an artifact over getting from the external repo, even if the same version
  • With the time taken to check the repo, you may as well spin it locally
  • Remember also that often people have changes in the local version and only usually update the version before release.
• Scan package.xml for msg dependencies - this way you can automatically spin with no effort from the programmer

Q) The above makes sure msg artifacts are around for a source workspace, but...
who makes sure the msg artifacts are around for installed workspaces?

For example, rosjava_foo is a mixed java/python catkin package that needs std_msgs. If you install it's deb, you ultimately have no org.ros.rosjava_messages.std_msgs artifact on the system still. If you run something, it will be missing that artifact and probably(?) fail.

What if...(and this, i.e. post-install scripts might be damn complicated to make work in the ros world)

• The debs don't actually install the artifacts, instead they have a postscript which does a maven install
  • This would make sure any dependent artifacts are installed at the same time

Then source workspaces are guaranteed to spin them up on the fly and installed workspaces are guaranteed to have the dependency chains all satisfied and ready to run.

[stonier]

I actually have an installation of the former (genjava) running here for testing. Seems to work quite well with little lag so long as the gradle demon is used. Note that you have to include any and all msg packages in the rosjava workspace. I'm working on a script to autogenerate from an installed ROS_PACKAGE_PATH to make things a little more convenient, but this is ultimately what genjava should do.

[stonier]

Another topic to bring into this here is the idea of automatically updating the maven repo from a job on OSRF's build farm...

[stonier]

Am convinced that genjava is the right way to go.

1. Catkin feeds you exactly which messages are to be built and which are just lying around
2. Catkin also feeds you exactly the transitive dependencies each message needs
3. Rebuilds will occur on the fly whenever a single message is changed.

Any solution outside of this will either end up reinventing alot of this or doing alot of redundant processing/rebuilding outside of the loop.

[stonier]

The current genjava implementation uses message_generation's bulk generator - i.e. it builds messages at the package level (i.e. all messages for a package at once). Need to implement a function that does this file by file as it fits better with genxxx's workflows and also enables us to pick up transitive dependencies. Currently we can't pick up the transitives because our processing occurs at the module (i.e. package) level and the transitives are only passed at the file level.