We could introduce an EolParametricType subclass of EolType (with a collection of parameterTypes) and make EolCollectionType and EolMapType its subclasses. We could also make Tuples typed by modifying the following line of the EOL grammar and by making EolTupleType also a subclass of EolParametricType.

: (CollectionTypeName | MapTypeName)^

Installing the latest interim version on a clean Eclipse 2023-09 fails with the following error message

Cannot complete the install because one or more required items could not be found.
  Software being installed: Picto 2.5.0.202310161253 (org.eclipse.epsilon.picto.feature.feature.group 2.5.0.202310161253)
  Missing requirement: Picto 2.5.0.202310161253 (org.eclipse.epsilon.picto 2.5.0.202310161253) requires 'osgi.bundle; wrapped.net.sourceforge.plantuml.plantuml-epl 1.2023.11' but it could not be found
  Cannot satisfy dependency:
    From: Picto 2.5.0.202310161253 (org.eclipse.epsilon.picto.feature.feature.group 2.5.0.202310161253)
    To: org.eclipse.equinox.p2.iu; org.eclipse.epsilon.picto [2.5.0.202310161253,2.5.0.202310161253]

@alfonsodelavega can you reproduce this?

Originally posted by @kolovos in #59 (comment)

The following Flexmi models m1.flexmi and m2.flexmi

<?nsuri http://www.eclipse.org/emf/2002/Ecore?>
<?import m2.flexmi?>
<class name="C1" supertypes="C2"/>

<?nsuri http://www.eclipse.org/emf/2002/Ecore?>
<?import m1.flexmi?>
<class name="C2" supertypes="C1"/>

that refer to each other don't resolve references correctly and as a result the following ANT build file

<project default="main">
  <target name="main">
    <epsilon.emf.loadModel name="M1" modelfile="m1.flexmi" metamodeluri="http://www.eclipse.org/emf/2002/Ecore" read="true" store="false"/>
    <epsilon.emf.loadModel name="M2" modelfile="m2.flexmi" metamodeluri="http://www.eclipse.org/emf/2002/Ecore" read="true" store="false"/>
		
    <epsilon.eol>
      M2!EClass.all.first().eSuperTypes.name.println();

      <model ref="M1"/>
      <model ref="M2"/>
    </epsilon.eol>
  </target>
</project>

prints Sequence{} instead of Sequence{C1}.

When using the Eclipse installer, an option to locally clone repositories is shown at some point. If Epsilon is selected, the used urls are from "git.eclipse.org" instead of the new GitHub location.

Currently, @cached only supports 0-argument context operations, as the cache key only has the context object and the operation name. This is also done to limit the size of the cache: the current @cache is just a Java Map with no eviction policy (which guarantees that a @cached operation is only ever run once). Without an eviction policy, adding parameters to the cache key could dramatically increase the size of the cache if we are not careful.

It would be good to introduce an alternative configuration where @cached is backed by a Guava Cache instead of a Java Map, with a configurable bounded size and with an LRU eviction policy. This new approach could support operations with parameters, but would drop the guarantee that a @cached operation is only ever run once (as a less-used entry may be evicted at some point and may need to be recomputed).

To preserve backwards compatibility in Epsilon 2.x, we should keep the old no-eviction cache as the default behaviour. We may want to reconsider this default in a future 3.x release.

This issue would need both changing the EOL code, as well as extending the .dt plugins to allow for setting whether we want the old no-eviction cache (which only supports 0-arg operations), or the new LRU cache (which supports all operations).

I'm embedding Epsilon code into my application, and I found this strange behavior.

Following is a simplified version of my code that is meant to basically get the rules and execute them with a custom function:

