Off the top of my head some reasons why it feels thick. - Not having dependency management.. (I might have to install 3 modules just to get one module I need, while in Eclipse you just install the one you need and Eclipse lets you know what else it needs to install automatically). - Modules take a relatively long time to start/stop - The format of the modules admin page could be improved… once you’ve got 20+ modules you’ve got a lot of scrolling to do—and there isn’t any sorting capabilities, etc
I would agree that the two points Burke makes—improving management and making it easier to handle dependencies—are more important/better than making multiple modules look like a single module. Mark From: [email protected] [mailto:[email protected]] On Behalf Of Burke Mamlin Sent: Friday, January 13, 2012 3:16 PM To: [email protected] Subject: Re: [OPENMRS-IMPLEMENTERS] 1.10 MUST have Mark, can you think about how/why module management in OpenMRS feels "thick" to you? Both Eclipse & OpenMRS list their plugins/modules and let you manage them. Why in particular does Eclipse – with many more plugins – feel lighter to you? +1 for improving module management (in fact, Shazin did this for GSoC a couple years ago and it never got committed) +1 for ways to make it easier to handle dependencies (like including them with an omod or making the module manager capable of grabbing them for you if you have internet connectivity) I'm not excited (at least at first blush) about trying to make multiple modules (a module & its dependencies) look like a single module in the module manager, since dependencies are not 1-to-many (they're many-to-many). -Burke On Fri, Jan 13, 2012 at 1:46 PM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: Definitely a +1 here. I think that modules should be lighter, or at least there should be a lighter alternative. In Rwanda we are running 20+ modules, and we are going to be approaching that number in Haiti. That seems like "too much", but mainly because of the heaviness of module management. For instance, if I check my installed Eclipse plug-ins I see that I have a zillion installed--it is just much more transparent to me, and not something I have to worry about on a day-to-day basis. I envision some sort of dependency system, where if you download a module that requires other modules, it can automatically download the other dependencies for you. Another idea I had was to build a module that simply contains a set of related utility methods and/or services that I want to be able to use in many different modules... but I'd like to be able to do this without having to build a full OpenMRS module that implementers have to install independently. Mark -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Rafal Korytkowski Sent: Friday, January 13, 2012 12:01 PM To: [email protected]<mailto:[email protected]> Subject: [OPENMRS-IMPLEMENTERS] 1.10 MUST have Hey, 1.9 is almost out. I'd like to start a discussion on what to include in 1.10. Let's have a better module support! Module management needs to be improved. We're saying OpenMRS is a modular architecture, but it's hard to acknowledge working with the Manage Modules page. I'm asking for a feature that allows to pack a few modules together in a single omod which can be installed and managed as one. Let's say we have HTML Form Entry and HTML Form Entry Designer. There's no point in distributing HTML Form Entry Designer alone since it requires HTML Form Entry to run. The other example is still hypothetical. Let's say you want to share reports from the Reporting module using the Metadata Sharing module. For that to work you would need the ReportingMDSSupport module. Why you need to know that? It should be packaged and managed by the Reporting module. It's the Reporting module that should know that if the Metadata Sharing module is started, it should start the RerportingMDSSupport. Going further, there's a great new feature in 1.9: visists. In order for the HTML Form Entry module to make use of that you would need HTML Form Entry 1.9 Compatibility module. And then comes 1.10 with even better visits and you need yet another HTML Form Entry 1.10 Compatibility module. It's a management nightmare to install all those modules and keep them running, but should be easily managed by the HTML Form Entry itself which when installed on 1.9 should simply start the 1.9 Compatibility feature. Hope I explained the idea good enough! I'm waiting for thumbs up or down for this idea! -Rafal _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected]<mailto:[email protected]> with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-implement-l] ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
