To Discuss in Jour Fixe

The intention of this page is to list the points to be discussed in the next jour fixe.

  1. Update of the developer version to 2019-06

Log of finished discussions

  1. AF3 platform update (2018-12)
    1. Will require a reinstallation.
    2. Currently under review/testing (negligible code changes).
    3. MacOS version also under testing.
    4. Single build configuration: Configure once, be happy.
      1. New maven-releng repository: Maven configuration + Git submodules.
      2. Enables jenkins + local builds with the same configuration.
      3. Derivative product (projects, pratical course) is easy now.
      4. We now use a target platform to centrally define external dependencies (p2).
      5. Separate repositories for the af3 tests, features, product, rcp.
    5. We may need our own osgi-p2 repo (easy): Currently, we use an osgi-repackaged version from bestsolution (efxclipse).
  2. Reassign Filips tickets
  3. Platform maintainers needed
    • Windows (known issues: #3577)
      • Alex
    • Linux (known issues: Ubuntu icon and color scheme problems, GTK crash / SWT_GTK3 flag)
      • Ubuntu: Hernan
      • Fedora: Flo
    • Mac (known issues: #3592, #3385)
      • Johannes
  4. AF3 platform update (2018-12)
    1. Support for free use of Oracle JDK 8 in companies ended in January 2019.
    2. Maven integration is finished.
    3. Short timeframe before release: In-depth testing needed.
    4. E(fx)clipse will be officially released on Feb. 28th --> Currently uses nightly update site (the only operational version). Early rollout would require devs to manually update the p2 site.
  5. JDK-11 & eclipse 2018-12 migration almost completed:
    1. Developer installation is operational
    2. Product build was reworked: no more scripts needed, pure maven. This allows identical builds locally.
  6. APACHE License @repos
    • Done: af3, kernel, fortiss-std-env, exploration-alg.
    • Open: jenkins-af3, jenkins-kernel, practical course
  7. Update the wiki
    • Status
  8. Update the wiki
    1. Check for out-of-date articles.
    2. Define responsibilities.
    3. Update the release test cases & separate them by pre-build and post-build tests.
  9. Amalthea / App4MC support
    OUTCOME: Can be integrated, if desired. No concerns were raised due to import of basic model elements (platform, tasks, ...) > Maintainability.
    • Partial import of Amalthea has been implemented in ARAMiS II (currently in an experimental plugin)
    • Amalthea plans extensions w.r.t. deployment constraints that consider hierarchical architectures (compartments, processors, cores, ...)
    • Since App4mc plans to link tools that support Amalthea, it should be discussed if Amalthea support should be integrated into the official release.
  10. af3.allocation is intended as a generalization of af3.deployment
    • In the mid-term, af3.deployment should be obsoleted by af3.allocation
    • Discussion: Which (non-official) plugins or branches make use of af3.deployment (needed to estimate the migration effort)
      • practical course (via code generation)
      • OBC-SA
  11. Failing tests in jenkins: Filip will examine the jenkins log.
  12. AF3 Transition to Photon
  13. What to do with the refinement plug-in? --> Needed for Spedit.
  14. Releases:
    1. Official MacOS support will be abandoned.
    2. A virtualized AF3 distribution shall be built.
  15. Development workflow: In case changes are requested for a Merge Request, the "Feedback implemented" label has to be assigned to the MR as an indicator.
  16. Import Service similar to eclipse new/import/export wizards (Planning)
    1. Is there more than one use case (App4MC)?
    2. Requires a kernel / base service.
    3. GUI can be programmed using ControlsFX (JFX): ; License 3-clause BSD
    4. Would be more convenient than several "Import ..." entries in the file menu.
    5. > Delayed until more use cases appear.
  17. There is no person responsible for the git repository named "publication".
    1. ==> Permission to push for everyone
  18. Issue tracking
    1. Available Tools (Server-side):
      • Gitlab
      • Redmine
      • Bugzilla (
    2. Available Tools (Client-side):
      • (Web browser)
      • Mylyn
    3. Mylyn integration available for
      • Redmine, integrated: Requires server-side plugin, unofficial plugin set.
      • Redmine, web-based: Mylyn official incubation plugin. Less integrated, but "connects" to git.
      • Bugzilla
    4. General considerations:
      • Mylyn integration allows to write pre-configured commit messages (e.g., ID of an activated task is automagically inserted, etc.).
      • Gitlab issue tracking would require a migration of the db.
      • Using Mylyn in combination with some other issue tracker than gitlab (currently the only option for mylyn) implies less automation based on the text written in commit messages.
      • If mylyn is used, the interaction with the WebUI (gitlab) is minimal.
  19. Reminder: Assign a responsible to every current plugin the the root: See AF3_Plugins_Description
  20. Cont'd: Eclipse Oxygen as development platform
    • Question: Also upgrade target platform, or stay with Kepler for now (e.g., because of: E4 application, OpenGL)?
    • Pro: Enables to use Oomph on Mac
    • Issue: Code formatter has different behavior (with same configuration)
    • Pro (?): More Java warnings (e.g., due to Java 9 support)
  21. Copy&Paste
    • Cross-project Copy&Paste introduces references to original model resource
    • Handling copy&paste of referenced "related" model elements
      • #2343: Handle complex copy&paste operations in the tooling plugins
      • #1865: MIRA: Copy traces when copying requirements
      • Current solution: ISpeciallyCopyable
    • Discussion
      • What has to be fixed for AF3 (e.g., to support MBSE lab course and MODELS tutorial), what can be postponed to AF4/SF?
  22. Java 9/10 seems to be supported by the latest AF3 release (tested on windows 10).
    • Oxygen as a development platform enables using recent java versions (>=1.8.151) under Mac OS X.
  23. Code Reviews & Testing
    1. Features / Larger changes: Find someone; Code has to be green when a MR is assigned to master.
    2. Small Bugfixes: Code review can be done by the master. Code has to be yellow.
  24. Update AF3 homepage "About Us" section
  25. Warnings:
    • Has something changed in the "warnings filter"? I see a couple of warnings which did not appear in the old installation.
  26. Date for the next release
  27. Date for the next hackaton (topic: make code GREEN and warning free)
  28. Can the simulink plugin go to attic?
  29. Code review
  30. GIT migration
  31. NEW: Allow @SuppressWarnings("Deprecation") for migration classes.
  32. svn tags reappeared!! Find a way to ensure that it doesn't happen in future. Maybe a process/checklist to include a new plugin in the product.
  33. Post Release version? Do they make sense? HOMEWORK: Update issues from 2.11 and 2.12 and those with no target to 2.13
  34. Bug #3199 occured to somebody other than the reporter?
  35. Plugin Cleanup: shall we move some pluggins to the attic?
  36. There are about 100 issues which are not assigned to anyone, and are therefore not appearing in Filip’s query. What to do with them?
    • Procedure to deal with this situation is started as homework for over-next JF.
    • Why not make "assignee" field mandatory for the open issues.
  37. What is the purpose of "AF3 Phoenix - Backlog"?
    • Procedure to deal with this situation is started as homework for next JF.
  38. Safely updating a metamodel: Ecore Builder documentation has been extended with best practices for metamodel modifications.
  39. Introduction of Oomph developer installation procedure and new code rating tool AF3 Developer Installation with Oomph
  40. DevTools NG
    • Apart from .java inside src/ folder (without * all html files inside the top-level html folder are subject to rating #3194?
    • Rating outdated warning will be kept until a testing phase has shown that this warning is not helpful, i.e., forces people to rate their code and, hopefully, learn to always make their code YELLOW #3204.
    • Each plugin requires a "/html/developer/documentation.html" to be present.
  41. Dealing with obsolete code:
    • Obsolete code is found by running unnecessary code detector on a workspace with all code (AF3, SFit, others)
    • The found obsolete code is marked as deprecated and everybody can check, which functions should remain.
    • Obsolete code is removed after a while when no vetos have been issued.
  42. Should we move to git? Preliminary investigation are started about our options.
  43. Properties vs. Annotations: when to use which one?
    • Property section should be used to display multiple attributes of a single edited entity.
    • Annotations should be used for globally relevant attributes, and also be displayed in the property section.
    • Properties should selectively be included in the annotations view if required.