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