Update Pluggable approach for Mappers and Drivers authored by Rustam Lotsmanenko (EPAM)'s avatar Rustam Lotsmanenko (EPAM)
......@@ -15,7 +15,8 @@ Key points:
- **Dynamic Dependency Wiring**: This solution enables dynamic dependency wiring at runtime, allowing for the swapping of dependencies as needed. The OSDU service relies on the Driver's self-sufficiency, which involves autonomous component assembly within the Driver. This approach fosters a loose coupling that allows for dependency swaps without requiring changes in the service. <br/>
![Untitled_Diagram.drawio_14__1_](uploads/c81ada18daa4a7ef5474a26cf5d5c467/Untitled_Diagram.drawio_14__1_.png)
- **Plugin usage is not mandatory**. Provider implementations could use community Drivers and their own Drivers as direct dependencies of their service implementation. The compile step configured for community Drivers is not mandatory for provider Drivers. Furthermore, the community Drivers will have 2 artifacts, the original jar which could be used as a regular dependency, and the Uber jar or plugin jar. <br/>
![Untitled_Diagram.drawio_15_](uploads/c3f9a1046e226dffb412388ee7186a4c/Untitled_Diagram.drawio_15_.png)
![Untitled_Diagram.drawio_15__1_](uploads/881dbe146f587def0bd60a7ff7c65140/Untitled_Diagram.drawio_15__1_.png)
### 3. Use Cases
#### Common Binaries and Custom Drivers:
......@@ -34,7 +35,7 @@ Key points:
- The plugin-based approach does not impose mandatory usage of Maven Shade and Uber jars.
- Providers have the option to introduce their drivers as they are and use them in the provider module as direct dependencies.
- Additionally, the community's south decision point or core-plus module won't require providers to remove already bundled community dependencies since they are not present.
![Untitled_Diagram.drawio_15_](uploads/c3f9a1046e226dffb412388ee7186a4c/Untitled_Diagram.drawio_15_.png)
### 4. Prerequisites
......
......