For your last scenarii, this is typically the kind of situation where I would rather advise to have Papyrus services started. You won’t be able to work only with
java/EMF/UML2, especially if you want to customize /extend existing customizations. For example, validation with quick fixes may not happen outside of Eclipse. For the sample modification you want to perform when importing/updating your models, base UML edition
may be sufficient. Also some of the basic utilities, like computing names, may be placed in that area.
For the codegen and probably some other kind of actions on the model, I do agree it would be useful to have a lightweight core plugin. But IMO adding more than
(R)eading abilities to this plugin would be very dangerous for further customization and consistency aspects.
Cheers,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
 www.eclipse.org/papyrus
De : papyrus-rt-dev-bounces@xxxxxxxxxxx
[mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Patrik Nandorf
Envoyé : jeudi 10 novembre 2016 16:16
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Split the org.eclipse.papyrusrt.codegen-feature?
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.
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.
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.
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).
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
|
