Split from #7

Name-based structural typing works well for evolution. However, mapping independently developed DSLs rarely works out-of-the-box.

Melange should support adaptation specification, at least through renaming, ideally with advanced mapping expressions. Some scenarios can be supported by derived attributed inserted through aspects. In a lot of other cases, an OCL-like expression can express the relationship between features of two different DSLs.

In such a case, it is the role of the adapters to effectively realize the adaptation. The mapping expression must be compiled in the adapter's code.

It's currently tricky to reuse aspects definition when inheritinig from a super-metamodel / metamodel trait.

Inheritance differs from merge operator by enforcing the subtyping relation between the sub-metamodel and its super-metamodel. However, subtyping can be broken e.g. if new mandatory references are inserted in the sub-metamodel. We should check that the subtyping is preserved when inheriting.

Just like EMF uses URI and a registry to identify metamodels, Melange should manage its own registry of languages (incl. their aspects, etc.) meant to be used by other tools.

when creating a melange language from 2 ecore files that merge, the outline isn't correct.

on my melange file

package org.gemoc.sample.tfsm.ed

language TFSM_ExecutionData {
    syntax "platform:/resource/org.gemoc.sample.tfsm.ed/model/tfsm_ed.ecore"
    syntax "platform:/resource/org.gemoc.sample.tfsm.model/model/tfsm.ecore"

/*
 *  with qualified.class.name
 */

    exactType TFSM_ExecutionDataMT
}

It correctly shows the added class (Toto in the screenshot) but not the added attributes (currentState on TFSM in the sample)

the model Type seems to be correct.

also note that the generate all, will generate errors on TFSMAdapter and FSMClockAdapter which seems related to a similar issue...

ecore_files.zip

If we define a public attribute of type List in an aspect on a Metaclass,
Melange generates a setter in the Adapter side but not in the ModelType side

curently the projet that contains the extended metamodel runtime code use the following pattern
ExtendedRuntime for the project

however, such project usually use a more complex naming scheme with for example org.company ...

We need to use a better default search location which would try to mimic the user schema.
In addition, we need a means to let the user specify where this runtime is located. (in order to customise it if the default schema doesn't suit the user's need)

It would be handy to be able to enable/disable the most time-consuming tasks (Eclipse projects generation, interfaces serialization, etc.) through a dedicated Eclipse Preferences page.

when creating the runtime for a language that use K3 aspect with dependency to other eclipse project, the depency is not copied to the runtime project

Currently, a transformation can only be applied on models typed by the interface it specifies.

Multiple inheritance should be supported with a well-defined semantics (e.g. no conflict or left/right-linearization):

metamodel X { ... }
metamodel Y { ... }
metamodel Z { ... }

metamodel A inherits X, Y { ... }
metamodel B inherits Y, Z { ... }
metamodel C inherits A, B { ... }

The "Generate EMF runtime in a new project" quickfix on inheritance-based metamodels complains about impossible serialization. We don't want to re-serialize the concrete syntax file after the quickfix so the behavior is OK, but we should avoid such nasty exceptions.

org.eclipse.emf.common.util.WrappedException: org.eclipse.xtext.validation.IConcreteSyntaxValidator$InvalidConcreteSyntaxException: These errors need to be fixed before the model can be serialized.
ModelTypingSpace'inheritancefsm'.elements[2]->Metamodel'ExecFsm': The feature Metamodel.exactType contains non-transient values but has no corresponding assignment in rule Element.

    at org.eclipse.xtext.ui.editor.quickfix.IssueResolution.apply(IssueResolution.java:78)
    at org.eclipse.xtext.ui.editor.quickfix.QuickAssistCompletionProposal.apply(QuickAssistCompletionProposal.java:32)
    at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertProposal(CompletionProposalPopup.java:968)
    at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertSelectedProposalWithMask(CompletionProposalPopup.java:914)
    at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$27(CompletionProposalPopup.java:910)
    at org.eclipse.jface.text.contentassist.CompletionProposalPopup$5.widgetDefaultSelected(CompletionProposalPopup.java:674)
    at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:119)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4454)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3799)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3409)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
    at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
    at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Caused by: org.eclipse.xtext.validation.IConcreteSyntaxValidator$InvalidConcreteSyntaxException: These errors need to be fixed before the model can be serialized.
