Before we look at how to package service extensions we need to understand the packaging of the base product.

Below we showcase project structure of an OBAPI base module. We take approvals as an example.

1. Main-module-project.
2. Sub-project containing all the schedulers required by the module.
3. Sub-project containing all the services comprising the module. (Majority extensions fall under this subproject).
4. Sub-project containing all the Data Transfer Objects used in other sub-projects
5. Sub-project containing validators used to validate Data Transfer Objects facilitating input to OBAPI.
6. Sub-project containing classes used to make cross module calls.
7. Sub-project exposing endpoints to UI for end user to interact with OBAPI.
8. Subproject exposing endpoints used by other module’s services to consume the services of this module via REST.
9. Sub-project containing JMS listeners required for the functioning of this module.

Each of the above listed subprojects are gradle projects which are then built into their respective jars. In case of the example shown above the jars artifacts resulting from the build are as given below.

1. com.ofss.digx.app.<<moduleName>>.scheduler.jar eg. com.ofss.digx.app.approval.scheduler.jar
2. com.ofss.digx.app.<<moduleName>>.service.jar eg. com.ofss.digx.app.approval.service.jar
3. com.ofss.digx.app.<<moduleName>>.xface.jar eg. com.ofss.digx.app.approval.xface.jar
4. com.ofss.digx.app.<<moduleName>>.xface.validators.jar eg. com.ofss.digx.app.approval.xface.validators.jar
5. com.ofss.digx.app.<<moduleName>>.adapter.jar eg. com.ofss.digx.app.approval.adapter.jar
6. com.ofss.digx.appx.<<moduleName>>.endpoint.jar eg. com.ofss.digx.appx.approval.endpoint.jar
7. com.ofss.digx.ixface.<<moduleName>>.endpoint.jar eg. com.ofss.digx.ixface.approval.endpoint.jar
8. com.ofss.digx.jms.<<moduleName>>.listener.jar eg. com.ofss.digx.jms.approval.listener.jar