Hi,
I'm not sure I get you. Every module always has a name. Of coude using
code like context->GetModule("name") couples the caller with the module
"name" via the character constant which is usually to be avoided.
I was thinking that every module (also auto-load modules) gets its own
test driver (under the modules "test" directory). So the coupling via
the name would only be between the module and its specific test driver,
which would still be quite "local".
However, using a pid is a more common solution to identify specific
services. Of course they become "public API" of that service and can't
be changed easily.
Best,
Sascha
On 04/15/2015 10:29 AM, Clarkson, Matt wrote:
> Hi Sascha,
>
> do you know how you might implement this?
> We can’t just remove the module name, or else every test driver will need
> updating.
> Will you provide an extra flag to say its only ever an auto-load module?
> Or if a module is only ever auto-loaded along with another module, then that
> should be the dependency?
>
> M
>
>
> On 11 Apr 2015, at 19:11, Sascha Zelzer <[email protected]> wrote:
>
>> Hi,
>>
>> good catch. We should probably not automatically add the linker dependency
>> in case of a test driver being created for an auto-load module. I will
>> change this ASAP (test drivers could still add the dependency explicitly
>> themselves).
>>
>> As a note, if you want to work with a specific service implementation in
>> your test, you could use:
>>
>> - A service property (e.g. "service.pid", for persistent identifier) to
>> identify the service object registered by the auto-load module or
>> - Get the services registered by the auto-load module in your test via
>> context->GetModule("auto-load-module-name")->GetRegisteredServices()
>>
>> Best,
>> Sascha
>>
>> On 04/11/2015 04:20 PM, Clarkson, Matt wrote:
>>> Hi there,
>>>
>>> If I have a module that ONLY contains MicroServices eg. New IO stuff, using
>>> the IFileReader and IFileWriter type interfaces, then as I understand it,
>>> nothing should need to link to this module. The module should be
>>> auto-loaded and services registered when autoloading. This includes unit
>>> tests.
>>>
>>> So, I have some Readers/Writers in a dedicated module, niftkCoreIO. This
>>> niftkCoreIO depends on MitkCore, and should be autoloaded. All code is in
>>> an “Internal” folder, and no symbols exported.
>>>
>>> But the CMake macro to create unit tests seems to create a specific
>>> dependency on niftkCoreIO.
>>>
>>> Is this right?
>>>
>>> https://github.com/MITK/MITK/blob/master/CMake/mitkMacroCreateModuleTests.cmake#L38
>>>
>>> Thanks
>>>
>>> Matt
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>>> Develop your own process in accordance with the BPMN 2 standard
>>> Learn Process modeling best practices with Bonita BPM through live exercises
>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>>> _______________________________________________
>>> mitk-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
