| Re: [papyrus-rt-dev] Split the org.eclipse.papyrusrt.codegen-feature? |
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.
cW_______________________________________________On 9 November, 2016 at 11:49:22, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Hi Patrik. Some comments inline below._______________________________________________
On Wed, Nov 9, 2016 at 3:41 AM Patrik Nandorf <patrik.nandorf@xxxxxxxxxxxx> wrote: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/Patrik
_______________________________________________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 PosseZeligsoft
On Tue, Nov 8, 2016 at 4:20 AM Patrik Nandorf <patrik.nandorf@xxxxxxxxxxxx> wrote: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