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