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