Some thoughts... Bundling modules together into one omod seems like a bad idea because it changes what an omod means. You can achieve the same effect anyway by just zipping up a bunch of omods and extracting them into your modules folder.
I think we should look at better tools for maintenance tasks, which operate outside of OpenMRS. Dave has been working on some tools that use rsync to keep all our Rwanda servers using the same modules, and do the actual module upgrade at scheduled times - this is a lot more useful for people managing lots of remote OpenMRS instances because they don't have to log into each instance separately. I also prototyped a JMX module that allows someone to list installed modules and stop/start them over JMX. Rowan On 18 January 2012 15:24, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected] > wrote: > I find this entire thread a little disconcerting because it's all > developers raising problems that developers have because they're constantly > changing their configuration and bringing modules up and down. Except for > automatic download of dependencies, there seems to be little in this thread > useful to sysadmins, let alone users.**** > > ** ** > > As for this particular suggestion, what's wrong with having my cool > utililties as a jar that's referenced in one or more modules? We could > keep them in contributions and the maven repo. Are your cool utilities > going to be designed generally enough and documented well enough for others > to use them? Are we dedicated enough to reuse that we would bother to find > the documentation and figure them out rather than write our own?**** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Michael Seaton > *Sent:* Friday, January 13, 2012 10:14 PM > > *To:* [email protected] > *Subject:* Re: [OPENMRS-IMPLEMENTERS] 1.10 MUST have**** > > ** ** > > 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 > **** > -- *Rowan Seymour* tel: +250 783835665 http://twitter.com/rowanseymour _________________________________________ 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]
