My immediate use case, and the one I'm going to spend time on this week, is
the "need to be able to distribute application-level functionality in just
one file". Hence the zip-of-omods approach. Also, I intentionally want to
include specifically-tested versions of dependencies, so this mechanism can
be used to manage tens or hundreds of installations, by moving them between
a small number of module configurations.
I was going to mention in my original email, but cut for brevity, that a
next piece of functionality would be to let the zip file contain a URL to
check for updates, and functionality to download updates in the background
and present them to the administrator for one-click install when they're
ready.
I think it would be good if OpenMRS could fetch missing dependencies for a
module you try to load. Perhaps if we tweaked the required-module tag in
config.xml to also indicate a URL, and default to looking in
modules.openmrs.org?
I also think it would be good to allow modules to include their
dependencies in a /dependencies folder.
But neither of these are relevant to me today, and I don't have any cycles
for them, but I'm happy to discuss with someone else who might implement
them. :-)
Regarding naming, I was thinking of actually just using "zip" but "omods"
is fine. (I originally though "opack", but Ben has said "ozip" enough times
that I switched to that.)
-Darius
On Tue, May 8, 2012 at 7:51 AM, Rowan Seymour <rowanseym...@gmail.com>wrote:
> Is there a reason we're not pursuing a way of managing module dependencies
> dynamically? Like a real package-manager?
>
> Building static bundles of modules is certainly convenient for people with
> bad internet, but a much better solution surely would be to have OpenMRS
> resolve and fetch dependencies at install time. The static bundles mean
> that you'll often not get the latest versions of the dependencies but
> whatever versions were available to the developer at compile time and
> people may already have those dependencies installed so you wasting
> bandwidth.
>
> Rowan
>
> On 8 May 2012 15:31, Ben Wolfe <b...@openmrs.org> wrote:
>
>> It definitely needs to work for any kind of module grouping, without
>> there needing to be a "root" module as you put it Darius.
>>
>> The ModuleUtil/ModuleFactory startup machinery should handle the
>> dependency loading and starting order for you. You just need to dump the
>> omod files into the directory and call the module startup methods. (I
>> think). If this is the case you don't have a need for a "root" module or
>> an xml file describing the load order.
>>
>> Ben
>>
>>
>> On Tue, May 8, 2012 at 9:08 AM, Bob Jolliffe <bobjolli...@gmail.com>wrote:
>>
>>> Agree with not using omod extension for this. Though ozip is kind of
>>> non-descriptive. as has been pointed out an omod is a zip file
>>> anyway. How about ".omods" ?
>>>
>>> In general I can see this idea being really very useful. I wonder is
>>> it an intention that the mechanism is strictly to do with packaging
>>> module+dependencies or can we view this more generally as a packaging
>>> of any ensemble of modules? For example it would be very useful to be
>>> able to package an ensemble of modules which are required for a
>>> particular facility setup. Having the dependencies resolved would be
>>> great but these might also be modules not directly dependent on each
>>> other.
>>>
>>> Watching with interest. Thanks for the initiative Darius.
>>>
>>> Bob
>>>
>>> On 8 May 2012 13:14, Ben Wolfe <b...@openmrs.org> wrote:
>>> > Jer: that second option should be easy. Right now it just says "you
>>> require
>>> > X module, do something about that" to the user. Instead, the module
>>> page
>>> > could easily catch that and provide a
>>> one-click-to-download-dependencies
>>> > button for all the required modules.
>>> >
>>> > Burke: I think calling them omods would be a mistake. The file
>>> structure
>>> > inside an omod vs ozip is very different. The ozip can have zips
>>> inside of
>>> > it, no problem there.
>>> >
>>> > As Mark put it, if a module contains more than a few dependencies the
>>> name
>>> > will get way too long. Having reporting.omod and
>>> > reporting-with-dependencies.ozip makes more sense to me.
>>> >
>>> > Ben
>>> >
>>> >
>>> > On Tue, May 8, 2012 at 8:05 AM, Mark Goodrich <mgoodr...@pih.org>
>>> wrote:
>>> >>
>>> >> 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: dev@openmrs.org [dev@openmrs.org] On Behalf Of Darius Jazayeri
>>> >> [djazayeri+...@gmail.com]
>>> >> Sent: Tuesday, May 08, 2012 2:22 AM
>>> >> To: openmrs-deve...@listserv.iupui.edu
>>> >> 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
>>> >> <robby.ocon...@gmail.com<mailto:robby.ocon...@gmail.com>> 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
>>> >> <djazay...@gmail.com<mailto:djazay...@gmail.com>> 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:lists...@listserv.iupui.edu
>>> ?body=SIGNOFF%20openmrs-devel-l>
>>> >> from OpenMRS Developers' mailing list
>>> >>
>>> >> ________________________________
>>> >> Click here to
>>> >> unsubscribe<mailto:lists...@listserv.iupui.edu
>>> ?body=SIGNOFF%20openmrs-devel-l>
>>> >> from OpenMRS Developers' mailing list
>>> >> ________________________________
>>> >> Click here to
>>> >> unsubscribe<mailto:lists...@listserv.iupui.edu
>>> ?body=SIGNOFF%20openmrs-devel-l>
>>> >> from OpenMRS Developers' mailing list
>>> >>
>>> >> ________________________________
>>> >> Click here to
>>> >> unsubscribe<mailto:lists...@listserv.iupui.edu
>>> ?body=SIGNOFF%20openmrs-devel-l>
>>> >> from OpenMRS Developers' mailing list
>>> >> _________________________________________
>>> >>
>>> >> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail
>>> to
>>> >> lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the
>>> body (not
>>> >> the subject) of your e-mail.
>>> >>
>>> >> [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
>>> >
>>> >
>>> > ________________________________
>>> > Click here to unsubscribe from OpenMRS Developers' mailing list
>>>
>>> _________________________________________
>>>
>>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>>> lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body
>>> (not the subject) of your e-mail.
>>>
>>> [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
>>>
>>
>> ------------------------------
>> Click here to
>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from
>> OpenMRS Developers' mailing list
>>
>
>
>
> --
> *Rowan Seymour*
> tel: +250 783835665
> http://twitter.com/rowanseymour
>
> ------------------------------
> Click here to
> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from
> OpenMRS Developers' mailing list
>
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
