@nolden FYI: you can (auto-)link tasks and Differentials by either

Deleted branch bugfix/T28002-ImprovePackageDependsFiles.

• Regarding 1: This is done to ensure that you are notfied if a problem arrises in the dcmsend step?
• Regarding 2: Do we have a test to verify if the problem still exists before we go into production with this? @gaoh: Was this a problem on the CTP side or on the DICOM4CHE side? So, did also other PACS like orthanc had the same problem?
• Regarding 3: This road I would only go, if we also have a test suite ready to benchmark the performance and to ensure that we don't have the same problem problem. What kind of reciever would you use here.

PACKAGE_DEPENDS now properly supports Boost, OpenMesh, OpenMP, OpenSSL, and Python3. For example:

Compensated for 2. Text was revised in T27677.

https://phabricator.mitk.org/D443

I can confirm this fixes the issue, I can merge it tomorrow

I would consider three different variants:

1. Keep CTP as receiver -> move the dcmsend from ctp-pipeline to airflow (unknown end of transfer issue)
2. Keep CTP as receiver and change the DICOMweb send pipline-step to the old DIMSE step (possible issue with missing slices <-> really fast)
3. Don't use CTP at all -> Start a DICOM receiver in Airflow as a sensor and trigger DAGs at arrival (performance unknown)

Pushed new branch T28017-VTK9-CodeIssues.

In T27573 we discussed the problem of data transfer from CTP to DCM4CHE.
So basically it is a kind of similar problem: A datatransfer between CTP and DCM4CHE fails.
The problem is then, CTP just keeps the data in the queue (here) or inserts in the quarantine folder (T27573).
Anyway, we do not get notified, that there is a problem.

It sounds nice, but I also think that we can run into cumbersome situations w.r.t. package management and version control with this approach: If the web app is located within the package, for each change to the package itself, it has to be investigated how the change affects the web app. The developer also has to adapt and test the web app then. This also means that for each package release, a corresponding web app has to be provided. In my opinion it makes more sense to focus either on the package or the web app during the development. Probably, we want to improve the web app that is based on a fixed package version x most frequently. This use case is then hampered by this approach as the package itself also evolves.

Pushed new branch T28017-VTK9.

After reading the itk::NumericTraits documentation and looking into the actual definitions of ZeroValue() I guess the fix could be:

TARGET_DEPENDS parameters are directly passed to target_link_libraries() and bypass the PACKAGE_DEPENDS mechanism.

Public API change: Depending on VTK does not add a transitive dependency to Qt5 Widgets anymore, except, when the required VTK components have a public dependency to Qt5 Widgets of course.

Fixed VTK and TinyXML-2 so far.

Pushed new branch bugfix/T28002-ImprovePackageDependsFiles.

Holy moly, I just learned that the package depends files work completely different than I thought/was told the past 9 years. Instead of fixing the mitk_use_modules() function we just need to use the package depends files correctly.

So for the current develop:
With or without CGET activated. When trying to Retrieve a dataset after Query, I get an Exception:

• mitk_create_module() passes PACKAGE_DEPENDS to _mitk_parse_package_args()
  • The PACKAGE[|COMPONENT1[+COMPONENT2]...] syntax is processed and the following variables are set in parent scope:
    • <PUBLIC|PRIVATE|INTERFACE>_PACKAGE_NAMES: Lists of package names for different visibilities
    • PACKAGE_NAMES: Joined lists from above (may contain duplicates!)
    • <PUBLIC|PRIVATE|INTERFACE>_<PACKAGE>_REQUIRED_COMPONENTS: Lists of components for different visibilities and packages
• mitk_create_module() passes PACKAGE_NAMES to mitk_check_module_dependencies()
  • mitk_check_module_dependencies() passes PACKAGE_NAMES to _mitk_parse_package_args()
    • Notice that PACKAGE_NAMES does not contain visibilities anymore, so everything is put into PRIVATE_PACKAGE_NAMES by default
  • Nevertheless, all visibility lists are joined into package_names and duplicates are removed (why not just use PACKAGE_NAMES in the first place and remove duplicates?)
  • For each package, check if MITK_USE_<package> is not set and add package to _MISSING_DEP in parent scope together with missing modules
• Also: Duplicates in PACKAGE_NAMES were removed by mitk_check_module_dependencies()
• The module is disabled if there are any missing dependencies
• PACKAGE_DEPENDS is passed to mitk_use_modules() as PACKAGES parameter

@jsolislemus There's a workaround if you can't wait for the next release which would also verify if your issue is fixed:

@thomass could you check if the problem was realy just cuased by slow network drive and is solved. If this is the case, could you close the task? If the problem still exists, may be the issue solved by Stefan is a solution.

@gaoh could you check if the problem is solved either with the branch or as soon as it is in develop?

I would see it positiv. No sense crying over spilt milk. Thanks for solving that problem!

apparently a vtkLoopUpTable is set automatically so the property as such cannot be used to handle custom vtkLookUpTables

Hi, from what I've been reading, it seems this issue might be fixed? I read on T26264 that it might be fixed with a CMake variables related to the DCMTK dictionaries; although I'm not sure how could I implement it myself, while waiting for the next release (we're still developing on top of 2018.04.2). Thanks a lot for the effort, this error seemed very difficult to pinpoint.

Mixed feelings here: On one hand I'm happy that we, with a single trivial line of CMake code, finally fixed a decade old severe issue we had in MITK without really noticing it causing quite some inconvenience for our users and we were not able to reproduce it over the years. Maybe we even lost some users right before they actually used MITK because "it cannot open my DICOM files". On the other hand, we fixed a decade old severe issue with a single line of CMake code.