I think that is governed by this code, which is then used by CTK

#!
#! Extract all library names which are build within this project
#!
#! \ingroup CMakeUtilities
macro(ctkMacroGetAllProjectTargetLibraries all_target_libraries varname)
  # Allow external projects to override the set of internal targets
  if(COMMAND GetMyTargetLibraries)
    GetMyTargetLibraries("${all_target_libraries}" ${varname})
  else()
    set(re_ctklib "^(c|C)(t|T)(k|K)[a-zA-Z0-9]+$")
    set(re_ctkplugin "^org_commontk_[a-zA-Z0-9_]+$")
    set(_tmp_list)
    list(APPEND _tmp_list ${all_target_libraries})
    #message("calling ctkMacroListFilter with varname:${varname}")
    ctkMacroListFilter(_tmp_list re_ctklib re_ctkplugin OUTPUT_VARIABLE ${varname})
    #message(STATUS "getallctklibs from ${all_target_libraries}")
    #message(STATUS varname:${varname}:${${varname}})
  endif()
endmacro()

So we could extend our macro to allow a list of external naming schemes, which are considered valid as well.

In T24149#121433, @goch wrote:

I think that is governed by this code, which is then used by CTK

This is correct.

So we could extend our macro to allow a list of external naming schemes, which are considered valid as well.

I came to the same conclusion. ;)
So only thing that was unclear to me/undefined, is where we allow to define the naming schema.

I would suggest a best practice of one naming scheme per extension directory and adding it to the PluginList.cmake

list(APPEND extensionNames exProject)
# Plug-ins must be ordered according to their dependencies
set(MITK_PLUGINS
  org.exProject.gui.qt.testplugin:ON
)

with extensionNames then being translated from "A;B;C" to "^org_A_[a-zA-Z0-9_]+$", "^org_B_[a-zA-Z0-9_]+$", "^org_C_[a-zA-Z0-9_]+$". An "unintended feature" would be that custom hierarchies could be set where "biguniversity_institute_oceanography" makes sure that the naming scheme of "^org_biguniversity_institute_oceanography_[a-zA-Z0-9_]+$" has to be followed.
One issue would be that each extension directory could completely overwrite extensionNames, but that is something I would be willing to accept, as it should be readily apparent and is easily fixed.

One issue would be that each extension directory could completely overwrite extensionNames, but that is something I would be willing to accept, as it should be readily apparent and is easily fixed.

One could move the append into MITK's cmakelists instead of letting the extension append it. So the extension sets the variable an its content (if set) is collected and then used in cmakelists.txt of mitk.

Do we really have to be strict about the naming scheme? Or asked from a different perspective, is it harmful to allow arbitrary naming as long as it follows the basic foo.bar.baz pattern in case CTK insists on it? So if possible we should consider not ot enforce naming schemes for others without any technical reason to do so. In case we want to still enforce the org.mitk prefix for our own plugins, we should adapt our validation code as local as possible but loosen the general top-level check.

My suggestion could only enforce org.* if you set the extension names explicitly to "". Would this still be to restrictive for you?

Yes, as I know of some examples where I have seen Java prefixes like com.* and so on. So it's not uncommon.

For the code in MITK.git, I would keep "org.mitk.*" as mandatory naming scheme.

For extensions, I could live with no restriction. It is more the question if we are willing to offer scheme feature for extensions to help extension maintainers to ensure correct plugin naming and something like namespace for plugins.

I would prefer offering the option to ensure naming. Partly because a lot of the first extensions will be maintained by us anyway and we currently have a naming convention.

Pushed new branch T24149-AllowOtherNamingSchemesForExternalPlugins.