public void executeRules(File rulesFile, Resource inputModel) {

	// Prepare the ECL Module
	module = new EclModule();

	module.parse(f);

	module.getContext().setOperationFactory(new EclOperationFactory());
	module.getContext().getModelRepository().addModel(inputModel);

	//perform other operations...

	// Find the rule
	Optional<MatchRule> ruleOpt = module.getMatchRules().stream()
  	.filter(r -> ruleName.equals(r.getName())).findFirst();

	MatchRule rule = ruleOpt.get();

	IEclContext context = module.getContext();

	MatchRule rule = ruleOpt.get();
	Lambda compiledRule = compiledRules.get(ruleName);
	Parameter otherParam = (Parameter) rule.getChildren().get(otherParamIndex);
	
	List<Object> other = rule.getAllInstances(otherParam, context, false)

	// THE PROBLEM IS HERE - It throws an exception indicating that the context’s module is null

	//more code to compile the rules with the lambda function

The current solution for this problem is after IEclContext context = module.getContext();, execute immediately context.setModule(module);. It solves the problem but looks like a workaround, not a solid solution.

Below is an example .ecl file that is used as input for this function as rulesFile

rule ruleName
match s : a!A
with t : b!B
{
    compare
    {
         return s.title = t.eContainer().title and s.name = t.eContainer().extraName;
    }
}

This same code (without the mentioned workaround, of course) was working before the update to Epsilon 2.4, so that is something new.

If it’s not a bug and it is indeed expected that the IEclContext object does not keep the reference to the EclModule after module.getContext(); it should be documented somewhere.

Eclipse version: Eclipse Modeling Tools Version: 2022-12 (4.26.0)
Epsilon: 2.4.0

I wrote an EVL script meant to be used within a Sirius diagram, and noticed it wasn't producing the expected errors. I turns out that I had an ambiguous NamedElement type reference in the script, which was being resolved to the Edapt NamedElement instead of my own NamedElement for a toy flowcharts metamodel. We should have issued a warning about this, instead of blindly going on with the first option.

We already have some code to detect ambiguous type references, but they only cover the case where different models have a match for the same name. They don't cover the case where a single model has multiple matches for the same name (quite common when running EVL scripts from Sirius, as the resource set has the full Eclipse package registry).

One issue is that the EMC API right now only has hasType(typeName): there's no checkAmbiguity(typeName) like what we have for the ModelRepository class. We need to extend that API to have its own version of this method for when the type name is ambiguous within a single model. We can provide a default implementation to ensure that existing EMC drivers continue to work without changes.

While trying to reproduce #67, I noticed that running this simple build.xml produced an error message:

<project default="main" xmlns:ivy="antlib:org.apache.ivy.ant">
  <target name="main">
    <epsilon.emf.loadModel name="ModelA"
      modelFile="TestModel.flexmi" 
      metamodelFile="metamodel.emf" 
      read="true" store="false" />
  <epsilon.emf.loadModel name="ModelB"
    modelFile="TestModel.flexmi" 
    metamodelFile="metamodel.emf" 
    read="true" store="false" />
  <epsilon.disposeModels />
</target>
</project>

The error message is as follows:

main:
[epsilon.disposeModels] Cannot find meta-class 'Element' in model 'ModelA'
[epsilon.disposeModels] 	at org.eclipse.epsilon.emc.emf.AbstractEmfModel.classForName(AbstractEmfModel.java:268)
[epsilon.disposeModels] 	at org.eclipse.epsilon.emc.emf.AbstractEmfModel.getCacheKeyForType(AbstractEmfModel.java:253)
[epsilon.disposeModels] 	at org.eclipse.epsilon.eol.models.CachedModel.removeFromCache(CachedModel.java:187)
[epsilon.disposeModels] 	at org.eclipse.epsilon.emc.emf.EmfModel.forceRemoveFromCache(EmfModel.java:318)
[epsilon.disposeModels] 	at org.eclipse.epsilon.emc.emf.EmfModel$CachedContentsAdapter.handle(EmfModel.java:243)
[epsilon.disposeModels] 	at org.eclipse.epsilon.emc.emf.EmfModel$CachedContentsAdapter.notifyChanged(EmfModel.java:186)
[epsilon.disposeModels] 	at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:424)
[epsilon.disposeModels] 	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.dispatchNotification(NotifyingListImpl.java:261)
[epsilon.disposeModels] 	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.clear(NotifyingListImpl.java:1099)
[epsilon.disposeModels] 	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.doUnload(ResourceImpl.java:1699)
[epsilon.disposeModels] 	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.unload(ResourceImpl.java:1721)
[epsilon.disposeModels] 	at org.eclipse.epsilon.emc.emf.CachedResourceSet$Cache.returnResource(CachedResourceSet.java:123)
[epsilon.disposeModels] 	at org.eclipse.epsilon.emc.emf.AbstractEmfModel.disposeModel(AbstractEmfModel.java:404)
[epsilon.disposeModels] 	at org.eclipse.epsilon.eol.models.CachedModel.dispose(CachedModel.java:312)
[epsilon.disposeModels] 	at org.eclipse.epsilon.workflow.tasks.DisposeModelsTask.executeImpl(DisposeModelsTask.java:20)
[epsilon.disposeModels] 	at org.eclipse.epsilon.workflow.tasks.EpsilonTask.execute(EpsilonTask.java:42)
[epsilon.disposeModels] 	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
[epsilon.disposeModels] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[epsilon.disposeModels] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[epsilon.disposeModels] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[epsilon.disposeModels] 	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
[epsilon.disposeModels] 	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
[epsilon.disposeModels] 	at org.apache.tools.ant.Task.perform(Task.java:350)
[epsilon.disposeModels] 	at org.apache.tools.ant.Target.execute(Target.java:449)
[epsilon.disposeModels] 	at org.apache.tools.ant.Target.performTasks(Target.java:470)
[epsilon.disposeModels] 	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
[epsilon.disposeModels] 	at org.apache.tools.ant.Project.executeTarget(Project.java:1374)
[epsilon.disposeModels] 	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[epsilon.disposeModels] 	at org.eclipse.ant.internal.core.ant.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:34)
[epsilon.disposeModels] 	at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
[epsilon.disposeModels] 	at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:712)
[epsilon.disposeModels] 	at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:532)
[epsilon.disposeModels] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[epsilon.disposeModels] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[epsilon.disposeModels] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[epsilon.disposeModels] 	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
[epsilon.disposeModels] 	at org.eclipse.ant.core.AntRunner.run(AntRunner.java:369)
[epsilon.disposeModels] 	at org.eclipse.ant.internal.launching.launchConfigurations.AntLaunchDelegate.lambda$0(AntLaunchDelegate.java:271)
[epsilon.disposeModels] 	at java.base/java.lang.Thread.run(Thread.java:829)

