Done
Pinned fields
Click on the next to a field label to start pinning.
Details
Details
Assignee
Paweł Gesek
Paweł GesekReporter
Sebastian Brudziński
Sebastian BrudzińskiStory Points
8
Original estimate
2d 3h
Time tracking
2d 3h logged
Components
Sprint
Add sprint
Fix versions
Priority
Time Assistant
Time Assistant
Created August 12, 2016 at 10:20 PM
Updated January 31, 2017 at 6:14 PM
Resolved January 16, 2017 at 3:47 PM
In order to avoid being redundant in our services, we will eventually want to have some kind of a "shared library". This story captures determining what this shared library is and how it is implemented. The spike should include how to add the shared library in the build process of the independent service.
OpenLMIS services could benefit from a shared library that reduces copy/pasted code between Independent Services. This shared library will contain only Java classes. The shared library should be published to Maven and pulled in to services from there.
A concern with a shared library is what occurs when the library has dependencies on 3rd party libraries that a Service also would have - and what happens when the versions are different on the classpath. To that end we want to publish guidance that takes a conservative approach:
be careful about dependent libraries that may also be used in the services
no spring dependencies
Acceptance:
a new git repo exists: openlmis-service-util
the utility project builds to a JAR via Gradle
the JAR is published to Maven central repo (OSSRH) in the same manner as the extension point & module mechanism (a Jenkins job will be needed)
the JAR is versioned similarly
the README has the stringent guidance for which utilities may be included