emoflon / emoflon-core Goto Github PK

• As the model/*.genmodel is generated, it should be added to the .gitignore.
• As the model folder contains a versioned file (the *.ecore) no .keepmodel is necessary.
• The gen folder does not need a .keepgen as the build will create the folder if it does not exist (cp. the injection folder).

The following .gitignore should be fine:

/bin/
/gen/
/model/*.genmodel

Please provide a README explaining what is required to setup a development workspace for emoflon-core.

My experiments show that one needs at least to install Xtext.

Such as attributes and operations etc

To reproduce:

• Choose a set of projects to build (code generation)
• One of these projects should cause an exception to be thrown (.ecore missing, or properties file corrupt, etc)
• build automatically is switched off at the beginning of the process, but apparently is not switched back on if an exception flies

My only explanation is that switching build automatically back on must be in a try block whereas it should actually be in the finally block to ensure that it is always executed.

To motivate metamodellers to document their classes and references, we could do something with these annotations in the visualisation. Perhaps a “note” for the currently selected (single) element? Or a caption?

It might make sense to implement a toggle (view action) so the notes/caption can be switched on and off.

The code for visualising correspondence models is located in EMoflonMetaModelVisualiser until including commit 9175f43 (see EMoflonModelAndMetamodelVisualiser). Following a refactoring, it is supposed to be removed from the Ecore visualiser. Therefore it needs to be added somewhere else, i.e. to the TGG visualisation.

Our little “cloud” menu to import PSFs is pretty but also quite useless at the moment. There are no pre-entered values and the standard PSF import in Eclipse is actually better because it can handle URLs, i.e., one doesn’t require the actual PSF file locally.

I propose we do two things:

• accept only URLs to PSF files as opposed to the actual files themselves. The aim is usually to check out some projects before cloning the respective git repositories.

• we should establish an extension point so that other plugins can hook into our menu here and pre-enter some PSF URLs. Without this extra functionality, our pretty cloud is simply not worth the extra effort of maintaining it.

What do you think @RolandKluge?

I have just established an extension point for this so the preference can be removed.

Note that no supplied extension defaults to PLUGIN so there is nothing to do for emoflon-tool (Ibex is now using an extension).

I didn't want to make this change myself as it probably breaks some code in emoflon-tool (setting the preference?)

The code in NewMoflonEmfProjectWizard creating a new metamodel project could be improved by using an Xtend template to create, e.g., the string required for the default documentation annotation (this is currently done using strings directly).

We should encourage documentation of metamodels by generating one GenModel annotation in the default .ecore that we place in newly created emf projects.

Caused by: java.lang.ClassCastException: org.eclipse.jface.text.TextSelection cannot be cast to org.eclipse.jface.viewers.IStructuredSelection
at org.moflon.core.ui.handler.TouchResourceHandler.execute(TouchResourceHandler.java:26)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:291)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:92)
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.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
... 51 more

We should also try to get rid of the already persisted jars in emoflon-core.
If nothing helps, we just start over.

• could we use platform:/resource/... as our default URIs instead of the current platform:/plugin/...? This simplifies things a bit for a most users and advanced users (who want to actually create eclipse plugins) can change this as required.

• could we remove all options in the default moflon.properties file apart from replace gen model? All other options are very eMoflon (SDM) specific and don't really make sense in a general context.

In a way that is backward compatible, i.e., one can of course still work directly with both .ecore and .genmodel.

• add a builder (extension?) that programmatically converts *.xcore to *.ecore and *.genmodel
• make visualisation of metamodels "Xcore aware"
• update handbook and recommend usage of Xcore and ESON
• update dependencies and update sites of eMoflon::core

This avoid confusing users about the use of certain options.

• Untar existing Oxygen 2 in image
• Install eMoflon Core Feature via command line
• Create a fresh workspace with the sample project

An NPE may arise if the moflon.properties.xmi does not contain an entry for the metamodel name.

due to dependency to org.gervarro.eclipse.task:

Missing requirement: Core build components for Eclipse 1.0.0.201801240921 (org.moflon.core.build 1.0.0.201801240921) requires 'bundle org.gervarro.eclipse.task 1.0.1' but it could not be found

For some reason, our autotester / PSF import always tries to "launch" one of the projects. Shouldn't this only be the case if the naming convention testsuite is adhered to? In the case of the ibex handbook projects this auto launch feature doesn't make much sense and just fails with an ugly error message.

at least I am unable to extract injections from manipulated source code.
The action "refresh injection for class" is present but is greyed out for some reason.

.. and I don't really know how to fix them.

Don't you have the warnings too @RolandKluge ?

• Create separate repository emoflon-core-updatesites for hosting the update sites
  • /stable
  • /snapshot
• Reduce size of emoflon-core by purging all jar files from history
  • https://rtyley.github.io/bfg-repo-cleaner/#examples
    • I removed all jar files, except for antlr.
    • java -jar bfg-1.13.0.jar --delete-files 'org.gervarro.*.jar' emoflon-core.git
    • java -jar bfg-1.13.0.jar --delete-files 'org.moflon.*.jar' emoflon-core.git
    • java -jar bfg-1.13.0.jar --delete-files 'org.eclipse.*.jar' emoflon-core.git
    • java -jar bfg-1.13.0.jar --delete-files 'net.sourceforge.*.jar' emoflon-core.git
    • java -jar bfg-1.13.0.jar --delete-files 'artifacts.jar' emoflon-core.git
    • java -jar bfg-1.13.0.jar --delete-files 'content.jar' emoflon-core.git
    • ...
  • Nice one-liner for checking objects in repo: https://stackoverflow.com/a/42544963
• Extend CI
  • Create update site with tycho
  • Revive CI - did not work :-(
  • Test whether the generated update site can be installed in Eclipse Oxygen 3
  • Push the update site to emoflon-core-updatesite

The model visualiser should implement a quick check for how many elements are to be visualised. If this exceeds say 500 then it should simply display a message "Too large to make any sense of -- you'd better make an explicit choice of the elements you want me to display." :)

At the moment opening large models (e.g., produced by the model generator simply crash Eclipse entirely).

The Xtend codegen is not triggered for this project.

See https://app.shippable.com/github/eMoflon/emoflon-core/runs/69/1/console

@anthonyanjorin FYI

We should simply use the default Eclipse formatter.
The Moflon-specific formatter shall be deleted from https://github.com/eMoflon/emoflon-tool

Is it on purpose that the following Handler is called Hanlder?

https://github.com/eMoflon/emoflon-core/blob/master/org.moflon.core.ui/src/org/moflon/core/ui/handler/NoActionCommandHanlder.java

I found out because of an error I get when trying to work with an Integration project...
(Just saw, that this following error has been brought up in another issue already.)

eclipse.buildId=4.7.2.M20171130-0510
java.version=1.8.0_162
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_IE
Framework arguments: -product org.eclipse.epp.package.modeling.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.modeling.product

org.eclipse.ui
Error
Tue Feb 27 17:45:47 CET 2018
Conflicting handlers for org.moflon.ide.ui.commands.MoflonDevtoolsMenuCommand: {org.moflon.core.ui.handler.NoActionCommandHanlder} vs {org.moflon.core.ui.handler.NoActionCommandHanlder}

Now that we have switched to creating .ecores with platform:/resource as default URI, we also have to fix our default generated genmodels to reflect this. At the moment this is not the case and the EoreEditor correctly flags this as an error (even though code generation still somehow works).

This is for example an excerpt from a genmodel (note the platform:/plugin fragments):

 <genPackages prefix="Businessrules" disposableProviderFactory="true" ecorePackage="platform:/plugin/de.upb.mbse.taxcalculationexample.businessrules/model/Businessrules.ecore#/">
    <genClasses ecoreClass="platform:/plugin/de.upb.mbse.taxcalculationexample.businessrules/model/Businessrules.ecore#//Foo"/>
  </genPackages>

• Should be able to auto-install an arbitrary PSF file
• Should be able to trigger the auto-installation process for the current workspace (without checkout)

There are currently a few warnings and I'm not sure if they are (un)important.

It would be nice to able to click on the classes/objects in the vis and to navigate to the element in the model editor, e.g. to be able to create/check attributes (values).

I just got a feature request for some kind of version information of eMoflon to be provided programmatically (not only via the normal Eclipse way). I suppose we could add this to the logger? Would be nice if this could be automatically updated (extracted from some plugin)?

Currently, code will be generated, but with strange compilation errors due to name clashes.

The visualisation should exploit eOpposites to beautify the diagram (bidirectional edges).

Similar to
http://www.kermeta.org/docs/html.chunked/KerMeta-Deploying-a-code/ch04.html
https://eclipse.org/epsilon/doc/articles/reflective-emf-tutorial/

Helpful code in Epsilon:
https://www.eclipse.org/epsilon/download/
plugins/org.eclipse.epsilon.emf.dt
class: org.eclipse.epsilon.emf.dt.RegisterMetamodelAction

It appears that I cannot really prevent (background) updates of eMoflon Core, which has caused eMoflon Tool to break multiple times due to the platform:/resource URI handling.

@anthonyanjorin I'm afraid, we have to switch the default handling to the traditional style.

I use working sets a lot and when I select some and hit our build "hammer", nothing happens (selection of projects appears to be empty).

Would be nice to have support for working sets :)

This is useful, if you want to re-trigger the code generation without the need for a full build.

The NewMoflonEmfProjectWizard currently has platform:/resource hard coded as the URI for all new EPackages. We could now also respect the new extension and use the value provided there for this.

@anthonyanjorin FYI

Adding generated code to the repo is ugly.
Therefore, we should trigger codegen on the CI server.
The following steps will be necessary:

1. Provide a custom Docker image with a stable eMoflon Core version installed

• The Eclipse should contain https://github.com/seeq12/eclipse-import-projects-plugin

1. Create an Eclipse workspace that contains all plugins in emoflon-core
   • Maybe we can even automate this step?
2. Add a headless build to the CI workflow
   • See https://help.eclipse.org/oxygen/index.jsp?topic=%2Forg.eclipse.jdt.doc.isv%2Fguide%2Fjdt_apt_building_with_apt.htm

workspacePath="../.."
repositoryRoot="."

# Create workspace
$ECLIPSE_HOME/eclipse -nosplash -application org.eclipse.jdt.apt.core.aptBuild -data $workspacePath

# Import all projects
$ECLIPSE_HOME/eclipsec -nosplash -application com.seeq.eclipse.importprojects.headlessimport -data $workspacePath -import $repositoryRoot
# Repeat if necessary: 
# $eclipseHome/eclipsec -nosplash -application com.seeq.eclipse.importprojects.headlessimport -data $workspacePath -import $repositoryRoot

# Invoke build
$ECLIPSE_HOME/eclipse -nosplash -application org.eclipse.jdt.apt.core.aptBuild -data $workspacePath

Our current link to a tutorial for people who paste our update site in a normal web browser is broken. We should replace it (Xtext has a nice link).

https://emoflon.github.io redirects to http://emoflon.org instead of https://emoflon.org.

As GitHub announced support for HTTPS for custom domains, this can be easily fixed such that the update sites are available over HTTPS.

The defaults are currently to ignore .ecore as well as .genmodel etc.
I suggest we remove the entry for .ecore so this not automatically ignored when setting up git.

I doubt if it's a good idea to start our very own implementations of extra collections (BiMap and HashBiMap) in core. I'm pretty sure Apache or Guava provide an excellent choice of such beefed up collections and much more.