産総研 知能システム研究部門 ヒューマノイド研究グループ にてお世話になっております 俵です。
現在OpenHRP3.1.0β2ベースで可能であればOpenRTM0.4.2への 互換性を保ったままOpenRTM1.0.0-RC1への対応をしております。 そこでEclipseプラグイン(Java)からIDLとIDLJより 作成したスタブのExtTrigExecutionContextServiceを 参照するところで悩んでおります。
0.4.2ではRTC.ExtTrigExecutionContextService 1.0.0ではOpenRTM.ExtTrigExecutionContextService とモジュール名の変更から import文をCでいうところのプリプロセッサ的な 切り替えで対処したい状態に陥っております。
自分が考えた対策は a)下位互換性は放棄してOpenRTM1.0.0-RCにのみ対応する。 b)cmakeのようなコンフィギュア時に環境のOpenRTMバージョンで場合わけして Javaソースファイルの差し替えを行なう。 c)Java側でCでいうところのプリプロセッサ的仕組みがあればそれを採用する。 など浮かんだのですが、スマートな解決方法、助言があれば ご教示お願いします。 以上です。
モーションエディタ/シミュレータ
動力学シミュレータ
統合開発プラットフォーム
産総研が提供するRTC集
東京オープンソースロボティクス協会
ネットワーク分散環境でデータ収集用ソフトウェアを容易に構築するためのソフトウェア・フレームワーク
産総研 知能システム研究部門 ヒューマノイド研究グループ
にてお世話になっております 俵です。
現在OpenHRP3.1.0β2ベースで可能であればOpenRTM0.4.2への
互換性を保ったままOpenRTM1.0.0-RC1への対応をしております。
そこでEclipseプラグイン(Java)からIDLとIDLJより
作成したスタブのExtTrigExecutionContextServiceを
参照するところで悩んでおります。
0.4.2ではRTC.ExtTrigExecutionContextService
1.0.0ではOpenRTM.ExtTrigExecutionContextService
とモジュール名の変更から
import文をCでいうところのプリプロセッサ的な
切り替えで対処したい状態に陥っております。
自分が考えた対策は
a)下位互換性は放棄してOpenRTM1.0.0-RCにのみ対応する。
b)cmakeのようなコンフィギュア時に環境のOpenRTMバージョンで場合わけして
Javaソースファイルの差し替えを行なう。
c)Java側でCでいうところのプリプロセッサ的仕組みがあればそれを採用する。
など浮かんだのですが、スマートな解決方法、助言があれば
ご教示お願いします。
以上です。