The build still passes, but it really should not be raising this error.

I keep getting a repository is not found, seems like GMF tooling is removed?

[2023-10-02 10:51:22] ERROR: org.eclipse.equinox.p2.metadata.repository code=1000 No repository found at http://download.eclipse.org/modeling/gmp/gmf-tooling/updates/releases.
at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.fail(AbstractRepositoryManager.java:405)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:119)
at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.fail(CachingRepositoryManager.java:388)
at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:279)
at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:520)
at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:110)
at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:105)
at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$RepositoryLoader$Worker.perform(ProfileTransactionImpl.java:1759)
at org.eclipse.oomph.util.WorkerPool$Worker.run(WorkerPool.java:437)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

This bug was originally reported in https://bugs.eclipse.org/bugs/show_bug.cgi?id=460540.

A patch was submitted but never merged.

In order to add arbitrary icons the icon annotation now accepts platform URIs for icon location. Thus, you can reference any icon in the worksapce or installation.

I have only tested with workspace references. The specficaion would be as follows (in emfatic):
@eXeed(icon="return 'platform:/resource/my.plugin/some/path/icon.gif';")
class MyIconClass {

}

Note that as opposed to the Exeed default icons the image extension has to be inlcuded.

I have been working on an Epsilon solution to the TTC 2023 KMEHR to FHIR case, and while porting their ATL transformation to ETL, I noticed that they had these nice #enum literals which did not require fully specifying the model and type (E*L would normally need Model!Type#enum).

We had discussed two approaches:

1. Treat it in the same way as type references, where we can give a warning if the partial reference is ambiguous.
2. Make property setters smarter, by having them check these partially-specified enum literals against the type of the field being set.

I thought option 2 would result in fewer risks of ambiguous references, but @kolovos raised the issue wouldn't translate well to multi-valued enum-typed fields. Looks like option 1 would be best for now.

This will need adding some acceptance tests, tweaking the E*L grammar, and changing how those enum literals are evaluated.

The recommended way to get the tag name of an XML element is to use the 'tagName' property, e.g.

var authors = b.children.select(a|a.tagName = "author");

When using java 11+, this will result in an exception:

Unable to make public java.lang.String com.sun.org.apache.xerces.internal.dom.ElementImpl.getTagName() accessible: module java.xml does not "exports com.sun.org.apache.xerces.internal.dom" to unnamed module @6f7b7657

This happens when the PlainXmlPropertyGetter delegates to the JavaPropertyGetter to resolve the Element#getTagName method, which eventually gets to ReflectionUtil#executeMethod which tries to make the getTagName() method accesible (failing do to the actual type of the element being "internal").

For this I suggest adding an additional 'if' condition to the PlainXmlPropertyGetter#invoke that catches access to the 'tagName' property and invokes the corresponding method directly on the element.

EGL supports defining "formatter" classes that post-process the generated code, ensuring it's more presentable:

https://www.eclipse.org/epsilon/doc/egl/#using-a-formatter

I cannot find any way to specify that a given EGX rule should use a certain formatter. I'll see if I can send a PR for this.

I'm working on an Epsilon solution for the TTC 2023 KMEHR to FHIR case, and I've noticed that our execution times increase very significantly from the second-to-last to the largest model:

A quick check with VisualVM shows we're spending 139s in the TransformationTrace.getTransformationTargets() method:

Looking at the method, it seems to have a similar issue to ECL's old MatchTrace, where it was using a simple loop over a list rather than a data structure which would scale better as models get larger.

