Convert to package format 2

[mikaelarguedas]

No description provided.

[DLu]

Honest question: since when is this a thing?

[mikaelarguedas]

Honest question: since when is this a thing?

I'm not sure if the question applies to format 2 or the fact of providing a reference to the schema in an xml header. So I'll try to answer both, keeping in mind that both preceded my involvement with ROS or xml parsers.

package format 2 has been introduced in 2013-2014 to provide a format more adapted to the catkin build system, some advantages being being less verbose than the first version by adding the <depend> tag to merge <build_depend>, <exec_depend> and <build_export_depend> into a single tag. Another is to aggregate every dependency type in the package.xml so that it's a single place to get all dependencies of a package, including <doc_depend> for example. The full definition of the format is available in REP140

xml schema : AFAIU it is recommended since 2001 to provide a formal definition in xsd format to allow to write/generate complete parsers for a specific xml format.
Embedding it in the xml file is not required given that catkin already has a knowledge of the format and a parser for it. However it provides a self contained description of the format so that a package.xml is machine-readable by any tool able to fetch and interpret an xml schema without requiring any external knowledge of ROS or its tools.
As of the "when" it looks like the xsd files for both formats have been added in 06/2016 to the REP and the download resources, but the notion has been around for a while in the xml world.

Hope this provides more context.

Note: I understand that this PR may conflict with numerous existing ones and may stay on hold for a bit.

[nuclearsandwich]

@ros-pull-request-builder retest this please.

[mikaelarguedas]

looks like CI is failing because base_local_planner declares a CATKIN_DEPENDS on message_generation. I fixed it in 0e941d8 but I'm not sure why this dependency is exported to downstream packages in the first place. If it's not a requirement I'm happy to update this PR accordingly

[mikaelarguedas]

@mikeferguson I just rebased this PR on latest lunar. I'm still unsure about #591 (comment), let me know if their is any change necessary

[mikeferguson]

I'm aiming to get one more thing in before this: #596 (which brings forward some of the same fixes you have here, but also fixes a number of CMake issues).

[mikeferguson]

Ok, I'm done totally destroying your pull request for a little while -- if you can rebase (and maybe there might be some fixups required?) we can get this in next.

[mikaelarguedas]

rebased and resolved conflict. CI has been interrupted a few times but looks promising so far

[mikeferguson]

Thanks! I'll do a new release into lunar in the morning