Page MenuHomePhabricator

Improve folder layout to simplify setup of different applications
Closed, ResolvedPublic

Description

Driver by QM requirements we want to improve the directory layout of Modules, Bundles and Application. Instead of Core/CoreUI there will be different sets of folders that require certain bugilla flags or other regulatory rules.

In this bug we should discuss a proposal first (written by Sascha) and then plan how to implement this regarding hook improvement and side effects on ongoing developments or external projects.

Event Timeline

Currently, we have the following folder structure in MITK:

Applications

  • CoreApp
  • ExtApp

BlueBerry
Core
CoreUI

  • Bundles
    • org.mitk.core.services
    • org.mitk.gui.qt.common
    • ...
  • BundleTesting
    • org.mitk.gui.qt.common.tests
  • Qmitk

Modules

  • Bundles
    • org.mitk.core.ext
    • ...
  • CameraCalibration
  • ...

...

In the last meeting, we agreed to remove the CoreUI folder and to put all plug-ins into one top-level folder. I'd suggest the following new layout:

Applications

  • CoreApp
  • ExtApp

BlueBerry
Core
Modules

  • CameraCalibration
  • ...
  • Qmitk
  • ...

Plugins

  • org.mitk.core.ext
  • org.mitk.core.services
  • org.mitk.gui.qt.common
    • Testing (previously in org.mitk.gui.qt.common.tests)
  • ...

(In reply to comment #1)

Applications

  • CoreApp
  • ExtApp

BlueBerry
Core
Modules

  • CameraCalibration
  • ...
  • Qmitk
  • ...

Plugins

  • org.mitk.core.ext
  • org.mitk.core.services
  • org.mitk.gui.qt.common
    • Testing (previously in org.mitk.gui.qt.common.tests)
  • ...

I like this suggestion, puts Qmitk where it belongs.

Would the following make it even more clear? It would mark plugins more clearly as belonging to BlueBerry/CTK.

Core
Modules

  • CameraCalibration
  • ...
  • Qmitk
  • ...

BlueBerry

  • Core
  • Plugins
    • org.mitk.core.ext
    • org.mitk.core.services
    • org.mitk.gui.qt.common
      • Testing (previously in org.mitk.gui.qt.common.tests)
    • ...

Applications

  • CoreApp
  • ExtApp

Regarding flags and rules, I'd like a system where we could extend the "Core Change Request" system to other important modules (where somebody also promises to define the scope, provide documentation etc.), including provision of a list of promised but unimplemented unit tests :-)

(In reply to comment #2)

Would the following make it even more clear? It would mark plugins more clearly
as belonging to BlueBerry/CTK.

Core
Modules

  • CameraCalibration
  • ...
  • Qmitk
  • ...

BlueBerry

  • Core
  • Plugins
    • org.mitk.core.ext
    • org.mitk.core.services
    • org.mitk.gui.qt.common
      • Testing (previously in org.mitk.gui.qt.common.tests)
    • ...

Applications

  • CoreApp
  • ExtApp

BlueBerry has no dependencies on MITK. In my opinion, it should stay that way.

(In reply to comment #4)

BlueBerry has no dependencies on MITK. In my opinion, it should stay that way.

Sure, that was not my intention. But A lot of plugins (ExtApp plugins) have not only MITK-Core dependencies (which are natural by name of the overall project) but also depend on Blueberry, which would become move visible with my suggestion. However, I'm not too sure if this is important to see.

(In reply to comment #5)

(In reply to comment #4)

BlueBerry has no dependencies on MITK. In my opinion, it should stay that way.

Sure, that was not my intention. But A lot of plugins (ExtApp plugins) have not
only MITK-Core dependencies (which are natural by name of the overall project)
but also depend on Blueberry, which would become move visible with my
suggestion. However, I'm not too sure if this is important to see.

Okay, but moving it there would require some CMake hacks to keep the BlueBerry folder MITK clean. Right now (at least theoretically) one could rip out the BlueBerry folder and compile it as it is.

Naturally, (almost) all of our Plug-ins have a BlueBerry dependency. Some may be CTK-only. We could try to make this distinction more clear.

I would like to get that done early today. Are there more suggestions for the plug-in directories?

Personally, I would just stay with "Plugins".

I prefer the first proposal. BlueBerry is an (optional) plugin dependency like for example Qt is an (optional) module dependency. I don't think we should express dependencies by folder hierarchy. Plugins and Modules are fundamental different concepts so it is a good idea to put them in different folders but everything else should be as simple as possible.

i like the layout as proposed by sascha. concerning the hooks: the script currently investigates if a commit touches a path beginning with "Core" to check if this commit must be checked for a modification flag. so by removing CoreUI Qmitk, etc. is not checked anymore.
if Marco agrees i can extend the script so that it uses a *list of path beginnings* instead of just "Core". then all Modules/plugins under special "Core" surveillance are simply put into this list. i dont see any problem here. except that this change must clearly communicated.

[67b92d]: Merge branch 'bug-11038-simplify-source-code-layout'

Merged commits:

2012-02-23 21:33:44 Sascha Zelzer [d2ea22]
Removed CoreUI directory and merged CoreUI/Bundles and Modules/Bundles.

There is now a top-level Plugins folder containing all MITK plug-ins.
Further, the BlueBerry build system support for BlueBerry-style plug-ins
has been dropped.

[dbf559]: Merge branch 'bug-11038-simplify-source-code-layout'

Merged commits:

2012-02-24 08:15:17 Sascha Zelzer [fcde09]
Removed legacy CMake code.

[91b30c]: Merge branch 'bug-11038-update-internal-plugin-version'

Merged commits:

2012-02-24 11:18:01 Sascha Zelzer [37013c]
Removed irrelevant version_name_hash info and bumped PLUGIN_SYSTEM version to 2.

[b86e97]: Merge branch 'bug-11038-simplify-source-code-layout'

Merged commits:

2012-02-24 18:39:42 Sascha Zelzer [e4dc7e]
Fixed ordering of plug-ins.