Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags.

Surviving RosJava Workspaces (Catkin Style)

Overview

A typical workspace will look like (refer to anatomy of a rosjava package for more details):

~/myjava
  /src
    /rosjava_catkin_package_a
      /rosjava_gradle_subproject_a
      /rosjava_gradle_subproject_b
      /rosjava_gradle_subproject_c
    /rosjava_catkin_package_b
      /rosjava_gradle_subproject_d
      /rosjava_gradle_subproject_e
      /rosjava_gradle_subproject_f

Essentially we have two ways to attack the clean-build cycle - via catkin or gradle. Catkin handles the big picture, making sure your repositories all get managed in an intelligent way. Gradle is the workhorse which does the actual dirty work. C++ workspaces are similar - they use catkin - make to get things done. Unfortunately things aren't quite so smooth with catkin and gradle, but it's pretty good now.

Cleaning Gradle Builds

It would be grand to be able to do the usual:

> cd ~/myjava/build
> make clean

to clean everything - however cmake doesn't give us access to the clean command. We do have however, a specially made target that will dig into each gradle project and clean it for you:

> cd ~/myjava/build
> make gradle-clean

Alternatively you can go through each project one by one and gradle clean them:

> source ~/myjava/devel/setup.bash
> cd ~/myjava/src/rosjava_catkin_package_a
> ./gradlew clean
> cd ~/myjava/src/rosjava_catkin_package_b
> ./gradlew clean

ToCatkin or ToGradle?

Once you've got a workspace compiled, you can then continue to compile your projects in one of two ways:

• Entire Workspaces: on the command line with catkin_make, but this takes ages!

• Individual Projects/Targets: source devel/setup.bash and work with the gradle wrappers at the root of each project/subproject, much faster.

Examples:

> source ~/myjava/devel/setup.bash
> cd ~/myjava/src/rosjava_catkin_package_a
# To build the default targets
> ./gradlew
# OR for specific targets, e.g. to build all artifacts
> ./gradlew clean
> ./gradlew publishMavenJavaPublicationToMavenRepository
# To build a specific subproject
> cd ~/myjava/src/rosjava_core/rosjava
> ./gradlew

Maven Artifacts

You will find all your maven artifacts get dumped in a local maven repository at ~/rosjava/devel/share/maven.

The best way of understanding the usefulness of both build commands is to understand their scope. In the above workspace, catkin_make has scope across the whole workspace - it is responsible for linking and sequencing each catkin package/gradle (super)project. The gradle wrapper on the other hand only has scope within a single catkin package.

When to Use Catkin Make

Catkin make is useful in the following situations:

• A first build of your entire workspace since it creates the setup.bash and is a one-shot way of building the entire workspace.
• Continuous integration builds.

If we didn't have catkin packages linking the gradle projects, you'd need to compile each by hand, one by one, or have a bash script to do so for you.

When to Use the Gradle Wrapper

You can use catkin_make exclusively, but that can be annoyingly slow as it's running through the entire workspace. Just as for c++ catkin builds (where you use make), you can drop down a level and directly use the gradle wrapper to compile single gradle projects, or even subprojects.

Compiling a binary app subproject:

> source devel/setup.bash
> cd src/rosjava_catkin_package_a/my_pub_sub_tutorial
> ../gradlew installApp

Compiling a library subproject:

> source devel/setup.bash
> cd src/rosjava_catkin_package_a/my_java_library
> ../gradlew publishMavenJavaPublicationToMavenRepository