ModelTypingSpace'inheritancefsm'.elements[2]->Metamodel'ExecFsm': The feature Metamodel.exactType contains non-transient values but has no corresponding assignment in rule Element.

    at org.eclipse.xtext.serializer.impl.Serializer.serialize(Serializer.java:96)
    at org.eclipse.xtext.serializer.impl.Serializer.serialize(Serializer.java:122)
    at org.eclipse.xtext.serializer.impl.Serializer.serializeReplacement(Serializer.java:138)
    at org.eclipse.xtext.ui.editor.model.edit.DefaultTextEditComposer.getObjectEdits(DefaultTextEditComposer.java:167)
    at org.eclipse.xtext.ui.editor.model.edit.DefaultTextEditComposer.getTextEdit(DefaultTextEditComposer.java:142)
    at org.eclipse.xtext.ui.editor.model.edit.DefaultTextEditComposer.endRecording(DefaultTextEditComposer.java:126)
    at org.eclipse.xtext.ui.editor.model.edit.ReconcilingUnitOfWork.exec(ReconcilingUnitOfWork.java:54)
    at org.eclipse.xtext.ui.editor.model.edit.ReconcilingUnitOfWork.exec(ReconcilingUnitOfWork.java:1)
    at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:418)
    at org.eclipse.xtext.ui.editor.model.XtextDocument.internalModify(XtextDocument.java:131)
    at org.eclipse.xtext.ui.editor.model.XtextDocument.modify(XtextDocument.java:124)
    at org.eclipse.xtext.ui.editor.model.edit.SemanticModificationWrapper.apply(SemanticModificationWrapper.java:31)
    at org.eclipse.xtext.ui.editor.quickfix.IssueResolution.apply(IssueResolution.java:76)
    ... 33 more

