These sound like really good ideas that simplify module management and +1 for module engine to manage dependent modules, i like the idea of multiple modules packaged together though i think this is more of a module packaging issue. I doubt if it would be so hard to support this in the modules engine.
As for the auto downloading and installing dependent modules when a module is getting started, this should be possible to support as long as you have a live internet connection. I would also like to see the manage modules page giving the user the option of choosing to drop a module's tables from the database when it is getting uninstalled or letting a module perform a self cleanup just before it is completely deleted, this would be good for implementers with limited sql knowledge and wish to get rid of redundant data, columns and tables. This would also benefit module developers, there are times during module development when you are testing module installation that involves running liquibase changsets, if you have to do it several times and you wish to have these changes to be 'auto reverted' before retrying, currently a developer has to do it manually or with a sql script before each attempt. I guess there is already a ticket for this. Wyclif 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] > _________________________________________ 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]
