wiki:Meetings/Meet-2011-03-15
Last modified 12 months ago

  1. KIELER Modularization Task Force Meeting
    1. Discussion
      1. Problematic Use Cases
      2. Possible Solutions
      3. Final Solution
    2. The Plan

KIELER Modularization Task Force Meeting

  • Date: March 15th, 2011
  • Attendants:
    • cds
    • chsch
    • cmot
    • haf
    • msp
  • Protocol: cds
  • Begin: 10:25
  • End: !11:50

Discussion

Problematic Use Cases

We have identified the following use cases as currently being problematic:

  1. New developers have to decide which plug-ins they need in their IDE.
  2. Auto builds break when building a plug-in that depends on recent changes in another plug-in.
  3. Users don't know which features they should install.
  4. Potential developers cannot distinguish between production code, experimental code and legacy code.

Possible Solutions

We have talked about the following approaches:

  • Eliminate dependencies between features (problems 2 and 3)
    • Define new features that contain all plug-ins they need. That way, features could be installed without having to worry about any other features they depend on.
    • Less features would be needed. Installation would get easier, because the features could be geared towards our research areas without having to know about individual projects.
    • A problem is that every feature would have to be built separately during the nightly build process -> time consuming
      • Could perhaps be remedied by introducing Maven to manage dependencies.
  • Project sets (problem 1 and 4)
    • Hard to manage if there are many project sets.
    • Easy to use for developers.
    • Perhaps only have very few project sets, comparable to the features.
    • Could be automatically generated somehow.
  • Dependency graph (problem 1)
    • Introduce an automatically generated graph showing the dependencies between our plugins.
    • Harder to use for developers.

Final Solution

We propose the following solution:

  • Have few features. The features must be self-contained and geared towards research areas. They must be configured manually.
  • Automatically transform the feature definitions to project sets for developers.

The Plan

Your mission, should you choose to accept it, ...

  • Prepare the features. We propose the following features: (included are the names of those responsible for creating that feature, as well as a list of plug-ins that could be part of it)
    • SyncCharts (haf+cmot)
      Relevant Core parts, SyncCharts, Esterel, S, Ptolemy, KIEM, KSBASE, KIML, GraphViz, KARMA, KEX (with SyncCharts examples)
    • KAOM (msp)
      Relevant Core parts, KAOM, KIML, Ptolemy import, KARMA, KLoDD, Klay, KEX (with KAOM examples), KVID, KIEM, Validation Manager
    • UML (jes+cmot)
      Papyrus bridge, Maude, KIEM, KIML, OGDF (class diagrams), GraphViz, Validation Manager, KEX (with UML examples)
    • KEG (msp)
      Editor, GrAna, KIML, KSBASE, all layout algorithms, Import / Export incl. XML formats, KEX (with layout examples), Layout View
    • Layout Graphiti (msp)
      KIML, all layout algorithms, Graphiti integration
    • Layout GMF (msp)
      KIML, all layout algorithms, GMF integration
  • Update Hudson
    • Include new features. (done by those responsible for the respective features)
      • Job name begins with Feature2.
      • Folder features/de.cau.cs.kieler....feature2.
    • Write the transformation that turns feature definitions to project sets. (haf)
    • Update the documentation (Wiki) to link to the generated project sets. (?)
  • Deadline: Next KIELER release, mid April