Paper Abstract: Open-source software has numerous advantages over proprietary commercial-off-the-shelf (COTS) software. However, there are modeling languages, tool chains, and tool frameworks that are developed and maintained in an open-source manner but still incorporate COTS tools. Such an incorporation of COTS tools into an overall open-source approach completely annihilates the actual open-source advantages and goals. In this tool paper, we demonstrate how we eliminated a COTS tool from the otherwise open-source-based generation and evolution workflow of the domain-specific modeling language EAST-ADL, used in the automotive industry to describe a variety of interdisciplinary aspects of vehicle systems. By switching to a pure open-source solution, EAST-ADL becomes easier to inspect, evolve, and develop a community around. We compare both the mixed COTS/open-source and the open-source-only workflows, outline the advantages of the open-source-only solution, and show that we achieve equivalent tooling features compared to the original approach.

Tool and demonstration scenario: In general, we present our new Eclipse-native generation and evolution workflow for EAST-ADL.

== Part 1 == We maintain and evolve the EAST-ADL metamodel, which in our approach relies on Ecore—in contrast to the original approach, which uses a metamodel with a proprietary file format maintained in a COTS modeling tool. This metamodel serves documentation purposes, so that we call it “documentation MM” in the paper. Steps of the scenario: - We add new language concepts to the Ecore-based EAST-ADL metamodel and hook them into the language infrastructure by inheritance. - In this context, we also shortly outline the documentation and visualization capabilities of EcoreTools and compare them to the COTS modeling tool from the original approach.

== Part 2 == We transform the documentation MM to another Ecore-based EAST-ADL metamodel that serves the deployment in the EAST-ADL modeling environment “EATOP” (where we call the latter metamodel “implementation MM” in the paper). Steps of the scenario: - We execute the transformation. - Compared to the documentation MM from part 1, we show which structural changes are conducted and which implementation details are added through EAnnotations to the implementation MM. These structural changes and implementation details are expected by the EATOP modeling infrastructure (cf. part 3). - We show further generated artifacts like the XML schema file, Genmodel, and plugins encompassing model/edit code.

== Part 3 == We deploy the implementation MM and the generated plugins to the EATOP modeling infrastructure. Steps of the scenario: - We deploy the newly generated plugins into the development workspace of the EATOP modeling infrastructure. - In the EATOP runtime, we first show how we create instances of the newly added language concepts. - Furthermore, we show how the changes that were conducted as part of the transformation from the documentation MM to the implementation MM (cf. part 2) influence the representation in the EATOP runtime in terms of menu structure, custom serialization format, and documentation texts.