I think it is valuable to have a new extension to distinguish an omod from an
ozip.
If we did end up with a single omod extension, I think we'd want to find some
other key word to distinguish a standalone module from a package of modules
("reporting-full.omod"?) because I'd argue against
"reporting+htmlwidgets+xstream.omod" When you have a module that is dependent
on 5+ modules (which I think will start to become a frequent occurrence, if not
the norm) the name would start to get rather unwieldy and confusing. Having an
ozip is a way to make things simpler for a non-technical administrator who just
wants, say, the mdrtb module, and doesn't know, or care, that it is dependent
on underlying support modules like reporting, htmlwidgets, etc.
A few other thoughts I have:
- The "main module" maven goal will have to support nested module dependencies
(the module requires a module that requires another module)
- Not a first-pass feature, but it would be helpful down the line to have
dependency logic based on the OpenMRS version you are installing on. For
instance, if you are installing a module that uses program location, it
requires the program location module, but only if you are using a version of
OpenMRS prior to program location being included in core. Or you are
installing a module that works on 1.5+, but depends on a module that has a
1.5-1.6 version and a 1.7+ version.
- Another approach would be instead of having a ozip to have a module be able
to contact the module repo itself and download it's dependencies; this would
probably be the ideal way to do things if we weren't generally working in
setting with poor connectivity
Mark
________________________________________
From: [email protected] [[email protected]] On Behalf Of Darius Jazayeri
[[email protected]]
Sent: Tuesday, May 08, 2012 2:22 AM
To: [email protected]
Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"
What's the benefit of reporting.omod and reporting+htmlwidgets+xstream.omod
having the same file extension exactly?
What problem is that solving that supporting a zip-full-of-omods wouldn't solve?
It's worth thinking about, but I can't imagine spending any time on it in the
early iterations (which must produce a module that will work on existing
OpenMRS versions).
-Darius
On Mon, May 7, 2012 at 9:00 PM, Robby O'Connor
<[email protected]<mailto:[email protected]>> wrote:
+1 on this proposal!
--rob
On 5/7/2012 10:12 PM, Burke Mamlin wrote:
Do we need an "ozip" extension? Â Rather, could we extend the omod spec to
allow for dependencies to be included? Â The omod is already a zip file, after
all.
For example:
reporting.omod
vs.
reporting+htmlwidgets+xstream.omod
-Burke
On Mon, May 7, 2012 at 6:45 PM, Darius Jazayeri
<[email protected]<mailto:[email protected]>> wrote:
Hi All,
Later this week I expect to do some work on a module that lets you distribute a
module with all of its required modules as a ZIP file, and is intelligently
able to update OpenMRS with all those modules in a single update step.
End-user requirements:
* needs to work with 1.9, so it has to be a module, not a core fix
* if you upload a zip file containing the omods for, for example, reporting,
htmlwidgets, and serialization.xstream:
* it installs/upgrades modules in the right order
* it would be fine to include a text/xml file in the zip describing
the order to load modules, but ideally it would determine this from the omods
themselves
* if the zip includes a module not on the system, it is installed
* if the zip includes a newer version of a module on the system, it is
upgraded
* if the zip includes the same or lower version of a module on the
system, that is left alone
* this happens with a single Spring restart, so there's no possibility of
ending up with only some of the modules installed
Also key, to support the developer:
* The "main module", i.e. the root of the dependency tree, should support a
maven goal that builds and packages the zip file including its own omod and
omods for modules it depends on.
Comments welcome. Though if you're going to add more requirements, I'm not so
interested. :-)
One particular question I have: are we publishing module omods to maven? I
assume not, so I assume I'm going to have to do something ugly to get the omods
of depended modules. The first thing that springs to mind is automatically
downloading them from the module repository. But I hope there's a better way.
Any ideas?
-Darius
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
