@dhood @wjwwood any chance you could give this PR a lookover?

The benefits include allowing users of RViz' API to transition away from the deprecated tf library, toward tf2, by utilizing a shared Buffer object.

As far as I can tell, with this implementation, the only downside is that there lacks an option to re-use a tf2_ros::Buffer passed in as an argument to the constructor, but I can add that if it is desired.

@wjwwood Can you please take a look at this since it is necessary for the migration of MoveIt to tf2. Thanks.

you are right that this will break ABI and will need to target melodic.

the downside that I see is that we now have duplicated the listener effort for TF, which is a shame since the tf1 listener is actually using a tf2 buffer underneath. I know you had worked to expose it in #1215 (comment); did you consider that approach here already?

@dhood I agree that reusing the tf listener would be ideal, but the underlying tf2_ros::Buffer object is not designed to be accessible outside of inheretance.
I ran into slicing issues in attempting to retrieve the pre-alocated & protected tf_buffer object and maintain its access inside a shared pointer, without it being deleted from underneath the shared_ptr and causing a coredump. In the end, I figure the best solution is probably the simplest (implemented in this PR) even if it is not the most efficient. However, I am open to recommendations on a better implementation (or pointers as to how my C++ foo is failing).

@wjwwood could you pitch in on this please if you get a chance? (and the split std::shared_ptr and boost::shared_ptr interface: maybe stick to boost for consistency in the API?)

Yeah, I was hoping to do it today. We'll see...

I'd really rather not have duplicated tf buffers. So I'm going to pursue why the subclass didn't work and/or adding a new method in tf that would give access to the underlying tf2::Buffer without subclassing.

#1215 (comment)

Closing since I believe this was worked around in ros/geometry#163. Please comment if that's not the case.

Thanks @wjwwood! I meant to close it myself. I believe this PR is unneeded due to the accessor method added to ros/geometry#163 Thanks for the reviews :)