On Wed, Jul 25, 2012 at 5:16 AM, Thibault Kruse <kruset@in.tum.de> wrote:
> On 07/25/2012 06:07 AM, Jack O'Quin wrote:
>>
>> Your proposal implies that every single program must be modified in Groovy
>> to use common_msgs/LaserScan, instead. Surely that is not your intent.
>
> The proposal of Dirk is only that the installed
> sensor_msgs/msg/LaserScan.msg file goes into
>
> .../share/common_msgs/.../LaserScan.msg
>
> If another message file uses sensor_msgs/LaserScan, then the
> lookup should be able to find the file in
> .../share/common_msgs/.../LaserScan.msg
>
> There are several ways in which that can be achieved, these alternatives
> should be collected and then weighted according to different use cases
> to chose the most suitable one.

Agreed.

Unfortunately, we are almost out of time for Groovy. Primary feature
freeze is three weeks away. (This is a "primary" feature if ever there
was one.)

Perhaps some of this can be postponed until Hydro, but Fuerte
introduced several serious build problems that really must get fixed
in Groovy.

> One reason for all this could be that a stack as a unit of release
> should not pollute the target installation more than necessary,
> such that the trees it creates in bin/ lib/ share/ etc. have a
> small namespace footprint.

Namespace management is a good point.

But, that suggests using package names and not stack names. Stack
names frequently change from one release to the next. Package names
are more permanent and much more important.
-- 
 joq