It would be helpful to have an action that create .melange files (that's painful to create an empty file with the correct extension and then remember how to fill it correctly)
Ideally it would support templates (with or without inheritance , ...)

Melange file:

package org.sample.melangeproject

import static extension fr.inria.diverse.melange.lib.MetamodelExtensions.*

language MyLanguage {
    ecore "platform:/resource/org.sample.toto/model/fsm.ecore"
    exactType MyLanguageMT
    with org.sample.totoaspect.StateMachineAspect
}
language Superlang inherits MyLanguage{
    exactType langMT
}

Aspect on StateMachine:

package org.sample.totoaspect;

import fr.inria.diverse.k3.al.annotationprocessor.Aspect
import finitestatemachine.StateMachine


@Aspect(className=StateMachine)
class StateMachineAspect {

    public def void who(){
        println("")
    }

}

Adapter generated for StateMachine from Superlang:

package org.sample.melangeproject.superlang.adapters.langmt;

import fr.inria.diverse.melange.adapters.EObjectAdapter;
import org.eclipse.emf.common.util.EList;
import org.sample.melangeproject.langmt.State;
import org.sample.melangeproject.langmt.Transition;
import org.sample.melangeproject.superlang.adapters.langmt.langMTAdaptersFactory;
import superlang.StateMachine;

@SuppressWarnings("all")
public class StateMachineAdapter extends EObjectAdapter<StateMachine> implements org.sample.melangeproject.langmt.StateMachine {
  private langMTAdaptersFactory adaptersFactory;

  public StateMachineAdapter() {
    super(org.sample.melangeproject.superlang.adapters.langmt.langMTAdaptersFactory.getInstance()) ;
  }

  @Override
  public EList<State> getStates() {
    return fr.inria.diverse.melange.adapters.EListAdapter.newInstance(adaptee.getStates(), org.sample.melangeproject.superlang.adapters.langmt.StateAdapter.class) ;
  }

  @Override
  public EList<Transition> getTransitions() {
    return fr.inria.diverse.melange.adapters.EListAdapter.newInstance(adaptee.getTransitions(), org.sample.melangeproject.superlang.adapters.langmt.TransitionAdapter.class) ;
  }

  @Override
  public void who() {
    org.sample.totoaspect.StateMachineAspect.who(adaptee) ;
  }
}

Problem:

org.sample.totoaspect.StateMachineAspect.who(adaptee) in who() raise a compilation error because adaptee is typed StateMachine from the generated Ecore for Superlang.

It would be nice to copy k3dsa dependencies inside the generated language project.

Name-based structural typing works well for evolution. However, mapping independently developed DSLs rarely works out-of-the-box.

Melange should support adaptation specification, at least through renaming, ideally with advanced mapping expressions. Some scenarios can be supported by derived attributed inserted through aspects. In a lot of other cases, an OCL-like expression can express the relationship between features of two different DSLs.

In such a case, it is the role of the adapters to effectively realize the adaptation. The mapping expression must be compiled in the adapter's code.

I modified the 3semantics example to test uniqueness of created adapter and I get a NullPointerException:

Modified part of FSM.melange

transformation execute(FiniteStateMachineUMLMT stateMachine, String input, String outputFile){
    val root = stateMachine.contents.head as finitestatemachines.finitestatemachineumlmt.StateMachine
//  root.eval(new FSM.interfaces.Context(input), outputFile)
    println(root.states)
    println(root.states)
    println(root.states.get(0))
    println(root.states.get(0).outgoing.head.source)
}

The error:

fr.inria.diverse.melange.adapters.EListAdapter@5a8e6209
fr.inria.diverse.melange.adapters.EListAdapter@4b4523f8
Adap<finitestatemachines.finitestatemachineuml.adapters.finitestatemachineumlmt.StateAdapter>(finitestatemachinescomposite.impl.InitialStateImpl@67b92f0a (name: init) (initialTime: 0, finalTime: 0))
Exception in thread "main" java.lang.NullPointerException
    at finitestatemachines.finitestatemachineuml.adapters.finitestatemachineumlmt.TransitionAdapter.getSource(TransitionAdapter.java:63)
    at finitestatemachines.execute.call(execute.java:29)
    at finitestatemachines.main.call(main.java:13)
    at finitestatemachines.main.main(main.java:18)

I guess it come from ListAdapter

It would be handy to have the ability to run a new wizard for selecting/creating an Ecore file when selecting the syntax of a model type (same thing that for languages), ie.:

modeltype A {
    syntax [ctrl+space wizard]
}

We need a feedback when we fail to apply an Aspect because the aspected class is not found.
The user need to know the classpath have to be fixed

Cross-references between different models is only in-the-small, at the Ecore level. However, it would be relevant to allow direct references between models by enabling the definition of metamodels' and model types' attributes or references:

modeltype MyMT { ... }
metamodel X implements MyMT {
    ecore "..."
    exactType XMT
}
metamodel Y {
    ecore "..."
    exactType YMT
    attribute myX : XMT
    attribute myRef : MyMT
}
transformation foo(Y y) {
    y.myX = ...
    y.myRef = new X
}

This attributes must be taken into account in the model-oriented type system.

The extension point "org.eclipse.emf.ecore.generated_package" is not generated in the melange project.

(split from #7)

Name-based structural typing works well for evolution. However, mapping independently developed DSLs rarely works out-of-the-box.

Melange should support adaptation specification, at least through renaming, ideally with advanced mapping expressions.

First step is to include renaming expression

In such a case, it is the role of the adapters to effectively realize the adaptation. The renaming expression must be compiled in the adapter's code.

currently the Emfruntime (ecore+project) is generated on request only via a quickfix (because it take too long to be done on the fly in the xtend)
As it is generated only once, it may be desynchronized with the actual source ecore+aspect.

we need to first detect such desynchronization and second propose a way to regenerate the ecore, genmodel and code.

for the detection we may use an EMF compare. this should be done either in the validate phase of the xtend compilation. Or if this is too time consumming need to be added in a new builder that would host long running tasks.
once detected it may be reported as an error or warning as a support for quickfix that propose to resynch
This resynch action should also be proposed as a popup action (right click on metamodel)

Currently, Melange's compiler generates (among others) a Java file for each metamodel and a Java file for each of its metaclass, in the same package. If a metamodel and one of its metaclass share the exact same name, the generated code is invalid (on Linux). The problem also arises on MacOS and Windows, even if the characters case differs.

Melange should provide an API for all the operations on models outside from Melange

We should finalize melange resource implementation.

in some case, the save is not possible due to a NPE.

workaround, say that we do not want to save then reopen, the file seems to be saved anyway 😕

it should be catched properly in order to be able to close the editor view even if there are some internal error (which should be trace in the error log or the problem view anyway)

I don't have a precise example to provide rigth now but here is the stacktrace
java.lang.NullPointerException
at fr.inria.diverse.melange.processors.ExtensionPointProcessor$8.accept(ExtensionPointProcessor.java:372)
at fr.inria.diverse.melange.processors.ExtensionPointProcessor$8.accept(ExtensionPointProcessor.java:1)
at java.lang.Iterable.forEach(Unknown Source)
at fr.inria.diverse.melange.processors.ExtensionPointProcessor.serializedAspects(ExtensionPointProcessor.java:376)
at fr.inria.diverse.melange.processors.ExtensionPointProcessor.access$6(ExtensionPointProcessor.java:364)
at fr.inria.diverse.melange.processors.ExtensionPointProcessor$7.accept(ExtensionPointProcessor.java:321)
at fr.inria.diverse.melange.processors.ExtensionPointProcessor$7.accept(ExtensionPointProcessor.java:1)
at java.lang.Iterable.forEach(Unknown Source)
at fr.inria.diverse.melange.processors.ExtensionPointProcessor._preProcess(ExtensionPointProcessor.java:353)
at fr.inria.diverse.melange.processors.ExtensionPointProcessor.preProcess(ExtensionPointProcessor.java:395)
at fr.inria.diverse.melange.ui.editor.MelangeDocumentProvider$1.exec(MelangeDocumentProvider.java:30)
at fr.inria.diverse.melange.ui.editor.MelangeDocumentProvider$1.exec(MelangeDocumentProvider.java:1)
at org.eclipse.xtext.resource.OutdatedStateManager.exec(OutdatedStateManager.java:121)
at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.internalReadOnly(XtextDocument.java:520)
at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.readOnly(XtextDocument.java:492)
at org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:133)
at fr.inria.diverse.melange.ui.editor.MelangeDocumentProvider.doSaveDocument(MelangeDocumentProvider.java:34)
at org.eclipse.ui.texteditor.AbstractDocumentProvider$1$SaveOperation.execute(AbstractDocumentProvider.java:610)
at org.eclipse.ui.texteditor.AbstractDocumentProvider$DocumentProviderOperation.run(AbstractDocumentProvider.java:74)
at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313)
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:75)
at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:65)
at org.eclipse.ui.texteditor.AbstractDocumentProvider.executeOperation(AbstractDocumentProvider.java:551)
at org.eclipse.ui.texteditor.AbstractDocumentProvider.saveDocument(AbstractDocumentProvider.java:629)
at org.eclipse.ui.texteditor.AbstractTextEditor.performSave(AbstractTextEditor.java:5076)
at org.eclipse.ui.texteditor.AbstractTextEditor.doSave(AbstractTextEditor.java:4866)
at org.eclipse.xtext.ui.editor.XtextEditor.doSave(XtextEditor.java:312)
at org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable.doSave(AbstractTextEditor.java:7209)
at org.eclipse.ui.Saveable.doSave(Saveable.java:216)
at org.eclipse.ui.internal.SaveableHelper.doSaveModel(SaveableHelper.java:355)
at org.eclipse.ui.internal.SaveableHelper$3.run(SaveableHelper.java:199)
at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:283)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:466)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:374)
at org.eclipse.ui.internal.WorkbenchWindow$13.run(WorkbenchWindow.java:2157)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2153)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:291)
at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:269)
at org.eclipse.ui.internal.SaveableHelper.saveModels(SaveableHelper.java:211)
at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:146)
at org.eclipse.ui.internal.WorkbenchPage.saveSaveable(WorkbenchPage.java:3915)
at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3929)
at org.eclipse.ui.internal.handlers.SaveHandler.execute(SaveHandler.java:54)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:294)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
at sun.reflect.GeneratedMethodAccessor192.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:286)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:507)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:558)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:378)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:324)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:86)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1060)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1070)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1112)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1108)
at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1529)
at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4722)
at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:343)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4610)
at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:339)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5023)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2549)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)

