| Note: This tutorial assumes that you have completed the previous tutorials: Anatomy of a RosJava Package, Creating Rosjava Packages. |
 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)
Description: Useful tips on how to survive in a catkin-gradle based rosjava workspace.Keywords: rosjava
Tutorial Level: BEGINNER
This tutorial outlines some useful hints on how to surive the catkin-gradle rosjava experience - cleaning, cmake vs gradle, and others. |
Contents
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_fEssentially 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?
The best way of understanding the usefulness of both build styles is to understand their scope. The first tool, 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 : use for a first/one-shot build of the entire workspace. |
catkin_make : use for continuous integration builds. |
catkin_make : is slow! |
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
gradle : use when working on a single project/subproject. |
Compiling a gradle (multi-)project:
> source ~/myjava/devel/setup.bash > cd ~/myjava/src/rosjava_catkin_package_a # Execute the default task(s) > ./gradlew
Compiling a binary app subproject:
> source ~/myjava/devel/setup.bash > cd ~/myjava/src/rosjava_catkin_package_a/my_pub_sub_tutorial > ../gradlew installApp
Compiling a library subproject:
> source ~/myjava/devel/setup.bash > cd ~/myjava/src/rosjava_catkin_package_a/my_java_library > ../gradlew publishMavenJavaPublicationToMavenRepository
Maven Artifacts
You will find all your maven artifacts get dumped in a local maven repository at ~/rosjava/devel/share/maven.
