sorry, can't read thru my 'fro and shades how about omg (openmrs module group) or omodz or zippo or snomod (selected nested omods, or sertain number of omods) or modzilla (zillions of modules) or mvn (oops, that's taken)
burke, i had managed to avoid this all day, why'd you have to call me out?? From: dev@openmrs.org [mailto:dev@openmrs.org] On Behalf Of Burke Mamlin Sent: Tuesday, May 08, 2012 12:23 PM To: openmrs-deve...@listserv.iupui.edu Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip" My favorite so far is osquad. squad = "A small number of soldiers assembled for drill or assigned to some special task." And then we have omod & osquad<http://en.wikipedia.org/wiki/The_Mod_Squad>. Maybe I'm just showing my age... at least Roger will back me on this one. :-) -Burke On Tue, May 8, 2012 at 11:44 AM, Ben Wolfe <b...@openmrs.org<mailto:b...@openmrs.org>> wrote: FYI, the ticket for this is here: https://tickets.openmrs.org/browse/TRUNK-1598 (created by Justin 2 years ago) Perhaps just a ".zip"? Or .ogrp .obundle .omodbundle .opkg ? "O" the possibilities On Tue, May 8, 2012 at 11:26 AM, Burke Mamlin <bmam...@regenstrief.org<mailto:bmam...@regenstrief.org>> wrote: On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <djazayeri+...@gmail.com<mailto: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). I was actually thinking of the reverse question -- what problem is the ozip extension is solving? Wouldn't we want the ability for modules to include their dependencies as standard practice by, for example, having a "dependencies" folder within the omod by convention? Is there an advantage to being able to ship the module without any dependencies -- e.g., does a module + dependencies get massively bigger so becomes a download issue? If the goal is, as Ben suggested, simply sending modules as a single package (not only handling dependencies, but also just a distribution of related modules that are useful together but may not depend on each other), then I'd agree that a different extension is warranted. Though, I agree with Bob that ozip doesn't say much and that something like omods would be more descriptive. Maybe osquad? ;-) -Burke -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 ________________________________ 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
