Verify Stock Management Extension Point


Acceptance criteria:

  1. Run ref-distro with extension point:

    1. Build an image of stock management service with tag 5.1.2-SNAPSHOT

    2. Build a fat jar using the gradle fatJar task

    3. Copy this fat jar to the example-extension /libs directory

    4. Run docker builder for example-extension and copy created source jar to the /libs directory in example-extensions

    5. Run docker builder and build an image of example-extensions with tag 0.0.1-SNAPSHOT

    6. Run ref-distro

  2. Verify if the default class was overriden by the extension

Check the forum post for more detailed information:


Klaudia Pałkowska
October 8, 2020, 8:27 AM

was reviewed by developers, and closed because adding an extension point took 1-2 days, but we got stuck with testing. So we created a separate ticket for verifying if it works and for more transparency what we are currently doing and what actually was done.

Paulina Buzderewicz
October 8, 2020, 8:33 AM

We have updated the ticket description. We’ll make sure that next ticket descriptions will be more complete.

Jakub Sławiński
October 12, 2020, 11:22 AM

What is the current status of this ticket? Why can’t we close it?


As far as I understand your discussion at the issue with the example service is that it is using build-time dependency instead of run-time and you think it is not a desired behavior.


However, I read through some old threads ( ) and through OpenLMIS docs ( and I think that it is a desired behavior. The main goal was to avoid forked code, not providing a real-time mechanism of hot code reloads.


Am I wrong?


“A project can insert their own strategy by creating an Extension Module, based on a provided template in a repository. This Extension Module will have a Java class that implements the extension point interface with a new strategy. The Extension Module is packaged with the rest of the Independent Service, its Spring context will be active in deployment, and the new strategy will be used.”

Sebastian Brudziński
October 12, 2020, 12:31 PM

I do believe the intention was always to have them as optional runtime dependencies. If they were compile-time dependencies this whole mechanism is over-complicated (we could just have ifs in the code that read some property file). Also if they were build-time dependencies, each implementation would need to rely on the core team to release the extension module they implemented.


  • Extension points → added and maintained by core team

  • Extension modules → added and maintained by implementations

Each implementation can start their own distribution of OpenLMIS that includes their own extensions. It works for UI in a similar way (non-dependant on core).

Howoever, given the findings, the scope of this ticket shifted to “Make extenssion modules work as runtime dependencies” - this needs to be communicated to and with an estimate so that we can plan the release.

Paulina Buzderewicz
October 20, 2020, 9:05 AM

Since the aim of this ticket was to verify that the extension points work and we managed to prove it, this ticket can be marked as completed. I’m moving it to Done.


Paulina Buzderewicz


Paulina Buzderewicz



Story Points


Time tracking





Fix versions