inference of melange doesn't support java arrays

if we have a K3 aspect that declares a method with java array, then we get an error in the merge of melange

ex: in TFSM sequential from GEMOC
@fr.inria.diverse.k3.al.annotationprocessor.InitializeModel
def public void initializeModel(String[] args){

then the melange:
with org.gemoc.sample.tfsm.plaink3.dsa.TimedSystemAspect

we get the folloing error :
Cannot merge tfsm_plaink3.String[] with tfsm_plaink3.eClassifiers: The name 'String[]' is not well formed Main.melange /org.gemoc.sample.tfsm.plaink3.xdsml/src/main/java/org/gemoc/sample/tfsm/xdsml line: 25 /org.gemoc.sample.tfsm.plaink3.xdsml/src/main/java/org/gemoc/sample/tfsm/xdsml/Main.melange Melange Problem

In GEMOc we use the org.eclipse.emf.ecoretools.registration.ui.ecoreAutoRegisterBuilder to automatically register the ecore in the current eclipse so ECL can work out of the box without having to deploye the plugin.
This information is stored in the .project as a buildCommand.
Unfortunatly, when generating the runtime for the language the .project file is completly overriden be a new one that doesn't contains this inforamtion anymore.

Second step for #7
Name-based structural typing works well for evolution. However, mapping independently developed DSLs rarely works out-of-the-box.

Melange should support adaptation specification, at least through renaming, ideally with advanced mapping expressions.

In Melange, we never explicitly set the file extension to be used by models conforming to a given language. EMF implicitly uses the name of the root package as the file extension.

Since the same Ecore file can be imported in various Melange languages, this can lead to conflicts. In this case, when Melange generates their runtime, they would use the same file extension, even though they are conceptually different.

To solve this problem, we can set an explicit file extension in the .genmodel generated from a language (each GenPackagehas a fileExtensionproperty). A good default would be to use the name of the language (in lower case) as the default file extension for its models. it would also be handy to be able to explicitly set the file extension of a language when needed. This means extending the current grammar with a new keyword (eg. fileExtension X).

See https://github.com/diverse-project/melange/blob/master/plugins/fr.inria.diverse.melange/src/main/java/fr/inria/diverse/melange/ast/MetamodelExtensions.xtend#L66-L92 to set the file extension in the serialized GenModel.

when using the creation of a metamodel such as
metamodel TfsmExtended inherits SimpleTfsm {
exactType TfsmExtendedMT uri "http://tfsm/mt"
with TFSMAspect
with StateAspect
with TransitionAspect
with FSMClockAspect
with EvaluateGuardAspect
}

it creates 2 projects: one for the EMFRuntime for TfsmExtended and one containing a copied of the *Aspect classes adapted for TfsmExtended .
since the adaptation works on java files only and not directly on xtend files we don't have the limitation prevent us to put all this in the same project. (see k3AL/xtend current limitation)

Then, if both emf generated code and behavior implementation code (from aspects) are in the same project, it would be quite easy to modify the .ecore and add the correct annotation that will allow to generate the code that calls the aspect operations directly from the operation in the EObjects.

If the user wish to create new aspects or overide the behavior, he is free to create a dedicated aspect project...

If the name of an inherited language language is in lower case, generated packages name for adapters are in with generated language classe.

package mypackage

language Lang{
    ecore "my.ecore"
    exactType superMT
}

language childlang inherit Lang{
    exactType childMT
}

We generate:

• mypackage/childang.java
• mypackage/childlang/adapter/childMT/childMTAdapterFactory.java

It seems that qualified name of mypackage.childang class conflict with name of the mypackage.childlang package

A workaround is to set a first uppercase character for name of languages.

moreover, when overiding these information manualy, the generate language runtime will remove the manual changes :-(

If we defined an attribute of type Set in an aspect on a Metaclass,
Melange tries to wrapper the Set in a ListAdapter when generating the corresponding adapter.
-> compilation problem

Because metamodels' and aspects' Ecore are externalized (not part of the AST), some elements of the (e.g. aspect attribute types) are not shown.

Besides, clicking on some elements (e.g. aspects' metaclasses) ends up in a FileNotFoundException.

when doing a generate Language runtime it completly remove any existing project. then recreate the project in the workspace.
The issue occurs when the previous project was actually imported in the workspace (because it is under version control with git for example) in that case, the synchronization with git is lost

in my FsmClockAspect I have an attribute of type Integer

@Aspect(className=FSMClock)
class FSMClockAspect extends NamedElementAspect {
    public Integer numberOfTicks;

this generates a buggy FSMClockAdapter.java with integer in lowercase

 public integer getNumberOfTicks() {
    org.gemoc.sample.tfsm.k3dsa.aspect.FSMClockAspect.numberOfTicks(adaptee) ;
  }

  public void setNumberOfTicks(final integer numberOfTicks) {
    org.gemoc.sample.tfsm.k3dsa.aspect.FSMClockAspect.numberOfTicks(adaptee, numberOfTicks
    ) ;
  }

workaround use int intstead of Integer

On some sample, the Generate Language runtime works if the melange editor is closed. (aspect correctly copied etc)

but if the editor is opened, the generated code is not the same and with a lot of errors
the issue also occurs on "Generate all"

there is no error log to help understand what's going on 😕

There is currently two ways to define a model type. Either by extracting the exact type of an existing metamodel:

metamodel X {
    ecore "..."
    exactType XMT // <-- Always contains all the features of the Ecore (i.e. no filtering)
}

... or by explicit importing an Ecore file describing it:

modeltype XMT {
    ecore "..."
}

Ecore annotations may be used to explicitly specify the features to be exposed in a metamodel:

metamodel X {
    ecore "..."
    exactType XMT // <-- Reads @Exposed annotations in the Ecore file. Only exposes them.
}

Current most costly steps are:

• Metamodels' and model types' Ecore load() (and save() + genmodel invocation when new languages are created)
• Code (mostly adapters) generation (+ corresponding JDT compilation time)

Code generation should only be triggered when the definition of the corresponding language changes, or when new typing relations are inferred.

Ecore and genmodel load()/save() should only be triggered when the definition of the corresponding language (or its super-hierarchy) changes.

Using a global com.google.inject.Singleton cache for the entire workspace would dramatically reduce parsing and compilation times. However, it is sometimes tricky to determine when the cache must be flushed or when code must be regenerated. Impact of changes in Metamodel/ModelType/Transformation definitions should be analyzed in order to minimalize regeneration of artifacts.

Some sort of transitive notify() on the hierarchy impacted by a change should do the job.

language A {
    ...
}
language B inherits A {
    ...
}

B inheris the Ecore and aspect definitions of A. If the Ecore/Aspects of A evolve, B is desynchronized.

Hello :)

There are compilation errors in the generated code (src-gen) when the syntax EPackage name has some upper case letters in it.

To reproduce:

• Create an EMF project with an ecore model whose package name is "PackageThatRocks"
• Create an xDSML project with a Melange model referencing the ecore as syntax
• Right click, "Generate all"

And there are many compilation errors in the generated "src-gen".

From what I can try to guess: some generator code of Melange uses toLowerCase when writing a package name in a Java file, even though the real package name might have upper case in it

Currently, operations are associated to metamodels or model types through the definition of transformations:

modeltype  A { ... }
metamodel X implements A { ... }
transformation foo(A a) { ... }
@Main transformation bar() { foo.execute(new X) }

A simple enhancement would be to allow the direct invokation of transformations whose first argument is a metamodel or model type:

modeltype  A { ... }
metamodel X implements A { ... }
transformation foo(A a, String s) { ... }
@Main transformation bar() {
    val x = new X
    x.foo("abc")
}

Similarily, operations could be defined in a more "object-oriented style":

modeltype  A {
    operation A foo(String s) { return this }
}
metamodel X implements A { }
metamodel Y inherits X implements A {
    override A foo(String s) { return ... }
}
@Main transformation bar() {
    val x = new X
    val y = new Y
    x.foo("abc") // X::foo
    y.foo("abc") // Y::foo
}

This would make explicit, e.g. the specialization of operations through the languages hierarchy.

Currently, the abstract syntax of metamodels is defined by importing the corresponding Ecore file:

metamodel X {
    ecore "platform:/.../X.ecore"
    exactType XMT
}

An alternative solution would be to allow the definition of metamodels directly within the metamodel construct using Xcore, something like:

metamodel X {
    Xcore {
        class Foo {
            String x
            contains Bar[] y
        }
        class Bar {}
    }
    exactType XMT
}

Jobs can run in parallel and give better real-time feedback to the user through the WIP dialog.
Splitting MelangeProcessors into separate Jobs with dependencies would possibly improve build time.

In the case where we wish more than one melange file in a single project (for example in order to have different package names for each languages) then the generate all removes everything, including elements related to the other melanges files, but will generate content only for the current file

With a Metamodel with several packages,
When aspects are copied, the package name of each Metaclass is changed for the name of the first package of the Metamodel.