Hi
I would like to announce the ALPHA version of BRIDE. This release is
meant to be a starting point for further development of an MDE IDE
that can be used for Orocos. The full release of BRIDE is meant to be
used in conjunction with a graphical editor for the BRICS Component
Model (BCM). The BCM is meant to be a meta-model for not only Orocos
but other frameworks such as OpenRTM. Yet, Orocos users are not
required to use the BCM part and can use the RTT editor standalone.
The idea of the BCM is to use it for the sharing of ideas between
members of the robotics community by sharing models of the software
they are using.
At the moment is supports creating an Orocos Package starting from a
graphical representation. The supported elements of RTT are Ports,
TaskContext, ConnectionPolicy, and Activity. You can see how it works
in this screencast:
http://www.best-of-robotics.org/bride/bcmdemo.html
Information and installation is available at:
http://www.best-of-robotics.org/bride/
We would like to exhort the Orocos community to test the software and
to join the bride-users list in order to further enhance BRIDE.
http://mailman.gps-stuttgart.de/mailman/listinfo/bride-users
We hope that with your input then BRIDE will be a useful tool for the
creation of Orocos based applications.
Thank you
Hugo A. Garcia
Research Assistant
Robotics Research Group
Katholieke Universiteit Leuven
Belgium
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 10:55 AM, Hugo Garcia wrote:
> Hi
>
> I would like to announce the ALPHA version of BRIDE. This release is
> meant to be a starting point for further development of an MDE IDE
> that can be used for Orocos. The full release of BRIDE is meant to be
> used in conjunction with a graphical editor for the BRICS Component
> Model (BCM). The BCM is meant to be a meta-model for not only Orocos
> but other frameworks such as OpenRTM. Yet, Orocos users are not
> required to use the BCM part and can use the RTT editor standalone.
> The idea of the BCM is to use it for the sharing of ideas between
> members of the robotics community by sharing models of the software
> they are using.
>
> At the moment is supports creating an Orocos Package starting from a
> graphical representation. The supported elements of RTT are Ports,
> TaskContext, ConnectionPolicy, and Activity. You can see how it works
> in this screencast:
>
> http://www.best-of-robotics.org/bride/bcmdemo.html
>
> Information and installation is available at:
>
> http://www.best-of-robotics.org/bride/
>
> We would like to exhort the Orocos community to test the software and
> to join the bride-users list in order to further enhance BRIDE.
>
> http://mailman.gps-stuttgart.de/mailman/listinfo/bride-users
>
> We hope that with your input then BRIDE will be a useful tool for the
> creation of Orocos based applications.
Cool.
Is there a specification somewhere of the files that are saved by the
model edition tool ? I could very easily use those as input to an orogen
generation as well ...
Sylvain
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 10:55 AM, Hugo Garcia wrote:
> Hi
>
> I would like to announce the ALPHA version of BRIDE. This release is
> meant to be a starting point for further development of an MDE IDE
> that can be used for Orocos. The full release of BRIDE is meant to be
> used in conjunction with a graphical editor for the BRICS Component
> Model (BCM). The BCM is meant to be a meta-model for not only Orocos
> but other frameworks such as OpenRTM. Yet, Orocos users are not
> required to use the BCM part and can use the RTT editor standalone.
> The idea of the BCM is to use it for the sharing of ideas between
> members of the robotics community by sharing models of the software
> they are using.
>
> At the moment is supports creating an Orocos Package starting from a
> graphical representation. The supported elements of RTT are Ports,
> TaskContext, ConnectionPolicy, and Activity. You can see how it works
> in this screencast:
>
> http://www.best-of-robotics.org/bride/bcmdemo.html
>
> Information and installation is available at:
>
> http://www.best-of-robotics.org/bride/
>
> We would like to exhort the Orocos community to test the software and
> to join the bride-users list in order to further enhance BRIDE.
>
> http://mailman.gps-stuttgart.de/mailman/listinfo/bride-users
>
> We hope that with your input then BRIDE will be a useful tool for the
> creation of Orocos based applications.
Cool.
Is there a specification somewhere of the files that are saved by the
model edition tool ? I could very easily use those as input to an orogen
generation as well ...
Sylvain
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
>
> Cool.
>
> Is there a specification somewhere of the files that are saved by the model
> edition tool ? I could very easily use those as input to an orogen
> generation as well ...
>
> Sylvain
>
Look at the RTT model page in the website. That is the current ecore model used.
If you want to see what is generated then it is best to download BRIDE
but these are the files:
>From the graphical editor:
an ecore model and a diagram file.
After generation from model:
The deployment file, the source files, the Cmake files, the manifest file
After building
The shared liabraries in a build directory with normal cmake stuff.
You can actually do make install and run the deployer using the
deployment file and it will work.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
>
> Cool.
>
> Is there a specification somewhere of the files that are saved by the model
> edition tool ? I could very easily use those as input to an orogen
> generation as well ...
>
> Sylvain
>
Look at the RTT model page in the website. That is the current ecore model used.
If you want to see what is generated then it is best to download BRIDE
but these are the files:
>From the graphical editor:
an ecore model and a diagram file.
After generation from model:
The deployment file, the source files, the Cmake files, the manifest file
After building
The shared liabraries in a build directory with normal cmake stuff.
You can actually do make install and run the deployer using the
deployment file and it will work.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 12:14 PM, Hugo Garcia wrote:
> Look at the RTT model page in the website. That is the current ecore model used.
>
> If you want to see what is generated then it is best to download BRIDE
> but these are the files:
>
> From the graphical editor:
>
> an ecore model and a diagram file.
>
> After generation from model:
>
> The deployment file, the source files, the Cmake files, the manifest file
>
> After building
>
> The shared liabraries in a build directory with normal cmake stuff.
>
> You can actually do make install and run the deployer using the
> deployment file and it will work.
oroGen is already a component generator, so I would only use the saved
files. I'll have to have a look at what they actually look like.
Sylvain
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 12:14 PM, Hugo Garcia wrote:
> Look at the RTT model page in the website. That is the current ecore model used.
>
> If you want to see what is generated then it is best to download BRIDE
> but these are the files:
>
> From the graphical editor:
>
> an ecore model and a diagram file.
>
> After generation from model:
>
> The deployment file, the source files, the Cmake files, the manifest file
>
> After building
>
> The shared liabraries in a build directory with normal cmake stuff.
>
> You can actually do make install and run the deployer using the
> deployment file and it will work.
oroGen is already a component generator, so I would only use the saved
files. I'll have to have a look at what they actually look like.
Sylvain
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
Typically EMF saves intermediate files in XMI format:
http://en.wikipedia.org/wiki/XML_Metadata_Interchange
The BRIDE (at least the RTT part) and OroGen is much the same. The
difference is that
BRIDE has graphical notation and is implemented with EMF, while OroGen is
textual and
is implemented in Ruby (please correct me if I am wrong).
In general, instead of parsing the XMI files produced by BRIDE you can
implement your
own M2T (Model-to-Text) transformation from BRIDE to the OroGen file format.
Or you
can implement OroGen syntax with xText and simply reuse the BRIDE code
generators...
Hugo - what are the reason, that BRIDE do not reuse the existing generators
from OroGen?
Regards,
Piotr.
On Fri, Aug 19, 2011 at 12:36, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 08/19/2011 12:14 PM, Hugo Garcia wrote:
> > Look at the RTT model page in the website. That is the current ecore
> model used.
> >
> > If you want to see what is generated then it is best to download BRIDE
> > but these are the files:
> >
> > From the graphical editor:
> >
> > an ecore model and a diagram file.
> >
> > After generation from model:
> >
> > The deployment file, the source files, the Cmake files, the manifest file
> >
> > After building
> >
> > The shared liabraries in a build directory with normal cmake stuff.
> >
> > You can actually do make install and run the deployer using the
> > deployment file and it will work.
> oroGen is already a component generator, so I would only use the saved
> files. I'll have to have a look at what they actually look like.
>
> Sylvain
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
Typically EMF saves intermediate files in XMI format:
http://en.wikipedia.org/wiki/XML_Metadata_Interchange
The BRIDE (at least the RTT part) and OroGen is much the same. The
difference is that
BRIDE has graphical notation and is implemented with EMF, while OroGen is
textual and
is implemented in Ruby (please correct me if I am wrong).
In general, instead of parsing the XMI files produced by BRIDE you can
implement your
own M2T (Model-to-Text) transformation from BRIDE to the OroGen file format.
Or you
can implement OroGen syntax with xText and simply reuse the BRIDE code
generators...
Hugo - what are the reason, that BRIDE do not reuse the existing generators
from OroGen?
Regards,
Piotr.
On Fri, Aug 19, 2011 at 12:36, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 08/19/2011 12:14 PM, Hugo Garcia wrote:
> > Look at the RTT model page in the website. That is the current ecore
> model used.
> >
> > If you want to see what is generated then it is best to download BRIDE
> > but these are the files:
> >
> > From the graphical editor:
> >
> > an ecore model and a diagram file.
> >
> > After generation from model:
> >
> > The deployment file, the source files, the Cmake files, the manifest file
> >
> > After building
> >
> > The shared liabraries in a build directory with normal cmake stuff.
> >
> > You can actually do make install and run the deployer using the
> > deployment file and it will work.
> oroGen is already a component generator, so I would only use the saved
> files. I'll have to have a look at what they actually look like.
>
> Sylvain
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 12:46, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> Typically EMF saves intermediate files in XMI format:
> http://en.wikipedia.org/wiki/XML_Metadata_Interchange
>
> The BRIDE (at least the RTT part) and OroGen is much the same. The
> difference is that
> BRIDE has graphical notation and is implemented with EMF, while OroGen is
> textual and
> is implemented in Ruby (please correct me if I am wrong).
Kind of, we have a separation between the model that represents an
Orocos package and the transformations into other artifacts such as
other model types and or the necessary artifacts for producing an
executable package like the deployment file (We could have easily
generated the scriptversion of the deployment.part).
Orogen is just the transformations + model intertwined with each other.
>
> In general, instead of parsing the XMI files produced by BRIDE you can
> implement your
> own M2T (Model-to-Text) transformation from BRIDE to the OroGen file format.
> Or you
> can implement OroGen syntax with xText and simply reuse the BRIDE code
> generators...
The M2T path is easier. I am using Epsilon for the transformations and
it is "easy" to create transformations from it.
>
> Hugo - what are the reason, that BRIDE do not reuse the existing generators
> from OroGen?
>
The goal is to use Eclipse for what it is: an Integrated Development
Environment (IDE) and use the CDT functionality. For this we need high
coupling with Eclipse. We also want a model based system given the
scope of the project in building an MDE based system.
Using command line tools such as OroGen decouples the IDE part and for
the most part renders Eclipse to just be an input file creator.
Integration beyond using Eclipse as an input file creator is difficult
and it is much easier to work within the Eclipse ecosystem.
Our usability goals are also easier to implement if we stay within the
Eclipse ecosystem. Our target audience are 1st and 2nd year PhD
students from the Engineering Dept... not the Computer Science Dept.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 12:46, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> Typically EMF saves intermediate files in XMI format:
> http://en.wikipedia.org/wiki/XML_Metadata_Interchange
>
> The BRIDE (at least the RTT part) and OroGen is much the same. The
> difference is that
> BRIDE has graphical notation and is implemented with EMF, while OroGen is
> textual and
> is implemented in Ruby (please correct me if I am wrong).
Kind of, we have a separation between the model that represents an
Orocos package and the transformations into other artifacts such as
other model types and or the necessary artifacts for producing an
executable package like the deployment file (We could have easily
generated the scriptversion of the deployment.part).
Orogen is just the transformations + model intertwined with each other.
>
> In general, instead of parsing the XMI files produced by BRIDE you can
> implement your
> own M2T (Model-to-Text) transformation from BRIDE to the OroGen file format.
> Or you
> can implement OroGen syntax with xText and simply reuse the BRIDE code
> generators...
The M2T path is easier. I am using Epsilon for the transformations and
it is "easy" to create transformations from it.
>
> Hugo - what are the reason, that BRIDE do not reuse the existing generators
> from OroGen?
>
The goal is to use Eclipse for what it is: an Integrated Development
Environment (IDE) and use the CDT functionality. For this we need high
coupling with Eclipse. We also want a model based system given the
scope of the project in building an MDE based system.
Using command line tools such as OroGen decouples the IDE part and for
the most part renders Eclipse to just be an input file creator.
Integration beyond using Eclipse as an input file creator is difficult
and it is much easier to work within the Eclipse ecosystem.
Our usability goals are also easier to implement if we stay within the
Eclipse ecosystem. Our target audience are 1st and 2nd year PhD
students from the Engineering Dept... not the Computer Science Dept.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 01:54 PM, Hugo Garcia wrote:
> The goal is to use Eclipse for what it is: an Integrated Development
> Environment (IDE) and use the CDT functionality. For this we need high
> coupling with Eclipse. We also want a model based system given the
> scope of the project in building an MDE based system.
>
> Using command line tools such as OroGen decouples the IDE part and for
> the most part renders Eclipse to just be an input file creator.
> Integration beyond using Eclipse as an input file creator is difficult
> and it is much easier to work within the Eclipse ecosystem.
>
> Our usability goals are also easier to implement if we stay within the
> Eclipse ecosystem. Our target audience are 1st and 2nd year PhD
> students from the Engineering Dept... not the Computer Science Dept.
And for what it's worth, control people here *are* using oroGen. Writing
the spec was *really* not their main problem. Understanding the concepts
behind the RTT components was.
--
Sylvain Joyeux
Space& Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 01:54 PM, Hugo Garcia wrote:
> The goal is to use Eclipse for what it is: an Integrated Development
> Environment (IDE) and use the CDT functionality. For this we need high
> coupling with Eclipse. We also want a model based system given the
> scope of the project in building an MDE based system.
>
> Using command line tools such as OroGen decouples the IDE part and for
> the most part renders Eclipse to just be an input file creator.
> Integration beyond using Eclipse as an input file creator is difficult
> and it is much easier to work within the Eclipse ecosystem.
>
> Our usability goals are also easier to implement if we stay within the
> Eclipse ecosystem. Our target audience are 1st and 2nd year PhD
> students from the Engineering Dept... not the Computer Science Dept.
And for what it's worth, control people here *are* using oroGen. Writing
the spec was *really* not their main problem. Understanding the concepts
behind the RTT components was.
--
Sylvain Joyeux
Space& Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> Orogen is just the transformations + model intertwined with each other.
>
Unfortunately the Orogen seems to be a pre-MDE tool...
The M2T path is easier. I am using Epsilon for the transformations and
> it is "easy" to create transformations from it.
>
And why you do not use more "standard-aligned" technologies, like Acceleo?
Thus you could (in general) decouple M2T transformation from the Eclipse
ecosystem.
Another issue, is that PortType <<enumeration>> BRIDE restricts a set of
datatypes,
which can be used by the underlying RTT.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> Orogen is just the transformations + model intertwined with each other.
>
Unfortunately the Orogen seems to be a pre-MDE tool...
The M2T path is easier. I am using Epsilon for the transformations and
> it is "easy" to create transformations from it.
>
And why you do not use more "standard-aligned" technologies, like Acceleo?
Thus you could (in general) decouple M2T transformation from the Eclipse
ecosystem.
Another issue, is that PortType <<enumeration>> BRIDE restricts a set of
datatypes,
which can be used by the underlying RTT.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 14:26, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
>>
>> Orogen is just the transformations + model intertwined with each other.
>
> Unfortunately the Orogen seems to be a pre-MDE tool...
>
>> The M2T path is easier. I am using Epsilon for the transformations and
>> it is "easy" to create transformations from it.
>
> And why you do not use more "standard-aligned" technologies, like Acceleo?
> Thus you could (in general) decouple M2T transformation from the Eclipse
> ecosystem.
Because those transformation using Acceleo and QVT are MDA based which
means you have to use an UML and/or OMG approach to things while when
using Epsilon I can create a domain model (yes ecore compliant) and
stick to a more generic MDE approach. From a development point of
view... it was much easier and faster to implement with Epsilon than
with Acceleo... at least in our use case.
>
> Another issue, is that PortType <<enumeration>> BRIDE restricts a set of
> datatypes,
> which can be used by the underlying RTT.
As soon as we get bugzilla up then you can open a bug report. This is
one of the many little problems to solve in the coming months.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 14:26, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
>>
>> Orogen is just the transformations + model intertwined with each other.
>
> Unfortunately the Orogen seems to be a pre-MDE tool...
>
>> The M2T path is easier. I am using Epsilon for the transformations and
>> it is "easy" to create transformations from it.
>
> And why you do not use more "standard-aligned" technologies, like Acceleo?
> Thus you could (in general) decouple M2T transformation from the Eclipse
> ecosystem.
Because those transformation using Acceleo and QVT are MDA based which
means you have to use an UML and/or OMG approach to things while when
using Epsilon I can create a domain model (yes ecore compliant) and
stick to a more generic MDE approach. From a development point of
view... it was much easier and faster to implement with Epsilon than
with Acceleo... at least in our use case.
>
> Another issue, is that PortType <<enumeration>> BRIDE restricts a set of
> datatypes,
> which can be used by the underlying RTT.
As soon as we get bugzilla up then you can open a bug report. This is
one of the many little problems to solve in the coming months.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 15:48, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> Because those transformation using Acceleo and QVT are MDA based which
> means you have to use an UML and/or OMG approach to things while when
> using Epsilon I can create a domain model (yes ecore compliant) and
> stick to a more generic MDE approach.
Acceleo does not enforce you to use UML/OMG. It is "OMG-aligned" in the
same sense, that Ecore is "MOF-aligned". Its use is not restricted to MDA.
Epsilon for Ecore is... using non-OMG-aligned tools for OMG-aligned
meta-model.
I am concerned, since Epsilon seems not to be on the list of EMF
long-term-supported
subprojects and the main development effort seems to be in the Acceleo (or
am I wrong?).
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 15:48, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> Because those transformation using Acceleo and QVT are MDA based which
> means you have to use an UML and/or OMG approach to things while when
> using Epsilon I can create a domain model (yes ecore compliant) and
> stick to a more generic MDE approach.
Acceleo does not enforce you to use UML/OMG. It is "OMG-aligned" in the
same sense, that Ecore is "MOF-aligned". Its use is not restricted to MDA.
Epsilon for Ecore is... using non-OMG-aligned tools for OMG-aligned
meta-model.
I am concerned, since Epsilon seems not to be on the list of EMF
long-term-supported
subprojects and the main development effort seems to be in the Acceleo (or
am I wrong?).
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 16:03, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 15:48, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
>>
>> Because those transformation using Acceleo and QVT are MDA based which
>> means you have to use an UML and/or OMG approach to things while when
>> using Epsilon I can create a domain model (yes ecore compliant) and
>> stick to a more generic MDE approach.
>
> Acceleo does not enforce you to use UML/OMG. It is "OMG-aligned" in the
> same sense, that Ecore is "MOF-aligned". Its use is not restricted to MDA.
>
> Epsilon for Ecore is... using non-OMG-aligned tools for OMG-aligned
> meta-model.
> I am concerned, since Epsilon seems not to be on the list of EMF
> long-term-supported
> subprojects and the main development effort seems to be in the Acceleo (or
> am I wrong?).
>
> --
> Piotr
>
They are part of the GMT project not the EMF project and Epsilon is
actively developed and maintained. There are other groups that are
approaching the BRIDE problem but from a more OMG MDA approach.
Here... we are taking the MDE approach.
When and if the Acceleo team implements a C++ generator or pays me to
build it then I might revisit it again but as is at the present
moment, using Acceleo + QVT is technically more challenging than using
Epsilon. The end result being the same but with faster development
time using Epsilon. One thing to point out is that the syntax used in
the transformation is very similar
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 16:03, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 15:48, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
>>
>> Because those transformation using Acceleo and QVT are MDA based which
>> means you have to use an UML and/or OMG approach to things while when
>> using Epsilon I can create a domain model (yes ecore compliant) and
>> stick to a more generic MDE approach.
>
> Acceleo does not enforce you to use UML/OMG. It is "OMG-aligned" in the
> same sense, that Ecore is "MOF-aligned". Its use is not restricted to MDA.
>
> Epsilon for Ecore is... using non-OMG-aligned tools for OMG-aligned
> meta-model.
> I am concerned, since Epsilon seems not to be on the list of EMF
> long-term-supported
> subprojects and the main development effort seems to be in the Acceleo (or
> am I wrong?).
>
> --
> Piotr
>
They are part of the GMT project not the EMF project and Epsilon is
actively developed and maintained. There are other groups that are
approaching the BRIDE problem but from a more OMG MDA approach.
Here... we are taking the MDE approach.
When and if the Acceleo team implements a C++ generator or pays me to
build it then I might revisit it again but as is at the present
moment, using Acceleo + QVT is technically more challenging than using
Epsilon. The end result being the same but with faster development
time using Epsilon. One thing to point out is that the syntax used in
the transformation is very similar
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 16:46, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> When and if the Acceleo team implements a C++ generator or pays me to
> build it then I might revisit it again but as is at the present
> moment, using Acceleo + QVT is technically more challenging than using
> Epsilon.
What Acceleo team has already done is support for standalone execution:
http://wiki.eclipse.org/Acceleo/New_And_Noteworthy#Standalone
So you can much easier reuse the code templates from outside of the Eclipse
ecosystem and share them with other toolchains, e.g. oroGen. I see no reason
to reimplement the engine in C++.
> The end result being the same but with faster development time using
> Epsilon.
>From the BRIDE point of view - true. From the reusability point of view -
not necessarily.
> One thing to point out is that the syntax used in the transformation is
> very similar
>
In general I would expect, that it is possible to develop a biderectional
model-to-model
transformation between Acceleo and Epsilon! :-)
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 16:46, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> When and if the Acceleo team implements a C++ generator or pays me to
> build it then I might revisit it again but as is at the present
> moment, using Acceleo + QVT is technically more challenging than using
> Epsilon.
What Acceleo team has already done is support for standalone execution:
http://wiki.eclipse.org/Acceleo/New_And_Noteworthy#Standalone
So you can much easier reuse the code templates from outside of the Eclipse
ecosystem and share them with other toolchains, e.g. oroGen. I see no reason
to reimplement the engine in C++.
> The end result being the same but with faster development time using
> Epsilon.
>From the BRIDE point of view - true. From the reusability point of view -
not necessarily.
> One thing to point out is that the syntax used in the transformation is
> very similar
>
In general I would expect, that it is possible to develop a biderectional
model-to-model
transformation between Acceleo and Epsilon! :-)
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 16:46, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> > Epsilon for Ecore is... using non-OMG-aligned tools for OMG-aligned
> > meta-model.
> > I am concerned, since Epsilon seems not to be on the list of EMF
> > long-term-supported
> > subprojects and the main development effort seems to be in the Acceleo
> (or
> > am I wrong?).
>
> They are part of the GMT project not the EMF project and Epsilon is
> actively developed and maintained. There are other groups that are
> approaching the BRIDE problem but from a more OMG MDA approach.
> Here... we are taking the MDE approach.
>
OK, sorry. I meant EMP, not EMF (model-based confusion...).
The GMT is "research incubator project of the top-level Eclipse Modeling
Project",
so I would expect, that Epsilon (as part of the incubator) is less supported
than
Acceleo (which is already part of the top-level Eclipse Modeling Project).
Maybe
I am wrong...
I have been trying EuGENia some time ago and it discouraged me from using
Epsilon.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 16:46, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> > Epsilon for Ecore is... using non-OMG-aligned tools for OMG-aligned
> > meta-model.
> > I am concerned, since Epsilon seems not to be on the list of EMF
> > long-term-supported
> > subprojects and the main development effort seems to be in the Acceleo
> (or
> > am I wrong?).
>
> They are part of the GMT project not the EMF project and Epsilon is
> actively developed and maintained. There are other groups that are
> approaching the BRIDE problem but from a more OMG MDA approach.
> Here... we are taking the MDE approach.
>
OK, sorry. I meant EMP, not EMF (model-based confusion...).
The GMT is "research incubator project of the top-level Eclipse Modeling
Project",
so I would expect, that Epsilon (as part of the incubator) is less supported
than
Acceleo (which is already part of the top-level Eclipse Modeling Project).
Maybe
I am wrong...
I have been trying EuGENia some time ago and it discouraged me from using
Epsilon.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 17:29, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 16:46, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
>>
>> > Epsilon for Ecore is... using non-OMG-aligned tools for OMG-aligned
>> > meta-model.
>> > I am concerned, since Epsilon seems not to be on the list of EMF
>> > long-term-supported
>> > subprojects and the main development effort seems to be in the Acceleo
>> > (or
>> > am I wrong?).
>>
>> They are part of the GMT project not the EMF project and Epsilon is
>> actively developed and maintained. There are other groups that are
>> approaching the BRIDE problem but from a more OMG MDA approach.
>> Here... we are taking the MDE approach.
>
> OK, sorry. I meant EMP, not EMF (model-based confusion...).
>
> The GMT is "research incubator project of the top-level Eclipse Modeling
> Project",
> so I would expect, that Epsilon (as part of the incubator) is less supported
> than
> Acceleo (which is already part of the top-level Eclipse Modeling Project).
> Maybe
> I am wrong...
If by support you mean:
active development
rapid bug resolution
keeping up with the latest Eclipse stable release
responsive newsgroup/forum
then they are both well supported.
>
> I have been trying EuGENia some time ago and it discouraged me from using
> Epsilon.
>
Yeah, I looked at EuGEnia and it needs a couple of more releases. I
don't use it yet. I use the GMF Tooling for generating the GMF
edtiors.
What I do use is the Epsilon Object Language (EOL) for all the M2M and
M2T transformations via ETLand EGL respectively.
http://www.eclipse.org/gmt/epsilon/doc/
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 17:29, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 16:46, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
>>
>> > Epsilon for Ecore is... using non-OMG-aligned tools for OMG-aligned
>> > meta-model.
>> > I am concerned, since Epsilon seems not to be on the list of EMF
>> > long-term-supported
>> > subprojects and the main development effort seems to be in the Acceleo
>> > (or
>> > am I wrong?).
>>
>> They are part of the GMT project not the EMF project and Epsilon is
>> actively developed and maintained. There are other groups that are
>> approaching the BRIDE problem but from a more OMG MDA approach.
>> Here... we are taking the MDE approach.
>
> OK, sorry. I meant EMP, not EMF (model-based confusion...).
>
> The GMT is "research incubator project of the top-level Eclipse Modeling
> Project",
> so I would expect, that Epsilon (as part of the incubator) is less supported
> than
> Acceleo (which is already part of the top-level Eclipse Modeling Project).
> Maybe
> I am wrong...
If by support you mean:
active development
rapid bug resolution
keeping up with the latest Eclipse stable release
responsive newsgroup/forum
then they are both well supported.
>
> I have been trying EuGENia some time ago and it discouraged me from using
> Epsilon.
>
Yeah, I looked at EuGEnia and it needs a couple of more releases. I
don't use it yet. I use the GMF Tooling for generating the GMF
edtiors.
What I do use is the Epsilon Object Language (EOL) for all the M2M and
M2T transformations via ETLand EGL respectively.
http://www.eclipse.org/gmt/epsilon/doc/
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 02:26 PM, Piotr Trojanek wrote:
> On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...
> <mailto:hugo [dot] a [dot] garcia [..] ...>> wrote:
>
> Orogen is just the transformations + model intertwined with each
> other.
>
>
> Unfortunately the Orogen seems to be a pre-MDE tool...
If by pre-MDE you mean "not using formalized model transformation",
then, yes, it is. And that's by design.
I do understand the need to separate code generation (i.e.
transformation) from specification. It makes things cleaner and more
reusable. And that's definitely a goal for oroGen.
I don't get, though, the "use formalized model transformation" part when
it comes to code generation, because you almost can't reuse your
transformation models between your different targets. So, in the end, it
is more complicated to use the formalized model than writing code that
does the generation based on the spec.
The paramount example being XSLT. In a lot of cases, writing a
ruby/python/whatever script that converts your XML documents is an order
of magnitude easier, more reusable and more easy to maintain than
writing XSLT.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 02:26 PM, Piotr Trojanek wrote:
> On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...
> <mailto:hugo [dot] a [dot] garcia [..] ...>> wrote:
>
> Orogen is just the transformations + model intertwined with each
> other.
>
>
> Unfortunately the Orogen seems to be a pre-MDE tool...
If by pre-MDE you mean "not using formalized model transformation",
then, yes, it is. And that's by design.
I do understand the need to separate code generation (i.e.
transformation) from specification. It makes things cleaner and more
reusable. And that's definitely a goal for oroGen.
I don't get, though, the "use formalized model transformation" part when
it comes to code generation, because you almost can't reuse your
transformation models between your different targets. So, in the end, it
is more complicated to use the formalized model than writing code that
does the generation based on the spec.
The paramount example being XSLT. In a lot of cases, writing a
ruby/python/whatever script that converts your XML documents is an order
of magnitude easier, more reusable and more easy to maintain than
writing XSLT.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 14:31, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> **
> On 08/19/2011 02:26 PM, Piotr Trojanek wrote:
>
> On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...>wrote:
>
>> Orogen is just the transformations + model intertwined with each other.
>>
>
> Unfortunately the Orogen seems to be a pre-MDE tool...
>
> If by pre-MDE you mean "not using formalized model transformation", then,
> yes, it is. And that's by design.
>
> I do understand the need to separate code generation (i.e. transformation)
> from specification. It makes things cleaner and more reusable. And that's
> definitely a goal for oroGen.
>
No, by MDE I mean rather a complete approach. That is, e.g., having multiple
notations (both graphical like BRIDE
and textual like oroGen) for the same meta-model, having multiple M2T
transformations (like separate generators for
documentation and code), implementing constraint rules within a model (like
OCL), defining translational semantics
with M2M transformations, etc.
MDE is much more than formalized model transformations...
> I don't get, though, the "use formalized model transformation" part when it
> comes to code generation, because you almost can't reuse your transformation
> models between your different targets. So, in the end, it is more
> complicated to use the formalized model than writing code that does the
> generation based on the spec.
>
You can. And you can also reuse some parts between constraints checking,
model validation, etc.
This is why OMG unified those aspects as QVT.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 14:31, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> **
> On 08/19/2011 02:26 PM, Piotr Trojanek wrote:
>
> On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...>wrote:
>
>> Orogen is just the transformations + model intertwined with each other.
>>
>
> Unfortunately the Orogen seems to be a pre-MDE tool...
>
> If by pre-MDE you mean "not using formalized model transformation", then,
> yes, it is. And that's by design.
>
> I do understand the need to separate code generation (i.e. transformation)
> from specification. It makes things cleaner and more reusable. And that's
> definitely a goal for oroGen.
>
No, by MDE I mean rather a complete approach. That is, e.g., having multiple
notations (both graphical like BRIDE
and textual like oroGen) for the same meta-model, having multiple M2T
transformations (like separate generators for
documentation and code), implementing constraint rules within a model (like
OCL), defining translational semantics
with M2M transformations, etc.
MDE is much more than formalized model transformations...
> I don't get, though, the "use formalized model transformation" part when it
> comes to code generation, because you almost can't reuse your transformation
> models between your different targets. So, in the end, it is more
> complicated to use the formalized model than writing code that does the
> generation based on the spec.
>
You can. And you can also reuse some parts between constraints checking,
model validation, etc.
This is why OMG unified those aspects as QVT.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 14:44, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 14:31, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> wrote:
>>
>> On 08/19/2011 02:26 PM, Piotr Trojanek wrote:
>>
>> On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...>
>> wrote:
>>>
>>> Orogen is just the transformations + model intertwined with each other.
>>
>> Unfortunately the Orogen seems to be a pre-MDE tool...
>>
>> If by pre-MDE you mean "not using formalized model transformation", then,
>> yes, it is. And that's by design.
>>
>> I do understand the need to separate code generation (i.e. transformation)
>> from specification. It makes things cleaner and more reusable. And that's
>> definitely a goal for oroGen.
>
> No, by MDE I mean rather a complete approach. That is, e.g., having multiple
> notations (both graphical like BRIDE
> and textual like oroGen) for the same meta-model, having multiple M2T
> transformations (like separate generators for
> documentation and code), implementing constraint rules within a model (like
> OCL), defining translational semantics
> with M2M transformations, etc.
>
> MDE is much more than formalized model transformations...
>
>>
+1
With a formalized model of RTT then we can accomplish all of the above.
The RTT ecore model could be used by OroGen directly. Yet the model
itself could be used by RTT. What if we used the model as our
deployment file? and this question should be brought up on the
Orocos-Dev list once we have a more robust RTT ecore model.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 14:44, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 14:31, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> wrote:
>>
>> On 08/19/2011 02:26 PM, Piotr Trojanek wrote:
>>
>> On Fri, Aug 19, 2011 at 13:54, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...>
>> wrote:
>>>
>>> Orogen is just the transformations + model intertwined with each other.
>>
>> Unfortunately the Orogen seems to be a pre-MDE tool...
>>
>> If by pre-MDE you mean "not using formalized model transformation", then,
>> yes, it is. And that's by design.
>>
>> I do understand the need to separate code generation (i.e. transformation)
>> from specification. It makes things cleaner and more reusable. And that's
>> definitely a goal for oroGen.
>
> No, by MDE I mean rather a complete approach. That is, e.g., having multiple
> notations (both graphical like BRIDE
> and textual like oroGen) for the same meta-model, having multiple M2T
> transformations (like separate generators for
> documentation and code), implementing constraint rules within a model (like
> OCL), defining translational semantics
> with M2M transformations, etc.
>
> MDE is much more than formalized model transformations...
>
>>
+1
With a formalized model of RTT then we can accomplish all of the above.
The RTT ecore model could be used by OroGen directly. Yet the model
itself could be used by RTT. What if we used the model as our
deployment file? and this question should be brought up on the
Orocos-Dev list once we have a more robust RTT ecore model.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 04:00 PM, Hugo Garcia wrote:
> +1
>
> With a formalized model of RTT then we can accomplish all of the above.
>
> The RTT ecore model could be used by OroGen directly. Yet the model
> itself could be used by RTT. What if we used the model as our
> deployment file? and this question should be brought up on the
> Orocos-Dev list once we have a more robust RTT ecore model.
FYI. The Rock toolchain already *uses* oroGen specs.
The metamodel and such is not formalized (and so, yes, it is not a pure
MDE approach as you see it), but it is *definitely* a model-based
approach. For me, that's what matters most.
--
Sylvain Joyeux
Space& Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 04:00 PM, Hugo Garcia wrote:
> +1
>
> With a formalized model of RTT then we can accomplish all of the above.
>
> The RTT ecore model could be used by OroGen directly. Yet the model
> itself could be used by RTT. What if we used the model as our
> deployment file? and this question should be brought up on the
> Orocos-Dev list once we have a more robust RTT ecore model.
FYI. The Rock toolchain already *uses* oroGen specs.
The metamodel and such is not formalized (and so, yes, it is not a pure
MDE approach as you see it), but it is *definitely* a model-based
approach. For me, that's what matters most.
--
Sylvain Joyeux
Space& Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 01:54 PM, Hugo Garcia wrote:
> Orogen is just the transformations + model intertwined with each other.
Actually, not true anymore. oroGen has a spec part and a code generation
part.
(to be fair: still a bit true for some things, but I'm working on
finally cleaning that up).
For one of the new DFKI project, I am even planning to model ROS nodes
using oroGen specs, so ...
> The M2T path is easier. I am using Epsilon for the transformations and
> it is "easy" to create transformations from it.
Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it
is. In my case, I always feel that toolchains should be strictly
non-GUI, but YMMV.
> Using command line tools such as OroGen decouples the IDE part and for
> the most part renders Eclipse to just be an input file creator.
> Integration beyond using Eclipse as an input file creator is difficult
> and it is much easier to work within the Eclipse ecosystem.
>
> Our usability goals are also easier to implement if we stay within the
> Eclipse ecosystem. Our target audience are 1st and 2nd year PhD
> students from the Engineering Dept... not the Computer Science Dept.
I don't buy this. I'm pretty sure that you can call external tools from
Eclipse. If that is indeed the case, converting the Eclipse model into
an oroGen spec and calling orogen to do the code generation is a no-brainer.
Non-savvy people don't care *how* things are done, just that they work.
--
Sylvain Joyeux
Space& Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 01:54 PM, Hugo Garcia wrote:
> Orogen is just the transformations + model intertwined with each other.
Actually, not true anymore. oroGen has a spec part and a code generation
part.
(to be fair: still a bit true for some things, but I'm working on
finally cleaning that up).
For one of the new DFKI project, I am even planning to model ROS nodes
using oroGen specs, so ...
> The M2T path is easier. I am using Epsilon for the transformations and
> it is "easy" to create transformations from it.
Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it
is. In my case, I always feel that toolchains should be strictly
non-GUI, but YMMV.
> Using command line tools such as OroGen decouples the IDE part and for
> the most part renders Eclipse to just be an input file creator.
> Integration beyond using Eclipse as an input file creator is difficult
> and it is much easier to work within the Eclipse ecosystem.
>
> Our usability goals are also easier to implement if we stay within the
> Eclipse ecosystem. Our target audience are 1st and 2nd year PhD
> students from the Engineering Dept... not the Computer Science Dept.
I don't buy this. I'm pretty sure that you can call external tools from
Eclipse. If that is indeed the case, converting the Eclipse model into
an oroGen spec and calling orogen to do the code generation is a no-brainer.
Non-savvy people don't care *how* things are done, just that they work.
--
Sylvain Joyeux
Space& Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 14:22, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 08/19/2011 01:54 PM, Hugo Garcia wrote:
>>
>> Orogen is just the transformations + model intertwined with each other.
>
> Actually, not true anymore. oroGen has a spec part and a code generation
> part.
> (to be fair: still a bit true for some things, but I'm working on finally
> cleaning that up).
>
> For one of the new DFKI project, I am even planning to model ROS nodes using
> oroGen specs, so ...
>>
>> The M2T path is easier. I am using Epsilon for the transformations and
>> it is "easy" to create transformations from it.
>
> Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it is.
> In my case, I always feel that toolchains should be strictly non-GUI, but
> YMMV.
The command line in a console is a GUI.
Command line vs GUI debates are totally nonsensical in my opinion.
What matters is the workflow in performing a task or series of task.
For some tasks command line is better for others a GUI is better and
for others a mix of both is optimal.
Would you actually want your cell phone to have only a command line interface???
>>
>> Using command line tools such as OroGen decouples the IDE part and for
>> the most part renders Eclipse to just be an input file creator.
>> Integration beyond using Eclipse as an input file creator is difficult
>> and it is much easier to work within the Eclipse ecosystem.
>>
>> Our usability goals are also easier to implement if we stay within the
>> Eclipse ecosystem. Our target audience are 1st and 2nd year PhD
>> students from the Engineering Dept... not the Computer Science Dept.
>
> I don't buy this. I'm pretty sure that you can call external tools from
> Eclipse. If that is indeed the case, converting the Eclipse model into an
> oroGen spec and calling orogen to do the code generation is a no-brainer.
Yes you can call them, yes it is a no brainer. But if you are only
doing calls then you are not integrating from where you are calling
from. This is what I mean by using Eclipse just as an input file
editor.
>
> Non-savvy people don't care *how* things are done, just that they work.
Non-savvy people care that things work as easily as possible so that
they can focus on their main problem to solve. How it work under the
hood is not their problem but how it works for them in accomplishing
the task of solving their problem is.
-H
>
> --
> Sylvain Joyeux
> Space& Security Robotics
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 14:22, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 08/19/2011 01:54 PM, Hugo Garcia wrote:
>>
>> Orogen is just the transformations + model intertwined with each other.
>
> Actually, not true anymore. oroGen has a spec part and a code generation
> part.
> (to be fair: still a bit true for some things, but I'm working on finally
> cleaning that up).
>
> For one of the new DFKI project, I am even planning to model ROS nodes using
> oroGen specs, so ...
>>
>> The M2T path is easier. I am using Epsilon for the transformations and
>> it is "easy" to create transformations from it.
>
> Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it is.
> In my case, I always feel that toolchains should be strictly non-GUI, but
> YMMV.
The command line in a console is a GUI.
Command line vs GUI debates are totally nonsensical in my opinion.
What matters is the workflow in performing a task or series of task.
For some tasks command line is better for others a GUI is better and
for others a mix of both is optimal.
Would you actually want your cell phone to have only a command line interface???
>>
>> Using command line tools such as OroGen decouples the IDE part and for
>> the most part renders Eclipse to just be an input file creator.
>> Integration beyond using Eclipse as an input file creator is difficult
>> and it is much easier to work within the Eclipse ecosystem.
>>
>> Our usability goals are also easier to implement if we stay within the
>> Eclipse ecosystem. Our target audience are 1st and 2nd year PhD
>> students from the Engineering Dept... not the Computer Science Dept.
>
> I don't buy this. I'm pretty sure that you can call external tools from
> Eclipse. If that is indeed the case, converting the Eclipse model into an
> oroGen spec and calling orogen to do the code generation is a no-brainer.
Yes you can call them, yes it is a no brainer. But if you are only
doing calls then you are not integrating from where you are calling
from. This is what I mean by using Eclipse just as an input file
editor.
>
> Non-savvy people don't care *how* things are done, just that they work.
Non-savvy people care that things work as easily as possible so that
they can focus on their main problem to solve. How it work under the
hood is not their problem but how it works for them in accomplishing
the task of solving their problem is.
-H
>
> --
> Sylvain Joyeux
> Space& Security Robotics
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 03:34 PM, Hugo Garcia wrote:
>> Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it is.
>> In my case, I always feel that toolchains should be strictly non-GUI, but
>> YMMV.
> The command line in a console is a GUI.
>
> Command line vs GUI debates are totally nonsensical in my opinion.
>
> What matters is the workflow in performing a task or series of task.
> For some tasks command line is better for others a GUI is better and
> for others a mix of both is optimal.
>
> Would you actually want your cell phone to have only a command line interface???
Ah ... I should explain myself better
I don't want everything in the world to be a console-based, far from it.
My issue is that, while command-line tools can be used in GUIs, the
opposite is *very often* not possible. That's why I personally perfer
the "plumbing" of the toolchains I use to be command-line tools. For the
rest, it has to be application-oriented (i.e. sometimes console,
sometimes GUI).
>> I don't buy this. I'm pretty sure that you can call external tools from
>> Eclipse. If that is indeed the case, converting the Eclipse model into an
>> oroGen spec and calling orogen to do the code generation is a no-brainer.
> Yes you can call them, yes it is a no brainer. But if you are only
> doing calls then you are not integrating from where you are calling
> from. This is what I mean by using Eclipse just as an input file
> editor.
Again, I don't see the issue here. You create your eclipse-based model
using the exact same graphical representation. Now, instead of
generating the code directly, you generate an intermediate
representation (a.k.a. an oroGen specification) and use orogen to
generate the code for you. This does not change the UI
I *do* understand that you might want to do everything in Eclipse. I
just don't think that your former argument applies.
>> Non-savvy people don't care *how* things are done, just that they work.
> Non-savvy people care that things work as easily as possible so that
> they can focus on their main problem to solve. How it work under the
> hood is not their problem but how it works for them in accomplishing
> the task of solving their problem is.
Exactly my point. They don't care if eclipse generates the code, or
oroGen or whatever. They just want it to *be* generated, and having the
same user-friendly interface.
--
Sylvain Joyeux
Space& Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On 08/19/2011 03:34 PM, Hugo Garcia wrote:
>> Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it is.
>> In my case, I always feel that toolchains should be strictly non-GUI, but
>> YMMV.
> The command line in a console is a GUI.
>
> Command line vs GUI debates are totally nonsensical in my opinion.
>
> What matters is the workflow in performing a task or series of task.
> For some tasks command line is better for others a GUI is better and
> for others a mix of both is optimal.
>
> Would you actually want your cell phone to have only a command line interface???
Ah ... I should explain myself better
I don't want everything in the world to be a console-based, far from it.
My issue is that, while command-line tools can be used in GUIs, the
opposite is *very often* not possible. That's why I personally perfer
the "plumbing" of the toolchains I use to be command-line tools. For the
rest, it has to be application-oriented (i.e. sometimes console,
sometimes GUI).
>> I don't buy this. I'm pretty sure that you can call external tools from
>> Eclipse. If that is indeed the case, converting the Eclipse model into an
>> oroGen spec and calling orogen to do the code generation is a no-brainer.
> Yes you can call them, yes it is a no brainer. But if you are only
> doing calls then you are not integrating from where you are calling
> from. This is what I mean by using Eclipse just as an input file
> editor.
Again, I don't see the issue here. You create your eclipse-based model
using the exact same graphical representation. Now, instead of
generating the code directly, you generate an intermediate
representation (a.k.a. an oroGen specification) and use orogen to
generate the code for you. This does not change the UI
I *do* understand that you might want to do everything in Eclipse. I
just don't think that your former argument applies.
>> Non-savvy people don't care *how* things are done, just that they work.
> Non-savvy people care that things work as easily as possible so that
> they can focus on their main problem to solve. How it work under the
> hood is not their problem but how it works for them in accomplishing
> the task of solving their problem is.
Exactly my point. They don't care if eclipse generates the code, or
oroGen or whatever. They just want it to *be* generated, and having the
same user-friendly interface.
--
Sylvain Joyeux
Space& Security Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 15:34, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> > Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it
> is.
> > In my case, I always feel that toolchains should be strictly non-GUI, but
> > YMMV.
>
> The command line in a console is a GUI.
>
> Command line vs GUI debates are totally nonsensical in my opinion.
>
Not really. Command line tools are MUCH easier to reuse. If some tool is
embedded
within a GUI, then it requires user interaction (by definition).
This way oroGen's generators are much easier to reuse than BRIDE's. Of
course, in
case of oroGen you need to have ruby installed, etc. - but it is issue of
packaging,
not integrating.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 15:34, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
> > Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it
> is.
> > In my case, I always feel that toolchains should be strictly non-GUI, but
> > YMMV.
>
> The command line in a console is a GUI.
>
> Command line vs GUI debates are totally nonsensical in my opinion.
>
Not really. Command line tools are MUCH easier to reuse. If some tool is
embedded
within a GUI, then it requires user interaction (by definition).
This way oroGen's generators are much easier to reuse than BRIDE's. Of
course, in
case of oroGen you need to have ruby installed, etc. - but it is issue of
packaging,
not integrating.
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 15:50, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 15:34, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
>>
>> > Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it
>> > is.
>> > In my case, I always feel that toolchains should be strictly non-GUI,
>> > but
>> > YMMV.
>>
>> The command line in a console is a GUI.
>>
>> Command line vs GUI debates are totally nonsensical in my opinion.
>
> Not really. Command line tools are MUCH easier to reuse.
I agree with the the statement about reuse. Command line tools are
ideally meant to be work flow independent while as soon as you have a
UI then you are imposing constraints on the user to a limited set of
workflows. Finding and improving the workflow of a user is one of the
points of having an IDE and one of the goals of BRIDE.
If some tool is
> embedded
> within a GUI, then it requires user interaction (by definition).
>
> This way oroGen's generators are much easier to reuse than BRIDE's. Of
> course, in
> case of oroGen you need to have ruby installed, etc. - but it is issue of
> packaging,
> not integrating.
>
Well, there is still a text based UI in Orogen with a particular
workflow but in general I agree you could decompose OroGen and use
parts of it in another tools chain which means using the work flow of
the tool chain you are starting with and this leads to what I mean by
integration: having the command line tool be part of the workflow and
being hooked into the toolchain in a seamless manner.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
On Fri, Aug 19, 2011 at 15:50, Piotr Trojanek <piotr [dot] trojanek [..] ...> wrote:
> On Fri, Aug 19, 2011 at 15:34, Hugo Garcia <hugo [dot] a [dot] garcia [..] ...> wrote:
>>
>> > Yeaaah. I guess that if Eclipse is in the middle of your toolchain, it
>> > is.
>> > In my case, I always feel that toolchains should be strictly non-GUI,
>> > but
>> > YMMV.
>>
>> The command line in a console is a GUI.
>>
>> Command line vs GUI debates are totally nonsensical in my opinion.
>
> Not really. Command line tools are MUCH easier to reuse.
I agree with the the statement about reuse. Command line tools are
ideally meant to be work flow independent while as soon as you have a
UI then you are imposing constraints on the user to a limited set of
workflows. Finding and improving the workflow of a user is one of the
points of having an IDE and one of the goals of BRIDE.
If some tool is
> embedded
> within a GUI, then it requires user interaction (by definition).
>
> This way oroGen's generators are much easier to reuse than BRIDE's. Of
> course, in
> case of oroGen you need to have ruby installed, etc. - but it is issue of
> packaging,
> not integrating.
>
Well, there is still a text based UI in Orogen with a particular
workflow but in general I agree you could decompose OroGen and use
parts of it in another tools chain which means using the work flow of
the tool chain you are starting with and this leads to what I mean by
integration: having the command line tool be part of the workflow and
being hooked into the toolchain in a seamless manner.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
2011/8/19 Hugo Garcia <hugo [dot] a [dot] garcia [..] ...>
> Hi
>
> I would like to announce the ALPHA version of BRIDE. This release is
> meant to be a starting point for further development of an MDE IDE
> that can be used for Orocos. The full release of BRIDE is meant to be
> used in conjunction with a graphical editor for the BRICS Component
> Model (BCM). The BCM is meant to be a meta-model for not only Orocos
> but other frameworks such as OpenRTM. Yet, Orocos users are not
> required to use the BCM part and can use the RTT editor standalone.
> The idea of the BCM is to use it for the sharing of ideas between
> members of the robotics community by sharing models of the software
> they are using.
>
> At the moment is supports creating an Orocos Package starting from a
> graphical representation. The supported elements of RTT are Ports,
> TaskContext, ConnectionPolicy, and Activity. You can see how it works
> in this screencast:
>
> http://www.best-of-robotics.org/bride/bcmdemo.html
>
> Information and installation is available at:
>
> http://www.best-of-robotics.org/bride/
>
> We would like to exhort the Orocos community to test the software and
> to join the bride-users list in order to further enhance BRIDE.
>
> http://mailman.gps-stuttgart.de/mailman/listinfo/bride-users
>
> We hope that with your input then BRIDE will be a useful tool for the
> creation of Orocos based applications.
>
> Thank you
>
Hi, this is really nice. Can't wait until this kind of project will be
stable.
How does the connection between the 2 component is made after generation ?
is it hard coded in the c++ code ? or is the connection just at model level
?
>
> Hugo A. Garcia
> Research Assistant
> Robotics Research Group
> Katholieke Universiteit Leuven
> Belgium
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
2011/8/19 Hugo Garcia <hugo [dot] a [dot] garcia [..] ...>
> Hi
>
> I would like to announce the ALPHA version of BRIDE. This release is
> meant to be a starting point for further development of an MDE IDE
> that can be used for Orocos. The full release of BRIDE is meant to be
> used in conjunction with a graphical editor for the BRICS Component
> Model (BCM). The BCM is meant to be a meta-model for not only Orocos
> but other frameworks such as OpenRTM. Yet, Orocos users are not
> required to use the BCM part and can use the RTT editor standalone.
> The idea of the BCM is to use it for the sharing of ideas between
> members of the robotics community by sharing models of the software
> they are using.
>
> At the moment is supports creating an Orocos Package starting from a
> graphical representation. The supported elements of RTT are Ports,
> TaskContext, ConnectionPolicy, and Activity. You can see how it works
> in this screencast:
>
> http://www.best-of-robotics.org/bride/bcmdemo.html
>
> Information and installation is available at:
>
> http://www.best-of-robotics.org/bride/
>
> We would like to exhort the Orocos community to test the software and
> to join the bride-users list in order to further enhance BRIDE.
>
> http://mailman.gps-stuttgart.de/mailman/listinfo/bride-users
>
> We hope that with your input then BRIDE will be a useful tool for the
> creation of Orocos based applications.
>
> Thank you
>
Hi, this is really nice. Can't wait until this kind of project will be
stable.
How does the connection between the 2 component is made after generation ?
is it hard coded in the c++ code ? or is the connection just at model level
?
>
> Hugo A. Garcia
> Research Assistant
> Robotics Research Group
> Katholieke Universiteit Leuven
> Belgium
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
> How does the connection between the 2 component is made after generation ?
> is it hard coded in the c++ code ? or is the connection just at model level
> ?
>
We are only hard coding the ports. The connection is a ConnPolicy and
all the information is mapped to the deployment XML.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
> How does the connection between the 2 component is made after generation ?
> is it hard coded in the c++ code ? or is the connection just at model level
> ?
>
We are only hard coding the ports. The connection is a ConnPolicy and
all the information is mapped to the deployment XML.
-H
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
2011/8/19 Hugo Garcia <hugo [dot] a [dot] garcia [..] ...>
> > How does the connection between the 2 component is made after generation
> ?
> > is it hard coded in the c++ code ? or is the connection just at model
> level
> > ?
> >
>
> We are only hard coding the ports. The connection is a ConnPolicy and
> all the information is mapped to the deployment XML.
>
> -H
>
Does this generates also the xml deployment file ?
BRIDE: an Eclipse based MDE IDE for Orocos (Alpha)
2011/8/19 Hugo Garcia <hugo [dot] a [dot] garcia [..] ...>
> > How does the connection between the 2 component is made after generation
> ?
> > is it hard coded in the c++ code ? or is the connection just at model
> level
> > ?
> >
>
> We are only hard coding the ports. The connection is a ConnPolicy and
> all the information is mapped to the deployment XML.
>
> -H
>
Does this generates also the xml deployment file ?