Re: [papyrus-rt-dev] Reusing the core component

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

Hi Christian,

Sorry, I still don't see the value very well. If you need to check that an element is an RTPort, doesn't it suffice to check that it is an instance of Port and has the RTPort stereotype? And if what you need to do is to check that it is a wired port, isn't it enough to check that it is an RTPort that has isWired set to true? Or is the idea that you have an EObject but somehow it doesn't have an EClass that you can use to check, or that it may have a different EClass but still conforms to the various criteria you are looking for?

I understand the idea of a general "matcher" to abstract all kinds of checks for different criteria, but for example, why use this matcher instead of say, Hamcrest's Matcher [1] (which by the way is in Orbit)? 

The ElementTypeUtil.matches uses a String id for the type of the element to obtain the actual type from an ElementTypeRegistry (from GMF). Who adds types to that registry? Is it Papyrus or the Papyrus-RT Tooling?

The stand-alone generator runs as a simple Java app, so no headless Eclipse, and therefore no extensions. I would be very interested in seeing how to use extensions without an Eclipse runtime, since that also limits the availability of user-defined generators in stand-alone. Do you have any links to point me to the use of extensions in pure Java apps?

[1] http://hamcrest.org/JavaHamcrest/javadoc/1.3/org/hamcrest/Matcher.html 

On Fri, Jun 10, 2016 at 11:26 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Ernesto,

I can provide some background about the usage of element-types, but that’s about it.

The element-types are more generalized than UML metaclass and stereotype extension information.  Their matchers can also inspect an element’s properties, related elements, and whatever else to determine whether the element conforms to the abstract “type” that the element-type represents.  For example, the various specializations of the RTPort element-type match on values of the ‘isService’, ‘isWired’, and other attributes.  So, relying on the types for queries like these utilities ensures a degree of future-proofness on potential evolution of these conformance conditions.

As far as run-time dependencies are concerned, the element-types are in a layer of GMF that doesn’t require the UI (and certainly not diagrams), but all of the registries are loaded from extension points (even the modelled element-type configurations), so it would take a bit of effort to make it work in an Eclipse-free context.  Does the code generator run in an (headless) Eclipse instance?  Or as simply as a Java app?  EMF has demonstrated that it is possible to process simple plugin.xml extensions without the Eclipse run-time, but I don't know that there aren’t more dependencies in GMF on the platform that would make it more difficult.

HTH,

Christian

On 10 June, 2016 at 11:08:23, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

Hi. I have some questions for the developers of the "core" component. I'm not sure who wrote them. Was it Remi, Céline, or someone else?

Anway, the core component contains several utilities that are intended to be reusable by both tooling and codegen, but currently codegen doesn't use them because when we were developing, the core utilities were not yet available at the time.

I'm now assessing the changes required in codegen to reuse the core utilities.

Right now it looks like there is an overlap between the *Utils classes in oeprt.umlrt.core.utils and the UMLRealTimeProfile and to some extent the UMLRealTimeStateMachProfile classes in oeprt.codegen.util.

I think some of these could be unified, but I don't understand some of the rationale behind the implementation of some utilites in core. For example, take the CapsulePartUtils class. It has a method

public static boolean isCapsulePart(final Property property) {

return ElementTypeUtils.matches(property, IUMLRTElementTypes.CAPSULE_PART_ID);

}

and in UMLRealTimeProfile we have

public static boolean isCapsulePart(Element el) {

Stereotype s = el.getApplicableStereotype(UML_REAL_TIME_CAPSULE_PART);

return s != null && el.isStereotypeApplied(s);

}

The first question is why the core method has a more narrow parameter type? Is it expected that the caller ensures that it is invoked only on Property elements?

The second question is why does it use ElementTypeUtils.matches? What are the advantages of using that method instead of a standard UML stereotype lookup? Looking at its implementation, it uses classes from GMF. Is this dependency strictly necessary? My concern here is that the code generator should also run in stand-alone mode, and I don't want to bring GMF as an additional dependency there.

Thanks

--

Ernesto Posse

Zeligsoft

_______________________________________________
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