The namespace of the project is org.modelspartiti, which was the original name
of the project; this may change in the future. At the moment we are adopting the following
naming conventions for plugins:
org.modelspartiti.infrastructure.[component]- Components of the core infrastructure of the framework. This is typically something related to the TMDL language itself.org.modelspartiti.formalisms.[name]- Contains the Ecore metamodels of the template-level and instance-level formalism[name].org.modelspartiti.formalisms.[name].design- Contains the graphical editor for models based on formalism[name].org.modelspartiti.formalisms.[name].examples- Contains example models for formalism[name].org.modelspartiti.formalisms.[name].concretize- Implements the concretize function for formalism[name].org.modelspartiti.formalisms.[name].gen.[format]- Generates output files in[format]from models in formalism[name].
We use Maven to automate the build process.
To build all the plugins you can just run mvn package in the plugins directory.
The resulting .jar files of the plugins will be generated in the target folder of the corresponding project. The content of the update site will be generated in the target/repository folder of the releng-updatesite project. That is, the folder plugins/releng-updatesite/target/repository/plugins/ will contain all the .jar packages of the plugins that are configured to be included in the update site.
The Maven configuration of the project uses Thyco, which obtains dependency information from the Eclipse plugins' MANIFEST.MF files, instead of requiring a separate pom.xml file for each plugin. To include a new Eclipse plugin project to the build process you can just add its folder to plugins/pom.xml file. More information on this setup can be found in this tutorial.
The repository is organized in two main branches: master and develop.
These two branches are protected, meaning that you cannot directly commit on top of them.
Please create your own branch and work on that. Once you think that your code is ready, push it to the repsitory and
create a new pull request to have it integrated in the main branches.
You may want to take a look at the GitFlow branching model to understand what is the idea behind using multiple branches.
Every commit on the master and develop branches is automatically built and deployed in the update site.
Eclipse normally stores newly created plugins in a workspace folder. However, we recommend to store the workspace and the code in two separate folders. This simplifies the management of plugins in the long run, and avoid user-specific configuration of the workspace to be mixed with code in the repository. Workspace configuration should not be committed to the repository.
Getting Started
To get started, follow these simple steps:
- Clone the repository of the project in a directory of choice (
git clone [address]) - Run Eclipse and create a new workspace folder in a directory of choice. You can create it inside the repository folder, but remember that this should not be committed.
- Import the existing projects in the workspace, using the menu command
File / Import / Existing Projects into Workspace, and selecting the plugins folder of the repository as source folder.
You are now ready to work on the existing plugins!
Adding a New Plugin
In case you need to create a new plugin, please do the following:
- When creating the project, instruct Eclipse not to use the default location, but instead have it creating the plugin inside the plugins folder of the repository. If you forget to do this, you can always move it later, and import again the plugin in the workspace.
- Remember that you need to add the plugin folder in the plugins/pom.xml file to have it included in the automated build process.
Running the Plugins
When worksing inside Eclipse you do not need to run Maven to compile the plugins: compilation is handled automatically by Eclipse.
To use or test the plugins being developed, you need to run a second instance of Eclipse that has the compiled plugins installed.
This can be done with the option Run As / Eclipse Application, which runs
a new instance of Eclipse in which all the plugins in the development workspace are installed.
We refer to these two instances of Eclipse as the development instance, in which you develop
the plugins, and the runtime instance, the one of in which the plugins are already installed.
Each has its own workspace. You will therefore have a development workspace and a runtime workspace, in two different folder. The location of the runtime workspace is configured in the Run Configuration.
That said, the are some tasks that can be executed in the development workspace. For example:
- By opening an Ecore metamodel with the Sample Reflective Ecore Model Editor, and right-clicking on a metaclass you can select
Create Dynamic Instanceto create a new XMI model conforming to that metamodel.
It is important to note that you can import plugins in the runtime workspace as well. It is always a good idea to import the plugins with example in the name also in the runtime workspace, as they will depend on the other plugins.
Depending on the plugin you are developing, you may actually need to work in the runtime workspace. For example, if you are developing a transformation from metamodel A to metamodel B, you need the that plugin(s) that include the metamodels A and B are installed.
Another option is to actually install the plugins you need in the development instance, and continue developing the ones that depend on them. For example, in the example of the transformation from metamodel A to metamodel B above, you may want to install the plugin(s) providing the A and B metamodels, so that you can work normally in the development workspace. The most convenient way to do this during development is explained in the next section.
Installing the Plugins
You may occasionally want to install the plugins you are developing in a new Eclipse installation.
The easiest way to do that is to export the plugins "as deployable fragments" and then copy them into the dropins folder of your Eclipse installation. On the next run Eclipse will automatically load the plugins in the environment.
Note: For this method to work, all the required dependencies must be avaialble, either among the installed plugins or among the plugins in the dropins folder.
It is always better to look at plugins' MANIFEST.MF files to understand the dependencies of each one.
From a general perspective, to be able to use the framework the following dependencies are needed:
- Eclipse Modeling Framework (EMF)
- Eclipse OCL
- Sirius
All these components can be found in the Eclipse Marketplace (Help / Eclipse Marketplace)
or in the default update site that comes configured in the default installation of Eclipse.
Tutorials
Official Websites