EOL - Accessing Derived Attributes? [message #1082491] |
Thu, 08 August 2013 16:44 |
Philip Makedonski Messages: 10 Registered: May 2013 |
Junior Member |
|
|
Hi Folks, so far Epsilon has been pretty amazing, but I seem to be hitting the odd issue every now and then. Current problem is with derived attributes (derivation specified via OCL, e.g. (from OCLinEclipse editor):
class Value
{
attribute name : String[?] { derived }
{
derivation: ofAttribute.name;
}
attribute content : ecore::EDouble[?];
property ofAttribute : Attribute;
}
class Attribute
{
attribute name : String[?];
property artifactTypes : ArtifactType[*];
}
which is a simplified example of more complex derivations.
When accessing a model instance through EOL (I guess through ETL and others as well), e.g. via:
("Value of "+Value.allInstances().first().name+" is "+Value.allInstances().first().content).println();
the name of the value is empty. When accessing the model instance through other means (tree editors, exceed, facet browser, etc.), the values are correctly derived.
My question is two-fold:
1. Does Epsilon even support derived values? (so far I haven't found any evidence supporting or rejecting this)
2. If yes, how do I access them in Epsilon languages?
I could also do the derivations by means of transformations if there is absolutely no other way, but I figured if it worked for other tools it would make some things easier if the derivations are baked into the meta-model, as the derived values are indeed based on other values within a model instance and may change as the model instance changes (e.g. the name of an attribute changes in the above example or a different attribute is used).
Thanks in advance!
|
|
|
Re: EOL - Accessing Derived Attributes? [message #1083012 is a reply to message #1082491] |
Fri, 09 August 2013 10:40 |
|
Hi Philip,
We use standard EMF facilities to access attributes, so they should work. If they don't, that's a bug.
I've tried creating a simple metamodel based on your example, using regular Java code to implement the derived attribute Value#name. I've attached two .zip files with the projects for the metamodel and the EOL script and launch configuration.
The launch configuration works fine for me: it prints something like "Value test: contents 42.0". As in your example, the name of the Value is derived from the name of the Attribute.
Does this example work for you as well? If it does, there might be something special in the way OCL is used to specify derived attributes that we need to support somehow. A bug report and a minimal example which reproduces the problem would help us a lot with fixing the problem.
Best regards,
Antonio
|
|
|
Re: EOL - Accessing Derived Attributes? [message #1083067 is a reply to message #1083012] |
Fri, 09 August 2013 12:22 |
Philip Makedonski Messages: 10 Registered: May 2013 |
Junior Member |
|
|
Hi Antonio,
thanks for the quick response! I've tried the supplied examples, and while you used a different derivation mechanism (based on adapting the generated Java code itself, which I guess shouldn't really matter for the time being), for me it doesn't work - the output is just "Value : 42.0". Any suggestions where to look for it next?
I'm running:
Eclipse Platform 4.3.0.I20130605-2000
EPP Modeling Feature 2.0.0.20130613-0530
Epsilon Core 1.0.0.201307120854 (and all other Epsilon components)
...and a number of other plugins and features
All other tools and editors I've tried so far seem to work as expected. Yesterday, I tried Acceleo (which is similar to EGL), which worked with the exact same template (besides the syntactical difference), but EGL did not.
Now upon further investigation, however, I discovered that your example does, in fact, work, IF ran into an Eclipse Application instance (which has the corresponding workspace plug-ins loaded), but does not if ran directly within the running host Eclipse Instance (i.e. using a dynamic model instance).
A couple of things I noticed:
1. OCL-derivation works for most tools in both host and application instances
2. Java-derivation in generated code works (obviously) only in an application instance
3. Epsilon-based scripts work with dynamic instances in the host but do not seem to support derived attributes
4. Epsilon-based scripts support derived attributes (OCL or Java -based) in an application instance
As mentioned other tools seem to work fine with derived attributes directly in the host Eclipse Instance as well using a dynamic model instance.
I guess this changes my initial question a little to:
Is it is possible to work with derived attributes in the host Eclipse instance using dynamic model instances or is it a known (current) limitation of Epsilon? Or am I doing something completely wrong.
I hope I made my situation a bit clearer.
|
|
|
Re: EOL - Accessing Derived Attributes? [message #1083244 is a reply to message #1083067] |
Fri, 09 August 2013 17:39 |
Philip Makedonski Messages: 10 Registered: May 2013 |
Junior Member |
|
|
OK, after fiddling around for a while, I somehow managed to get it to work. Maybe my initial tests were incorrect, but after observing all sorts of odd behavior and failing tests started to pass for no obvious reason, it may just as well be the weather. Disregard the findings about OCL-based derivation above.
One issue seems to persist, however:
- When using a native (EOL-Program) launch configuration the results are correct.
- When using an Ant-based launch configuration the results are also correct.
- BUT, when using a standalone Java-based launch configuration (adapted from /org.eclipse.epsilon.examples.standalone/src/org/eclipse/epsilon/examples/standalone/eol/EolStandaloneExample.java by setting the correct meta-model, model-instance, and EOL script locations), derived attributes are still not shown properly for some reason. Is this mechanism for launching up-to-date or am I missing something?
|
|
|
Re: EOL - Accessing Derived Attributes? [message #1083848 is a reply to message #1083244] |
Sat, 10 August 2013 16:00 |
|
Hmm, I don't recall us making any change that would break existing standalone Java code, but dynamic models have always been somewhat complicated to set up.
Could you send me your example so I can have a look at it? If it has sensitive information, you could send it to our support email address at epsilon dot devs at gmail dot com instead.
|
|
|
Powered by
FUDForum. Page generated in 0.03943 seconds