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