preserve ros maven deployment repository

[fmessmer]

includes #37
i.e. essentially this PR is about 4da3ba6

I was facing problems where my rosjava packages where part of a chained workspace, i.e.:
CMAKE_PREFIX_PATH something like wsA/devel:wsB/devel:/opt/ros/kinetic

my rosjava packages are located in wsB/src
if I catkin buildmy chain bottom-up and then finally source the top-most wsA/devel/setup.bash, ROS_MAVEN_DEPLOYMENT_REPOSITORY will be set to wsA/devel/share/maven

when re-compiling my rosjava packages in wsB, now some of them fail
(in particular the action message generation part)
they have been compiling successfully while ROS_MAVEN_DEPLOYMENT_REPOSITORY has been set to wsA/devel/share/maven

this commit preserves the the environment variable ROS_MAVEN_DEPLOYMENT_REPOSITORY if it has been set (by user or by the first rosjava_build_tools envhook) and the set value is part of CMAKE_PREFIX_PATH

did anybody experience a similar issue when using rosjava packages with chained workspaces?
I don't know what has been the intention behind alway setting ROS_MAVEN_DEPLOYMENT_REPOSITORY to the top-most workspace[0]

[fmessmer]

I more and more doubt the concept of having ROS_MAVEN_DEPLOYMENT_REPOSITORY environment variable actually works as promised

could someone help me understand how this is meant to be used?

[jubeira]

Hi @fmessmer,

I have vague memories of these situations failing 'randomly' in the past. I've always used rosjava from source, so basically my code is always a workspace on top of rosjava's.

If I'm not mistaken, ROS_MAVEN_DEPLOYMENT_REPOSITORY points the directory where the output artifacts should be dumped, but I'm not sure if it really has to do with the dependencies of a given project.

when re-compiling my rosjava packages in wsB, now some of them fail
(in particular the action message generation part)
they have been compiling successfully while ROS_MAVEN_DEPLOYMENT_REPOSITORY has been set to wsA/devel/share/maven

When I source the workspace with rosjava_build_tools and I run env | grep ros -i, I see a variable called ROS_MAVEN_PATH, which has the maven folder for the workspace I just built. Isn't that variable the one you need to find the dependencies properly?

[fmessmer]

I've always used rosjava from source, so basically my code is always a workspace on top of rosjava's.

I also use rosjava from source...it's part of my wsB
everything rosjava related is in wsB - both rosjava itself (rosjava_build_tools, genjava, rosjava_bootstrap,...) as well as my own maven/gradle packages using rosjava/rosjava_message_artifacts
there is no rosjava-related code in wsA at all...mainly application packages launching nodes from wsB

what is probably the problem is that, with wsB sourced, artifacts are dumped to wsB/devel/share/maven at first, but with sourcing the topmost workspace for my scenario, they will get dumped to wsA/devel/share/maven because the ROS_MAVEN_DEPLOYMENT_REPOSITORY has changed...and with that some of my packages seem to be failing due to unmet dependencies...

I know about ROS_MAVEN_PATH, and this environment variable is set correctly similar to CMAKE_PREFIX_PATH (i.e. it's reflecting the workspace chain accordingly)...but similarly, I am not completely sure where this variable is used...

I'm absolutely no gradle/maven expert, so I'm having a hard time getting all these things together

maybe a little bit about my context:
most of my packages using rosjava artifacts are pure maven projects where I have a pom.xml and I added a custom target to those packages' CMakeLists.txt to compile them via catkin build (i.e. python-catkin-tools:

add_custom_target(${PROJECT_NAME}_maven ALL
                  COMMAND cp -Rf ${CMAKE_CURRENT_SOURCE_DIR} ${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_SHARE_DESTINATION}/
                  COMMAND mvn -e -X -B -U clean install
                  WORKING_DIRECTORY ${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_SHARE_DESTINATION}/${PROJECT_NAME}
                  VERBATIM)

as can be seen, I also do this in devel/build space to be conform with the read-only source space.

[fmessmer]

I separated the relevant commit into a separate PR (independent from #37/#39)