As a module developer, I love the idea of packaging other modules with mine as a bundle. However, it would be even more fantastic if (during loading the module), the user was prompted with: "This module requires [module name] version [version number]. Click here to download and install it from the OpenMRS Module Repository."
Jeremy Keiper OpenMRS Core Developer AMPATH / IU-Kenya Support On Tue, May 8, 2012 at 7:26 AM, Jeremy Keiper <jer...@openmrs.org> wrote: > I prefer a more specific name describing the trio, like > reporting-full-package.ozip ... and the extension identifies it as a > package and not directly uploadable as a single module itself. > > I think AMPATH would use this as a way to maintain a > this-is-what-we-use-in-production snapshot of modules, so it would be easy > to get test instances up to speed with modules through the UI. > > Jeremy Keiper > OpenMRS Core Developer > AMPATH / IU-Kenya Support > > > > On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri > <djazayeri+...@gmail.com>wrote: > >> 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>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>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<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> 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]
