Run ref-distro with extension point:
Build an image of stock management service with tag 5.1.2-SNAPSHOT
Build a fat jar using the gradle fatJar task
Copy this fat jar to the example-extension /libs directory
Run docker builder for example-extension and copy created source jar to the /libs directory in example-extensions
Run docker builder and build an image of example-extensions with tag 0.0.1-SNAPSHOT
Verify if the default class was overriden by the extension
Check the forum post for more detailed information: https://forum.openlmis.org/t/extension-point-configuration/5683
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.
We have updated the ticket description. We’ll make sure that next ticket descriptions will be more complete.
What is the current status of this ticket? Why can’t we close it?
As far as I understand your discussion at https://forum.openlmis.org/t/extension-point-configuration/5683 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 (https://openlmis.readthedocs.io/en/v3.0.0/developer-docs/contributionGuide.html?highlight=extension) 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.”
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.
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.