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 <[email protected]> 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 <[email protected]>wrote: > >> On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri >> <[email protected]>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 >>> <[email protected]>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 <[email protected]>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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>>> OpenMRS Developers' mailing list >>>> >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
