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]
<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
_________________________________________
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]