A user reported that Picto would block the Eclipse UI while rendering the view. This is usually not a problem in most cases, as the local neighbourhoods that Picto usually displays shouldn't take long to render, but it can be an issue if the rendering uses an external tool which renders complex images (e.g. by calling the PlantUML libraries, which in turn spawns Graphviz processes).

I was able to reproduce the issue with this EGL script with a Thread.sleep:

[%
  // Simulates a slow EGL script
  var thread = new Native('java.lang.Thread');
  thread.currentThread().sleep(20000);
%]

<ol>
[% for (i in 1.to(10)) { %]
<li>line [%=i%]</li>
[% } %]
</ol>

We should refactor the code so the view rendering takes place mostly in a background job, and we only dip into the UI thread to show the rendered content. We already something like this for the EGX script which computes the tree, but not for EGL: any call to view.getContent() will trigger the execution of the EGL script if it hasn't been run already.

After an InMemoryEmfModel is disposed, the adapter(s) used to keep the cache updated are not removed. As a result, if the Resource used for the InMemoryEmfModel is modified, the model still receives notifications.

Trying to run a nested Eclipse instance with the latest version of our target platform produces several plugin validation issues (see below).

I have completed the development of emc-json, so it can now both write and read JSON files, and has options to specify HTTP headers when using an http:// or https:// URI. It would be good to port over the driver to the project.

The driver depends on a json-simple library which is rather old, but it hasn't really needed any fixes all this year as it is very simple. It has a ClearlyDefined score of 80 and it is Apache-licensed, so it should be OK to include. All its other dependencies were already in our target platform.

There seems to be a problem in loading models when loading flexmi models in a EUnit task. When I do that I get a Test test1 {} failed with status ERROR: Premature end of file. error. When I convert the models to xmi, the problem dissapears. I have made a small example where it happens. I'm using epsilon 2.4.0.

build.xml:

<project default="main" xmlns:ivy="antlib:org.apache.ivy.ant">
	<target name="main">
		<!-- test that the model is actually working -->
		<epsilon.emf.loadModel name="ModelA"
			    			modelFile="TestModel.flexmi" 
			    			metamodelFile="metamodel.emf" 
			    			read="true" store="false" />
		<epsilon.eol>
			<model ref="ModelA"/>
			ModelA!Element.all.first().Message.println();
		</epsilon.eol>
		<epsilon.disposeModel model="ModelA"/>
		
		<!-- does not work with flexmi files -->
		<epsilon.eunit src="test.eunit">
			<modelTasks>
	    		<epsilon.emf.loadModel name="ModelA"
	    			modelFile="TestModel.flexmi" 
	    			metamodelFile="metamodel.emf" 
	    			read="true" store="false" />
	    		<epsilon.emf.loadModel name="ModelB"
	    			modelFile="TestModel.flexmi" 
	    			metamodelFile="metamodel.emf" 
	    			read="true" store="false" />
			</modelTasks>
		</epsilon.eunit>
	</target>
</project>

Metamodel.emf:

@namespace(uri="NS", prefix="")
package NS;

class Element {
	attr String Message;
}

TestModel.flexmi:

<?nsuri NS?>
<Element Message="Some Message"/>

test.eunit:

@test
operation test1() {
  assertEqualModels("ModelA", "ModelB");
}

https://github.com/eclipse/epsilon/blob/273ae8e27c8afa7c947526d043ea18ad2b9f6845/plugins/org.eclipse.epsilon.workflow/ant/org/eclipse/epsilon/workflow/tasks/ExecutableModuleTask.java#L299C4-L299C4

During parsing, the ExecutableModuleTask will log any parse errors but then continue on without failing or throwing an exception. This happens even if failOnErrors is set to true.

I am suffering what Ed Willink labelled "metamodel schizophrenia" using the ANT tasks (but it also happens with the run configurations).
In the mwe, I have a small ETL that "lifts" a model to a metamodel. Thus the rules are of the form:

