Skip to end of metadata
Go to start of metadata
23 April 2009
- Mike Seaton
- Ben Wolfe
- Darius Jazayeri
- Burke Mamlin
- Justin Miranda
- Paul Biondich
- Brian McKown
- OpenMRS 1.5 alpha needs to be released. Release Manager volunteers? -Ben 10:23, 20 April 2009 (EDT)
- Discussion about modules - need new features for modules (some rough thoughts outlined below)
- Move towards a Linux/Eclipse idea of thin kernel + lots of modules with complex dependencies
- i.e. OSGI implementation of module framework
- Need to move all non-patient related components into Core Modules
- Some modules that should be included as Core Modules ...
- Scheduler API
- Reporting API
- Form API
- (there are others – just can't think of them at the moment)
- We can then build modules that are based off Core Modules and have their own roadmap/versioning
- Requires a more strict versioning and dependency
- Need to support plugins for API components that are not patient-related
- Need to add more separation between core API and implementation/tool modules (i.e. simple web)
- Need to support module bundles
- Allows us to create a reporting module bundle that holds multiple modules that work together
- Allows us to install and start a bunch of modules together
- Allows us to add/remove modules together
- Keeps implementers from having to choose modules that are compatible
- Modules need upper version dependency (works with OpenMRS 1.4.7+, but not 1.5.0+)
- Module IDs should be fully qualified package (like Eclipse)
- Move old reporting to a Core Module
- Need to consider using this module as a library within trunk/lib
- 1.5 Alpha release?
- the alpha doesn't need to be feature-complete. aka, 1.5.x doesn't need to be created
- We need to create a recipe for testing the web. pih/sync has a google doc to keep track
- The google doc just has a list of things to test. if it fails before a release, the error message or a red x is placed (manually) into the google doc.
- We don't need to spend hours coming up with tests. But we do need to figure out.
- TODO: Darius copy pih google doc over to public place and link to from
- release manager: Ben
- (Justin volunteers to be release manager for 1.6)
- Do we need to pass through the tickets and assign everything to 1.5/1.6/someday?
- We need to look at Jira's Jira to see how its "supposed" to be done. (or trac's trac?)
- Background: Justin/Mike are working on reporting and see things in core that really aren't core to an MRS. (Things like form/cohort/reporting/etc)
- Started adding module dependencies and seeing weaknesses in our module framework
- Changing core to a more a modular based framework would facilitate coding faster and getting releases out easier, less coordination of code, etc
- Modules still need to be fairly easy to write so that all the work isn't going into writing a module's shell and not code
- Reporting: Mike has taken most of reporting packages out to a module.
- Reporting: CohortDefinition has been removed, Cohort has remained
- Scheduler API: can be pulled out easily.
- Reporting: Do we want to pull out everything and just point people at the module? deprecate things for a version as much as we can?
- Reporting: Deprecate all reporting methods for 1.5. Delete web layer links, pages, controllers for reporting. Create reporting-1.0 to be included with 1.5 as a core module. For openmrs-1.6 move reporting objects/methods into reporting module and delete methods from core.
- Reporting: TODO: Mike will deprecate reporting methods in trunk before 1.5 release.
- OSGI: we don't need to switch to it right now.
- OSGI: Ben: From what I've read, osgi is above tomcat and you include that as a plugin within it.
- OSGI: TODO: Justin will read more about osgi
- OSGI: TODO: Paul will reach out to some people that have osgi experience (phillipe, kayolan, etc)
- TODO Ben: create a ticket to add an upper bound for version's required by a module