problem with importing OCL components
| Submitted by dominick.vanthienen on Tue, 2011-01-11 10:56 |
Dear all,
I'm trying to run a program with the deployer.
One of the components he should create, is a OCL::FileReporting component.
Therefor I did:
*include ocl in manifest (ROS way)
*import ocl in deployer.xml
=>ERROR:
0.213 [ Debug ][DeploymentComponent::import] OCL should be loaded by
default in ROS package trees. No need to import it.
0.213 [ Info ][DeploymentComponent::import] Component package 'ocl'
already imported.
...
0.319 [ Debug ][DeploymentComponent::loadComponent] Trying to create
component Reporter of type OCL::FileReporting
0.319 [ ERROR ][DeploymentComponent::loadComponent] Unable to create
Orocos Component 'OCL::FileReporting': unknown component type.
=>He doesn't recognize this component (because he didn't import OCL)?
!
When I add the path of OCL to RTT_COMPONENT_PATH, the problem is solved,
but I thought that this was 'obsolete'?
Nick
problem with importing OCL components
On Tuesday 11 January 2011 11:53:23 Dominick Vanthienen wrote:
> Dear all,
>
> I'm trying to run a program with the deployer.
> One of the components he should create, is a OCL::FileReporting component.
> Therefor I did:
> *include ocl in manifest (ROS way)
> *import ocl in deployer.xml
> =>ERROR:
> 0.213 [ Debug ][DeploymentComponent::import] OCL should be loaded by
> default in ROS package trees. No need to import it.
> 0.213 [ Info ][DeploymentComponent::import] Component package 'ocl'
> already imported.
> ...
> 0.319 [ Debug ][DeploymentComponent::loadComponent] Trying to create
> component Reporter of type OCL::FileReporting
> 0.319 [ ERROR ][DeploymentComponent::loadComponent] Unable to create
> Orocos Component 'OCL::FileReporting': unknown component type.
> =>He doesn't recognize this component (because he didn't import OCL)?
> !
> When I add the path of OCL to RTT_COMPONENT_PATH, the problem is solved,
> but I thought that this was 'obsolete'?
We need to resolve this. It's caused by your definition of the
RTT_COMPONENT_PATH, hence overriding the automatic import of ocl components.
We should check if ocl was *really* loaded instead of assuming it always is.
I'll take a look at it again, I know it's not obvious for some reason. Your
work around is indeed to include ocl for now in the RTT_COMPONENT_PATH.
Peter
problem with importing OCL components
On Tuesday 11 January 2011 13:42:23 Peter Soetens wrote:
> On Tuesday 11 January 2011 11:53:23 Dominick Vanthienen wrote:
> > Dear all,
> >
> > I'm trying to run a program with the deployer.
> > One of the components he should create, is a OCL::FileReporting
> > component. Therefor I did:
> > *include ocl in manifest (ROS way)
> > *import ocl in deployer.xml
> > =>ERROR:
> > 0.213 [ Debug ][DeploymentComponent::import] OCL should be loaded by
> > default in ROS package trees. No need to import it.
> > 0.213 [ Info ][DeploymentComponent::import] Component package 'ocl'
> > already imported.
> > ...
> > 0.319 [ Debug ][DeploymentComponent::loadComponent] Trying to create
> > component Reporter of type OCL::FileReporting
> > 0.319 [ ERROR ][DeploymentComponent::loadComponent] Unable to create
> > Orocos Component 'OCL::FileReporting': unknown component type.
> > =>He doesn't recognize this component (because he didn't import OCL)?
> > !
> > When I add the path of OCL to RTT_COMPONENT_PATH, the problem is solved,
> > but I thought that this was 'obsolete'?
>
> We need to resolve this. It's caused by your definition of the
> RTT_COMPONENT_PATH, hence overriding the automatic import of ocl
> components. We should check if ocl was *really* loaded instead of assuming
> it always is.
>
> I'll take a look at it again, I know it's not obvious for some reason. Your
> work around is indeed to include ocl for now in the RTT_COMPONENT_PATH.
Why did you set RTT_COMPONENT_PATH in the first place ? In ros systems,
this variable is not useful, unless some non-ros package is to be imported.
I have a fix I can push to the toolchain-2.2 branch which checks that when
the user imports ("ocl"), and the "OCLTypekit" is not yet present, it will proceed
with the import, instead of the complaints you see above.
commit fb1f4045aaa24711c58f64ee0e24bb03df5802c4
Author: Peter Soetens <peter [..] ...>
Date: Tue Jan 11 14:04:22 2011 +0100
deployment: only report OCL as imported when its typekit was found
This works around the automatic loading of ocl without registering
it as an imported package.
Signed-off-by: Peter Soetens <peter [..] ...>
diff --git a/deployment/ComponentLoader.cpp b/deployment/ComponentLoader.cpp
index 2a69678..c225aaf 100644
--- a/deployment/ComponentLoader.cpp
+++ b/deployment/ComponentLoader.cpp
@@ -6,6 +6,7 @@
#include <rtt/Logger.hp
#include <boost/filesystem.hp
#include <rtt/plugin/PluginLoader.hp
+#include <rtt/types/TypekitRepository.hp
#ifdef HAS_ROSLIB
#include <ros/package.h>
@@ -322,14 +323,11 @@ bool ComponentLoader::isImported(string type_name)
return true;
if (find(loadedPackages.begin(), loadedPackages.end(), type_name) != loadedPackages.end())
return true;
-#ifdef HAS_ROSLIB
- // hack: since ros works with package names, and ocl is imported by default (in configureHook())
- // we claim that the 'ocl' package is always imported."
- if ( type_name == "ocl") {
- log(Debug) <<"OCL should be loaded by default in ROS package trees. No need to import it." <<endlog();
+ // hack: in current versions, ocl is loaded most of the times by default because it does not reside in a package subdir
+ // once ocl is in the 'ocl' package directory, this code becomes obsolete:
+ if ( type_name == "ocl" && TypekitRepository::hasTypekit("OCLTypekit")) {
return true;
}
-#endif
return false;
}
Peter
>
problem with importing OCL components
...
> >
> > We need to resolve this. It's caused by your definition of the
> > RTT_COMPONENT_PATH, hence overriding the automatic import of ocl
> > components. We should check if ocl was *really* loaded instead of
> > assuming it always is.
> >
> > I'll take a look at it again, I know it's not obvious for some reason.
> > Your work around is indeed to include ocl for now in the
> > RTT_COMPONENT_PATH.
>
> Why did you set RTT_COMPONENT_PATH in the first place ? In ros systems,
> this variable is not useful, unless some non-ros package is to be imported.
Because this was the way to go before ....
So are we not supposed to use the RTT_COMPONENT_PATH anymore?
Tinne
problem with importing OCL components
On Tuesday 11 January 2011 14:20:20 Tinne De Laet wrote:
> ...
>
> > > We need to resolve this. It's caused by your definition of the
> > > RTT_COMPONENT_PATH, hence overriding the automatic import of ocl
> > > components. We should check if ocl was *really* loaded instead of
> > > assuming it always is.
> > >
> > > I'll take a look at it again, I know it's not obvious for some reason.
> > > Your work around is indeed to include ocl for now in the
> > > RTT_COMPONENT_PATH.
> >
> > Why did you set RTT_COMPONENT_PATH in the first place ? In ros systems,
> > this variable is not useful, unless some non-ros package is to be
> > imported.
>
> Because this was the way to go before ....
> So are we not supposed to use the RTT_COMPONENT_PATH anymore?
When everything you use is in a ros package and in your ROS_PACKAGE_PATH,
there's no need to set the RTT_COMPONENT_PATH. We will always use ROS to
locate the package and import the libraries from the lib/orocos directory in
your package.
Peter
problem with importing OCL components
On 01/11/2011 02:33 PM, Peter Soetens wrote:
> On Tuesday 11 January 2011 14:20:20 Tinne De Laet wrote:
>> ...
>>
>>>> We need to resolve this. It's caused by your definition of the
>>>> RTT_COMPONENT_PATH, hence overriding the automatic import of ocl
>>>> components. We should check if ocl was *really* loaded instead of
>>>> assuming it always is.
>>>>
>>>> I'll take a look at it again, I know it's not obvious for some reason.
>>>> Your work around is indeed to include ocl for now in the
>>>> RTT_COMPONENT_PATH.
>>> Why did you set RTT_COMPONENT_PATH in the first place ? In ros systems,
>>> this variable is not useful, unless some non-ros package is to be
>>> imported.
>> Because this was the way to go before ....
>> So are we not supposed to use the RTT_COMPONENT_PATH anymore?
> When everything you use is in a ros package and in your ROS_PACKAGE_PATH,
> there's no need to set the RTT_COMPONENT_PATH. We will always use ROS to
> locate the package and import the libraries from the lib/orocos directory in
> your package.
>
> Peter
I don't really understand how the setting of this ROS_PACKAGE_PATH can
influence the problem.
In my .bashrc I do (before the work around):
export
RTT_COMPONENT_PATH=$LUA_TYPEKIT_PATH:$RTT_TYPEKIT_PATH:$BFL_TYPEKIT_PATH:$RTT_COMPONENT_PATH;
So if there was something in the RTT component path, it should be still
there.
And I say nothing about OCL.
So if I have a non-ROS library, I will set the RTT component path in a
similar way, causing the same problem, no?
Nick
problem with importing OCL components
On Tuesday 11 January 2011 15:57:39 Dominick Vanthienen wrote:
> On 01/11/2011 02:33 PM, Peter Soetens wrote:
> > On Tuesday 11 January 2011 14:20:20 Tinne De Laet wrote:
> >> ...
> >>
> >>>> We need to resolve this. It's caused by your definition of the
> >>>> RTT_COMPONENT_PATH, hence overriding the automatic import of ocl
> >>>> components. We should check if ocl was *really* loaded instead of
> >>>> assuming it always is.
> >>>>
> >>>> I'll take a look at it again, I know it's not obvious for some reason.
> >>>> Your work around is indeed to include ocl for now in the
> >>>> RTT_COMPONENT_PATH.
> >>>
> >>> Why did you set RTT_COMPONENT_PATH in the first place ? In ros systems,
> >>> this variable is not useful, unless some non-ros package is to be
> >>> imported.
> >>
> >> Because this was the way to go before ....
> >> So are we not supposed to use the RTT_COMPONENT_PATH anymore?
> >
> > When everything you use is in a ros package and in your ROS_PACKAGE_PATH,
> > there's no need to set the RTT_COMPONENT_PATH. We will always use ROS to
> > locate the package and import the libraries from the lib/orocos directory
> > in your package.
> >
> > Peter
>
> I don't really understand how the setting of this ROS_PACKAGE_PATH can
> influence the problem.
> In my .bashrc I do (before the work around):
> export
> RTT_COMPONENT_PATH=$LUA_TYPEKIT_PATH:$RTT_TYPEKIT_PATH:$BFL_TYPEKIT_PATH:$R
> TT_COMPONENT_PATH; So if there was something in the RTT component path, it
> should be still there.
> And I say nothing about OCL.
> So if I have a non-ROS library, I will set the RTT component path in a
> similar way, causing the same problem, no?
Correct. I have pushed a fix to the toolchain-2.2 branch (ocl). This ocl-
specific issue will dissolve when ocl is installed in a package dir in the 2.3
release series.
Peter
problem with importing OCL components
On Tuesday 11 January 2011 14:33:24 Peter Soetens wrote:
> On Tuesday 11 January 2011 14:20:20 Tinne De Laet wrote:
> > ...
> >
> > > > We need to resolve this. It's caused by your definition of the
> > > > RTT_COMPONENT_PATH, hence overriding the automatic import of ocl
> > > > components. We should check if ocl was *really* loaded instead of
> > > > assuming it always is.
> > > >
> > > > I'll take a look at it again, I know it's not obvious for some
> > > > reason. Your work around is indeed to include ocl for now in the
> > > > RTT_COMPONENT_PATH.
> > >
> > > Why did you set RTT_COMPONENT_PATH in the first place ? In ros systems,
> > > this variable is not useful, unless some non-ros package is to be
> > > imported.
> >
> > Because this was the way to go before ....
> > So are we not supposed to use the RTT_COMPONENT_PATH anymore?
>
> When everything you use is in a ros package and in your ROS_PACKAGE_PATH,
> there's no need to set the RTT_COMPONENT_PATH. We will always use ROS to
> locate the package and import the libraries from the lib/orocos directory
> in your package.
This makes sense. Thanks for the clarification!
(I believe we were still using it since we have some components not writing
their lib in lib/orocos .... . So we first try to fix these things.)
Tinne