+1 for pulling dependencies automatically over a live Internet connection. I've worked with the MDR-TB module which requires a rather long list of other modules some of which are only there because required modules are dependent on them. Automatically pulling required modules would make life much easier.
+1 also to Wyclif's point about a feature that lets you choose to clean up module data after an uninstall Ali On Sat, Jan 14, 2012 at 8:13 AM, Michael Seaton <[email protected]> wrote: > ** > I'm really happy that Rafal has raised this and would love to see many of > the improvements raised here. > > To Mark's point, let's say I have a few useful utility classes methods > that I have written in a module and I find myself copying / re-writing > these in many of my other modules. Obviously it would be better to be able > to maintain this code in one place and use it within my modules, rather > than try to maintain it in multiple places. Right now, the only real way > to do that would be to create a new OpenMRS module with these utility > classes, and to make all of my other modules require it as a dependency. > The problem with this is that an implementer has to actually do find the > "MyCoolUtilities" module and install it in order to install the module that > has the actual feature that they care about. This utility module really > has no meaning to them and is really an implementation detail. The > reporting module is sort of like this - you have to install the > "serialization.xstream" module and the "htmlwidgets" module before you can > install the reporting module. Neither of these modules provide any UI > components or features to an end-user, and are basically meaningless to an > implementer. But the implementer needs to find them, install them, and > maintain them nonetheless. I think this is an area we could improve with > some thought. > > I also want to strongly second the notion of trying to think through ways > where we can make it easy for modules to bundle support for multiple > (incompatible) OpenMRS versions, and to provide integration features > between itself and one or more other modules that are optional. Rafal's > examples are all on point. > > I would love to see this topic continue to be discussed, perhaps on an > upcoming design or developers call... > > Thanks, > Mike > > > > > On 01/13/2012 03:15 PM, Burke Mamlin wrote: > > 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]> 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]] On >> Behalf Of Rafal Korytkowski >> Sent: Friday, January 13, 2012 12:01 PM >> To: [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] with "SIGNOFF openmrs-implement-l" in the >> body (not the subject) of your e-mail. >> >> [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] >> >> > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list > -- Ali Habib Director, Informatics Interactive Research and Development Ph: +92-21-34327697 [email protected] _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