rule A2Class
    transform n : M!A
    to c : T!EClass { 
    ...

I also want to save the trace of the transformation using an ECore model. For this, I have created a metamodel that mimics the rules (this metamodel references the source metamodel):

class A2CLass extends Link {
    ref A source;
}
abstract class Link {
    ref EClass target;
}

To save the trace I add post processing in the ETL:

post {
	// Save trace
	var trace : new Trace!Trace;
	for (t in transTrace.transformations) {
		var link;
		switch(t.getRule().name) {
			case "A2Class":
				link = new Trace!A2Class;
			case "B2Class":
				link = new Trace!B2Class;
		}
		link.source = t.source;
		link.target = t.targets.first();
		trace.links.add(link);
	}
}

When running the transformation I get:

 The value of type 'org.eclipse.emf.ecore.impl.EClassImpl@a4d872b (name: A) (instanceClassName: null) (abstract: false, interface: false)' must be of type 'org.eclipse.emf.ecore.impl.EClassImpl@251e298c (name: A) (instanceClassName: null) (abstract: false, interface: false)'

which translates that the source metamodel is loaded twice as separate resources (once for the source model and once for the trace model).
I suspect this has to do with how each EMF model uses its own ResourceSet, but have not taken the time yet to dig deeper into the issue.
I have attached the MWE, with the ANT script that runs the ETL.
mwe.zip

As mentioned in the XML EMC page, all methods of the org.w3c.dom.Element should be available to elements of the PlainXML model.

However, in latest versions of Java, the ElementImpl' class that is under com.sun.org.apache.xerces.internal.domis no longer accesible via reflection. Thus, calls to any of the Element interface methods fails. The first case of this was reported in #5 (access to getTagName()), but further use has reveal the same issues when accessingappendChild()`. We imagine any other method calls will result in the same issue.

It would be good to add Export/Import buttons to the Profiler view that we have in Eclipse. At this point, once a profiling run has completed, there is no way to get the results out in a way that would support further data analysis, or explore the results from a previous run.

I tried using the profiler on an ETL script through the Java API, and found that the rule information was not being populated as expected. I could see the various profile targets in the tree, but noticed that no TransformationRules were being listed, only their guards and StatementBlocks.

Thinking it may be my use of the Java API, I tried running the example Flowchart2HTML transformation via the usual Eclipse launch configurations with profiling on (including the fine-grained profiling), and found it left the Rules tab empty as well.

I have found one possible fix, but I'm not sure the approach I followed is the best one in terms of design. I'll share it via a PR.

To reproduce this issue:

• Check out the org.eclipse.epsilon.examples.picto.socialnetwork example
• Comment out the Network2Graphviz rule in socialnetwork.egx
• Open socialnetwork.flexmi
• Select the Social Network tree item in the Picto view
• The following exception is produced

I am using an ECL script as part of the reference implementation for a TTC 2023 case.

I have noticed two things:

• Before I moved away from using compare to decide if there was a match (using a guard) instead, ECL was storing all matches (whether passing or failing) in its trace. This was significantly slowing it down as it uses the getMatch method to find if a match was already computed or not, and for a model with 50 containers I was getting 61k matches in total. This may be intended ECL behaviour, but it's an easy trap to fall into: in the end, I left compare as just true and used the guard for the actual check.
• While looking at getMatch, I notice that it loops over all matches, repeatedly testing if the match is for those two exact objects (Match#contains compares object identities directly). It'd be much faster to use two levels of IdentityHashMaps for this.

The builds are failing which made me notice:

https://ci.eclipse.org/oomph/job/setup-archiver/lastBuild/

I expect these git clone tasks don't work properly either:

They should look more like this:

Generally it's a good idea to change the id of each git clone tasks so that the old/out-dated recorded values in the user.setup are not reused. Make sure you change all the reference to that ID via induced variable if you do that.

As reported in this forum post, the following code fails as Files.copy(...) defines a varargs parameter, and ReflectionUtil.searchMethodsFor(...) doesn't support varargs.

var a = new Native("java.io.File")("a").toPath();
var b = new Native("java.io.File")("b").toPath();
var Files = Native("java.nio.file.Files");
Files.copy(a,b);

The error message produced in such cases is quite confusing:

Invalid number (or types) of arguments for operation 'copy': expected 'java.nio.file.Path, java.nio.file.Path, java.nio.file.CopyOption[]' but got 'org.eclipse.epsilon.eol.dom.NameExpression, org.eclipse.epsilon.eol.dom.NameExpression'
	at (/Users/dk135/Dev/Eclipse/eclipse-2020-06/runtime-EclipseXtext/native-test/native-test.eol@4:0-4:16)
	at (/Users/dk135/Dev/Eclipse/eclipse-2020-06/runtime-EclipseXtext/native-test/native-test.eol@4:0-4:16)
	at (/Users/dk135/Dev/Eclipse/eclipse-2020-06/runtime-EclipseXtext/native-test/native-test.eol@1:0-4:16)
	at (/Users/dk135/Dev/Eclipse/eclipse-2020-06/runtime-EclipseXtext/native-test/native-test.eol@1:0-4:16)

This is because, if everything else fails, we end up in DynamicOperation.execute(...), while we shouldn't in this case.

Copying @SMadani as the original developer of DynamicOperation.

I have two metamodels MMA and MMB. MMB extends all EClasses in MMA (MMB is a wrapper for MMA). I have a generic Picto egl->graphviz template that uses dynamic EMF to draw a containment hierarchy tree of models. When loading models that conform to MMA or MMB the tree is not being built.

The issue is that eObject.eClass.eAllReferences is retruning emtpy for the root element of each model. However, in MMA this should be 4 and in MMB 5 EReferences. I added the statement self.eClass.eSuperTypes.size().println("sts: ") to the template and it produces unexpected results (Epsilon console):

• Normal mode:
  no parent true eClass: Gateway sts: 0 no parent true eClass: Gateway_fgm sts: 1 no parent true eClass: Gateway sts: 0 no parent true eClass: Gateway_fgm sts: 1 no parent true eClass: Gateway sts: 0 no parent true eClass: Gateway_fgm sts: 1 allRefs: 1

• Standalone mode:
  no parent true eClass: Gateway sts: 0 allRefs: 0

My gut feeling is that it is a caching issue and/or the way the java property getter resolves the methods.

I have added a MWE
with three projects. Two with the metamodels (ca.mcmaster.workbench.deep.dsl and ca.mcmaster.workbench.fgm.deep) and one with the models and picto files. To reproduce load the metamodels in a ws and the models in a nested ws.

I also added a junit test that checks the eclass supertypes and eAllReferences sizes that shows that Epsilon is acting up.

Description

When importing an EOL script into ETL, the Special Assignment Operator semantics are not respected when executing the code in the EOL script.

Example

// ETL
import "helper.eol"
rule AB
  transform a:A
  to b:B {
  b.ref = createC(a); 
} 
----

// helper.eol
operation createC(a:A) return C {
  var c = new C;
  c.other ::= a;
  return a;
}

Current Behavior

The statement c.other ::= a, will try to assign a to c.other, resulting in a cast error.

Expected Behavior
The statement c.other ::= a, will assign a's equivalent to c.other.

In this example, referring to p1 in the TaskLeader pattern should throw an exception but it doesn't because presumable the variable leaks from the Collaborators pattern.

// Find pairs of people that work
// on at least one common task
pattern Collaborators
	p1, p2 : Person {

	match: Task.all.exists(t|t.effort.person.
		includesAll(Sequence{p1, p2}))
}

// Pair tasks with their leaders
pattern TaskLeader 
	t : Task,
	p : Person from: t.effort.person {

	match: t.effort.sortBy(e|-e.percentage).
		first()?.person = p1 
}

There is currently no way to run Pinset programs from Ant.

Running this code with EplModule produces a complete stack trace as shown below:

Type 'Person1' not found
	at (unknown@4:10-4:17)
	at (unknown@3:0-8:1)
	at (unknown@4:10-4:17)
	at (unknown@3:0-8:1)

Running the same code with EplModuleParallelPatterns only produces the first line:

Type 'Person1' not found

Tentatively assigning to @SMadani as the original developer of EplModuleParallelPatterns.

When adding a new EMF model with multiple URIs, it is tedious to have to add one. It would be good if multiple URIs could be selected and added.

Trying to embed views which are not valid XML in other Picto views fails at the moment as reported in this forum post. A minimal example with a standalone Picto file and two custom HTML views follows.

<!--example.picto-->
<?nsuri picto?>
<picto standalone="true">
	<view path="Root, View1" format="html" source="view1.html"/>
	<view path="Root, View2" format="html" source="view2.html"/>
</picto>

<!--view1.html-->
View 1

<!--view2.html-->
<html>
<h1>View 2</h1>
<picto-view path="Root, View1"/>
</html>

Trying to render Root/View2 produces a Content is not allowed in prolog. error message in Picto because view1.html is not valid XML.

To fix this we could try to parse the content of the view to embed as XML and if this fails, put it in an iframe instead.

It would also be nice to support a custom iframe attribute in <picto-view> elements to allow the user to force an iframe (e.g. if the other view is XHTML but the user doesn’t want its CSS/JavaScript to mess up the host page’s style/functionality).

Bug

The epsilon.for Ant task will execute once with the it property set to empty string when the fileset has no matching files.

Desired behaviour

The epsilon.for Ant task should not execute if the fileset has no matching files

Cause

If the fileset has no matching files, the task's getFiles() method returns a string array with one element, an empty string, instead of return an empty array

After the following ANT build file

<project default="main">
	<target name="main">
		<epsilon.emf.loadModel name="M1" modelfile="m1.ecore" metamodeluri="http://www.eclipse.org/emf/2002/Ecore" read="true" store="false"/>
		<epsilon.emf.loadModel name="M2" modelfile="m2.ecore" metamodeluri="http://www.eclipse.org/emf/2002/Ecore" read="true" store="false"/>

		<epsilon.eol>
			M1!EClass.all.first().eSuperTypes.println();
			M2!EClass.all.first().eSuperTypes.println();
			<model ref="M1"/>
			<model ref="M2"/>
		</epsilon.eol>

	</target>
</project>

is executed against the following models m1.ecore and m2.ecore that reference each other, the models are not disposed properly. As a result, if we re-execute the same build file in the same JVM, the contents of m2.ecore are not loaded from disk the second time.

<?xml version="1.0" encoding="ASCII"?>
<ecore:EClass xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmi:id="_rnSosFwLEe2eQLwPX_T8WQ" name="C11">
  <eSuperTypes href="m2.ecore#/"/>
</ecore:EClass>

<?xml version="1.0" encoding="ASCII"?>
<ecore:EClass xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmi:id="_sBzacFwLEe2eQLwPX_T8WQ" name="C221">
  <eSuperTypes href="m1.ecore#/"/>
</ecore:EClass>

A workaround for this is to add the following JavaScript task to the build file to clear the EMF driver's resource cache.

<script language="javascript">
with(new JavaImporter(org.eclipse.epsilon.emc.emf)){
  CachedResourceSet.getCache().clear();
}
</script>

Running Epsilon's plugged-in tests from Maven using

mvn -f tests/org.eclipse.epsilon.test verify -P plugged

produces the following error, which seems to be related to the new JSON driver

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: org.eclipse.epsilon.test 2.5.0.qualifier
[ERROR]   Missing requirement: org.eclipse.epsilon.test 2.5.0.qualifier requires 'osgi.bundle; org.eclipse.epsilon.emc.json.test 0.0.0' but it could not be found

I'm using Maven 3.9.5 to match the version we use in the CI build.

Currently PictoTests passes when launched as a plugged-in test but fails when it is included in the SuiteClasses of EpsilonPluggedInTestSuite, as SocialNetworkTests.testSocialNetwork() uses a relative file path to load ecore/socialnetwork.picto.

I have found an issue (and a potential solution) with Picto in Windows that I want to test further.

To reproduce:

1. In an Eclipse instance with Epsilon installed, import org.eclipse.epsilon.examples.picto.ecore , open any .ecore file and the Picto window
2. A visualisation should appear, if the Stats view is selected in the tree, it might appear blank
3. (same with 3D inheritance)

The current solution I found: add -Dorg.eclipse.swt.browser.DefaultType=edge to the eclipse.ini file of your Eclipse instance.

Another solution could be to detect if Windows is the OS in use and then instantiate the Browser in Picto with the SWT.EDGE option (similar SWT.WEBKIT exists for Os X, and other deprecated options as well). Info: https://github.com/eclipse-platform/eclipse.platform.swt/blob/19c5bc83ae72e7d31767a1b4575511d148975794/bundles/org.eclipse.swt/Eclipse%20SWT/common/org/eclipse/swt/SWT.java#L2572

Similar to %!TEX root in LaTeX.

I tried writing some Flexmi files in YAML format today, using this custom metamodel:

queryset-metamodel.zip

I tried writing this bit:

?nsuri: https://eclipse.org/hawk/sqlite/queries
queryset:
  name: NonTimeawareQueries
  queries:
    - name: "nodeIDsByLabel"
      sql: "SELECT rowid FROM nodes WHERE label = ?;"
      parameters:
        - name: label
          type: String
    - name: "nodeCountByLabelStatement"
      sql: "SELECT COUNT(1) FROM nodes WHERE label = ?;"
      parameters:
        - name: label
          type: String

I expected to see one QuerySet with its proper name and two queries, each with their own name and parameters. This is in line with typical use of YAML, which supports three types of nodes: maps (essentially, objects), sequences (lists), and scalar values. I had expected to see maps turned into objects, sequences turned into ELists, and scalar values to be used to set attributes / references.

Unfortunately, I got something rather odd instead:

I had one Query with two parameters, for some reason.

I had to change the YAML file to this, which is cumbersome to type with all the -s, and it's also not natural YAML:

?nsuri: https://eclipse.org/hawk/sqlite/queries
queryset:
  - name: NonTimeawareQueries
  - query:
    - name: "nodeIDsByLabel"
    - sql: "SELECT rowid FROM nodes WHERE label = ?;"
    - parameters:
        - name: label
        - type: String
  - query:
    - name: "nodeCountByLabelStatement"
    - sql: "SELECT COUNT(1) FROM nodes WHERE label = ?;"
    - parameters:
        - name: label
        - type: String

That produced the expected outline:

From a semantic point of view, it doesn't make sense to have queryset need to contain a list with its first element being a map whose key is name just to set the name of that queryset. Same goes for specifying its child objects.

We had a question today from a user on how to customise the EMF load and save options for their EmfModel. Our website says this cannot be done, but we do have methods for it in EmfModel since version 2.3.0.

The issue is that this functionality is not exposed from the developer tools, and it cannot be used via typical string properties as we do for other options. This would need to be exposed in some way, but we'd have to find some way to encode the map of options (which may have non-string values) into the StringProperties we normally use.

Once this is corrected, we should also update the Epsilon website, specifically these two articles:

https://eclipse.dev/epsilon/doc/articles/epsilon-emf/
https://eclipse.dev/epsilon/doc/articles/in-memory-emf-model/

I have been trying to write an up-to-date clone if this repo to my machine on wsl, and I got it to run on simulation. Following the tutorial at https://www.numworks.com/resources/engineering/software/build/ I gave up on wsys2 with too much errors, but now on linux I got it running with make PLATFORM=simulator epsilon_run. The issue rn is when I try to write to my calculator like the article says with python3 build/device/dfu.py -s 0x90010000:leave -D output/release/device/n0110/userland/userland.A.dfu, it says I'm missing the dfu which is obvious, so I tried to build it with make userland.A.dfu, but that gave me the error of:
make userland.A.dfu QSTRDAT python/port/genhdr/qstrdefs.generated.h HOSTCC kandinsky/fonts/rasterizer RASTER kandinsky/fonts/SmallFont.cpp RASTER kandinsky/fonts/LargeFont.cpp HOSTCC escher/image/inliner APPSLYT apps/home/apps_layout.h I18N apps/i18n.h CXX apps/apps_container.o CXX apps/apps_container_helper.o CXX apps/apps_container_launch_default.o CXX apps/apps_container_prompt_none.o apps/apps_container_prompt_none.cpp: In static member function 'static void AppsContainer::__static_initialization_and_destruction_0(int, int)': apps/apps_container_prompt_none.cpp:5:15: warning: statement has no effect [-Wunused-value] 5 | const KDColor AppsContainer::k_promptColors[] = {}; | ^~~~~~~~~~~~~ CXX apps/apps_container_storage.o CXX apps/apps_window.o ... CC python/src/py/unicode.o CC python/src/py/vm.o CC python/src/py/vstr.o CC python/src/py/warning.o LD userland.A.elf arm-none-eabi-gcc: error: ASSERTIONS=0: No such file or directory make: *** [build/rules.mk:83: output/release/device/n0110/userland/userland.A.elf] Error 1 the file is just plainly missing, and I have no idea what to do after googeling away.

Working on the TTC KMEHR to FHIR case today, I noticed that the benchmark driver in its reference solution, transforms a File into a Resource, rather than a File to a File. This is done so the "Run" phase of the measurements does not include the time used in saving the model.

To make results comparable, I decided to make the same change, and have the ETL transformation go from an EmfModel to an InMemoryEmfModel. When I did that, however, I noticed it significantly slowed down. VisualVM points to the maintenance of the allContents cache:

This wasn't an issue with EmfModel. It turns out that at some point, I added some code to register CachedContentsAdapters automatically in the initialisation of InMemoryEmfModel. I wonder why I didn't check whether caching was enabled or not at that time - I can't remember at the moment.

Later on, Sina changed the code to just use setCachingEnabled(true), which performs the same work but is also consistent with the cached flag. This is after a commit where he fixed EmfModel::setCachingEnabled to add/remove the CachedContentsAdapter itself (as it should have).

Looking at this again, I wonder if we should drop this altogether from InMemoryEmfModel, and just let users decide if they want to turn on caching or not by themselves:

  // Since 1.6, having CachedContentsAdapter implies cached=true, otherwise it's inconsistent.
  setCachingEnabled(true);

As reported in this forum post, there's no way to run EMG from Ant. We need to add an EmgTask that extends EplTask here.

The PlantUML version available in Eclipse Orbits is outdated (1.2019) and lacks the recent improvements in PlantUML rendering included by the maintainers (e.g. see this). The same PlantUML version is maintained in more recent Orbits than the one we have in the target platform (such as the latest 2022-12 one)

Does anyone know what is the proper way to upgrade the Orbit version? I'm currently using the update site PlantUML authors provide for their Eclipse plugins in a local target platform, and so far it works fine.

I think this relates to Epsilon because we're probably the only ones using that feature (seems that @SMadani added it).

Migrating an Ecore metamodel using an empty Flock transformation does not copy enumeration literals correctly as reported in this forum post. A minimal example that demonstrates this behaviour is attached.
flock-enum-bug.zip

@louismrose Fancy having a look into this?

EGL supports a special marker comment that starts with [*- instead of [*. Currently, marker comments produce excess whitespace. For example

[*-Marker*]
[%="test"%]

produces

test

while the regular comment version

[*Marker*]
[%="test"%]

produces (the expected)

test