DSL Forge 0.9.0 is Out!

dslforge-header

DSL Forge v0.9.0 is based on Eclipse Neon packages, with RAP 3.1.0 and Xtext 2.10. ANTLR v3.3 with JavaScript target has been patched for Java 8. This version comes with core refactorings on the generators. Mainly, the ACE/ANTLR Generator has been extracted from the Xtext/RAP Generator, which has been enhanced with new features. The Xtext content assist feature has been ported to RAP with very localized changes. The difficulty is not in porting the Xtext interfaces, but rather to manage the dependencies to JFace (no web support) and the adherence to the Eclipse JDT. Well, the Xtext team have refactored their features since version 2.9.x and the dependencies are now managed much better.

The Xtext/RAP Generator produces now 3 projects. For example, if you have the following RCP plugins:

  • /org.eclipse.xtext.example.statemachine
  • /org.eclipse.xtext.example.statemachine.ui

The generator outputs 3 projects:

  • /org.eclipse.xtext.example.statemachine.web
  • /org.eclipse.xtext.example.statemachine.web.build
  • /org.eclipse.xtext.example.statemachine.web.target

The web plugin to package with RAP, a Maven/Tycho project to actually build and package the editor as a web application archive (war), and the target platform on top of which to compile and build the web application.

4 Steps to get your DSL deployed on the web!

Step 1: Generate a web editor from an existing Xtext grammar.

Step 2: Set up the debug configuration and launch the web application from Eclipse.

Step 3: run the Maven build to get a web application archive ready to be deployed.

Step 4: Deploy the web archive on Tomcat

Limitations

Xbase is out of scope for now, as its adherence to the JDT cannot be satisfied in the current scenario. Moreover, Xtext grammar inheritence is not yet translated into ANTLR grammar inheritence, so if your grammar imports other grammars, generate the editor from the main grammar then copy the rules from the original Xtext files to the ANTLR file. Contact the professional support for additional details.

Download P2 Sites

Tooling: http://dslforge.org/downloads/tooling/repository/

Runtime: https://dslforge.org/downloads/runtime/repository/

Get the Source Code

https://github.com/plugbee/dslforge

Report issues

GitHub: https://github.com/plugbee/dslforge/issues

mailto: team@dslforge.org

dslforge

What’s new in DSL Forge?

The browser-based cool stuff soon available to play with!

dslforge-workbench

When it comes to manage multiple users accessing the same model resource online, the most straight forward way is to consider using a repository, such as EMFStore or CDO. The main reason why these technologies are not well suited for textual resources is the serialization format. Classical EMF resources are persisted in XMI, while resources with textual content are often persisted as-is, and this is also the case of Xtext resources.

Moreover, I don’t like the idea of persisting model content into databases… such a decision will make migrating models complex afterwards, compared to traditional file storage systems.

Anyway, I have at least two reasons to consider the problem right from the beginning. What we need is a component acting like a workspace in a web context. With the first prototype presented at MoDELS, the workspace was simply mapped to a root folder in the server’s file storage system.

To be able to manage concurrent users access, we need to keep track of information about the users accessing the workbench, such as their ID, name, company, projects, etc. We need to maintain the state of files currently locked, and by who the files are locked.

A database is a good candidate to store and manage such metadata, then we need to map the files in the file system to that metadata in the database, and provide a convenient API unifying the access to the couple (file storage system, database) as a unique singleton providing basic functions like creating a projet, creating a file, locking a file, etc. Ok, this sounds like an ECM repository right? After all, DSL files can be seen as “enterprise content”, and they are first-class entities in our scenario.

The Workbench has now an embedded Derby database, persistency is managed using Gemini and EclipseLink.

We also added an extension point that allows to integrate DSL editors easily. These are the DSLs currently contributed to the workbench:

  • Fowler’s DSL: a language for describing state machines,
  • Arithmetics: a language for describing arithmetic expressions,
  • Dimain Model: classical entities and relationships language
  • Humming Bird: a language for describing embedded system devices

Bringing domain-specific languages to the Web

It seems inevitable that everything we do in software engineering is going Web. This is true also for Eclipse-based modeling environments. Whether or not online IDEs will make developer’s life easier that is another question. At least in the area of Domain-Specific Languages where automated processes are heavily used for model transformations, code generation, etc., one can think about web-based approaches. DSL users are supposed to be non-developers, say “domain experts”. Their focus is mainly on business added value, not the implementation details. Examples of domains making extensive use of model-driven engineering are automotive, energy, and defense.

Sharing tools and resources across multiple users has always been used in traditional developments environments. This is the case for versioning systems, workspace provisioning systems, shared repositories, and even content management systems. However, with the increasing of end users mobility and for some reasons of remote configuration, e-learning, webminars, wikis, etc., there is still a need for more lightweight applications shifted on web browsers.

In this screencast, I’m going to show you how you can derive a Web editor from an existing Xtext grammar, with the following features already given for free:

–        Syntax highlighting

–        Syntax validation

–        Content assist

If this prototype interests you, you can contact me at: amlajmi[at]gmail[dot]com