Difference between revisions of "Sirius/Modularization"

Revision as of 10:18, 29 July 2013

The move to Eclipse, which implies a complete renaming of the existing Viewpoint code base, implies by definition a major API break. We want to take this opportunity to improve the code modularization. This page describes the target organisation and the actions needed on the current code base to get there.

Note: The page may sometimes refer to the structure of the source code before the conversion to Eclipse, which is not publicly visible.

Git Repository Layout

The source code will be in a single Git repository, organized in the following directories:

• plugins: source code for all the plug-ins of Sirius itself;
• doc: the documentation plug-ins;
• examples: example Sirius modelers and sample metamodel definitions used by the examples and/or the tests;
• tests: automated tests (JUnit and SWTbot);
• features: feature definitions (including doc, examples and test features);
• releng: parent project (for the root POM and shared files), target platform definitions, update-sites definitions;
• tools: source code for development tools that contributors must install in their development environment (e.g. Acceleo generators used to generate parts of the source code). These are not part of Sirius but are required to develop Sirius.

Modularity Criteria

The general criteria used to define the plug-ins boundaries are:

• Common vs Runtime vs Tooling
  • Runtime code is needed to execute a deployed Sirius modeler;
  • Tooling code is needed to develop a Sirius modeler;
  • Common code is shared by both runtime and tooling;
  • Both runtime and tooling plug-ins can depend on common plug-ins (that is their purpose). Tooling plug-ins may depend on common and runtime plug-ins (for example to make sure the tooling knows exactly how something will be interpreted by the runtime), as long as the runtime plug-in is not more dialect or technology-specific than the tooling plug-in (for example, a generic tooling plug-in can not depend on a diagram-specific runtime plug-in).
• Generic vs Dialect-Specific vs Technology-Specific
  • Generic means dialect-agnostic, it corresponds to code which is common to all kinds of representations supported by Sirius (diagrams, tables, etc.)
  • Dialect-Specific corresponds to the core semantics of a kind of representation (e.g. diagrams), independently of the concrete technology used to implement it;
  • Technology-Specific corresponds to the concrete implementation of a dialect on top of a specific technology (e.g. GMF Runtime for diagrams).
• Core vs Eclipse-specific vs UI
  • Core code is pure library code with no dependency on any runtime framework (or maybe juste OSGi), and can be run headless and outside of an Eclipse runtime;
  • Eclipse-Specific code depends on the Eclipse framework, but not on the UI; it can still be run headless;
  • UI code requires a complete Eclipse Workbench (and provides the integration inside of it).
• API vs internal API vs SPI vs internal (this is more for package boundaries than plug-in boundaries)
  • API is the official API that can be used by non-Sirius code;
  • internal API is technically API (i.e. exported by the OSGi bundles) but reserved for internal usages inside of Sirius itself. It can be used by non-Sirius code but it does not have the same kind of guarantees in terms of backward compatibility;
  • SPI (Service Provider Interface) is specifically targeted for systems which want to extend Sirius. This typically includes extension points and interface definitions that extender must implement. These may be used by Sirius itself, for example to provide default implementations.
  • internal is all the rest, and is not accessible outside of Sirius.