To take a concrete example, when importing our legacy RSA-RTE
models i needed to extend the importer and to some m2m transform.
There I needed to change our own implementation of bidirectional
signals, two call events/operations with the same name, one in and
one out. There I need to delete one (D), update the other one with
information from the removed one (R+U), create a new IO RTMessage
(C).
I foresee other scenarios as well where more then reading will be
needed, e.g. custom editing functionality, refactoring, validation
with quick fixes etc
/Patrik
On 11/09/2016 08:13 PM, Ernesto Posse
wrote:
Hi Remi. Normally yes I see
that one would only need the R for codegen, but in our case we
do some transformations, in particular, we flatten the
inheritance hierarchy of both capsules and state machines, and
flatten the nesting composition of state machines. If we do
them in-place, we need at least CRU. If we just create copies,
we'll need CR only.
Cheers,
--
Ernesto
Just to understand one thing,
Ernesto: Why would you need CRUD operations for
codegen? I thought you were only reading the model for
code generation, not modifying it. Validation does not
need also modifying the model, only the R of the CRUD.
Regards,
Rémi
That's great. If you
can make them elementType-free, then I (and Patrik)
can use them. The last time I checked, those under
"core" didn't support the full range of CRUD
operations. Maybe we need them.
A question about the
oeprt.umlrt.uml plugin, just to clarify. The API
that codegen needs would be operations like
"isCapsule", "getCapsuleParts", etc, similar to
those found in the UMLRealTimeProfile class. This is
the API that you would like there, correct?
PS: I don't mind if it's pure
Java and not Xtend.
--
Ernesto
Hi,
Ernesto,
I
would like to pull some of these utility APIs
into the org.eclipse.papyrusrt.umlrt.uml plug-in
that I am beginning to work on. This should
provide not only the customization of the UML
semantics for UML-RT, but also the utilities
needed by transformations, validation, and other
applications to help them understand the meaning
of the UML content. This new bundle will
support the same deployment environments as UML2
and EMF, which basically means “pure Java”
without any Eclipse/OSGi dependencies.
On 9 November, 2016 at 11:49:22,
Ernesto Posse (eposse@xxxxxxxxxxxxx)
wrote:
Hi
Patrik. Some comments inline below.
To me the
issue is two fold.
First is the
general question of providing
'CRUD' methods for UML-RT that
could
be used for code generator, but
also for custom validation,
refactoring or other things that
a developer or tool smith would
use to work with a UML-RT model.
I see these as generic model
manipulation utilities that
should be separated for the
Papyrus-RT code generators all
together which the tool ought to
make available to developers and
tool smiths.
Right, as you
point out, we do have some of that
functionality, but it is split
between codegen and tooling, or more
precisely "core". The idea of the
"core" plugins was to provide that
sort of API (and you will find it
under oeprt.umlrt.core in the
oeprt.umlrt.core.utils package), but
the UMLRealTimeProfile class (and
the equivalent XtUML-RT ones) are
not part of these core plugins for a
reason: the elementtypes. These
"core" plugins rely on the
ElementType registry and that needs
the Papyrus runtime services active,
i.e. it only works when you are
running Papyrus. But as I mentioned,
one of our key requirements was for
codegen to be supported in
standalone, and because of this,
codegen does not use these 'core'
plugins and uses the ones that you
find in either the codegen or the
xtumlrt components. We've had quite
a few discussions on this, but
codegen does not and cannot use
anything that depends on the
elementtypes framework.
So I think it
makes sense to have the
non-elementtype-based API for UML-RT
in the core, but not in the current
core component, but a separate one.
Maybe we could create one called
'oeprt.umlrt.core.standalone' or
something like that.
The second
more specific question is that
I'd need to replace the RSA-RTE
UML-RT API calls in our legacy
code generators with something
working for Papyrus/UML-RT
models. I've started to go
though the code and don't have a
specific set of methods that are
required yet.
Do you have a
reference for this API? We do not
have access to that, so it would be
great and I could reproduce that
API.
Of course I
could make a third
implementation of this (beside
the elementType based solution
and what is currently in the
code gen) but that would bring
little benefit I assume and just
add maintenance cost.
As I said
above, codegen does not use an
elementType-based solution, and if
you use elementTypes, you won't be
able to run in standalone.
Actually
after sending the email I
realized that you've done some
refactoring already. I was first
looking at 0.72 code where the
UMLRTProfileUtil was
org.eclipse.papyrusrt.codegen.utils
(I think) but now has be moved
to
org.eclipse.papyrusrt.xtumlrt.external.
That one seems to have few
dependencies, the only thing I
stands out is extend but I guess
that just shows my lack of
understanding how you use xtend
in the Papyrus-RT code base.
That's correct.
The idea was that we are using for
codegen (and textual) an additional
metamodel called 'XtUML-RT'. It
contains just the core of UML-RT and
a few extras. It has an "Xt" in
front because we did this with
Ericsson Hungary and IncQuery Labs,
who are interested in xtUML, and we
were trying to come up with a
"common" meta-model. I'm not sure if
it was that successful or if they
are still using it.
But keep in
mind that the bulk of the
refactoring is not done yet. In
particular, the codegen plugins are
still tightly coupled with the
target language, and this is going
to be an essential part, but I think
that's not for 0.9 but for 1.0.
After all, we still have some
flexibility regarding APIs before we
leave incubation.
Nevertheless,
if you are working on code
generation, I would really like to
get more input from you as to what
you would like to see in our code
generator (besides the CRUD UML-RT
API) that may be useful to you. I
think it would be very useful in
determining the direction that we
take with the code generator.
One thing that
might interest you is looking at
that oeprt.xtumlrt.external package.
It is designed precisely to be able
to load models and profiles in
stand-alone.
Any suggestions
for improvement (or gerrits) are
welcome ;)
As for Xtend
(more precisely Xtend2), I highly
recommend it. If you are not very
familiar with it, it's very easy to
learn for Java developers. You can
think of it as a layer of syntactic
sugar on top of Java, which makes it
much more readable and less verbose.
It also comes with a few constructs
that are extremely useful for code
generation, like "dispatch methods"
and "create methods". Part of the
appeal is that Xtend2 compiles into
source Java (rather than to
bytecode), so you can always see the
corresponding generated (readable)
Java, which is great when you are
learning the language (see the
'xtend-gen' folders). And this also
means that it is 100% compatible
with Java. You can call any Java
method from Xtend and viceversa, so
you can combine in any way and the
transition is smooth. You can take a
look at http://xtend-lang.org.
--
Ernesto
On 11/08/2016 05:28 PM, Ernesto
Posse wrote:
Hi
Patrick.
Yes,
indeed that we can and will
split the codegen feature.
It has been proposed (thanks
to Peter) to refactor the
code generator into
components for different
target languages, and have a
generic "core codegen" in
common.
I
already started some of this
refactoring, but it is not
there yet, and it is not in
the list of bugs for 0.9
which are the priority.
Nevertheless,
this generic codegen
component is supposed to
have a "skeleton" of the
code generator (there are
several alternatives,
perhaps a
Template method or
Strategy pattern or go
with an MWE2 workflow). In
the "core" component that
you'd like, would you
include that "generic" code
generator skeleton, or are
you looking for including
only core utility classes?
If the latter, then we
should have two "core"
components: one with the
generic codegen and the
other with just utilities.
By the way, which classes
would you like to see in
that component?
By the
way, the code generator can
be run stand-alone, as in
really stand-alone, i.e. no
Papyrus runtime service, not
even headless Eclipse, just
plain Java. See the
oeprt.codegen.standalone
plugin. (I spent quite a bit
of time on making this
work).
--
Ernesto
Posse
Zeligsoft
Hi,
A question regarding the
org.eclipse.papyrusrt.codegen.utils
plugin. It
ocontains some nice utils
I'd like to use for our
custom code genrator
etc but it is bundled into
the
org.eclipse.papyrusrt.codegen-feature
which includes a lot of
things that I don't need
and that just would
bloat our custom
installation.
Would it be possible to
split that feature into
two where one contains
the more generic utils etc
and the one the specific
Papyrus-RT code
generator details? If the
genric sould be a new
feature och part of core
or soemthing aready
existing, I don't know.
The important thing is
that these utils can be
used in standalone mode,
ie without the Papyrus
service runtime, something
that I understand also
is needed by the
Papyrus-RT C++ codegen.
/Patrik
_______________________________________________
papyrus-rt-dev mailing
list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery
options, retrieve your
password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options,
retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve
your password, or unsubscribe from this
list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|