I'm fine with any of them. osquad, opckg, ozip, omods, etc. I don't see a reason to debate over the name of the extension much longer. (shed painting<http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality>anyone?) Darius gets to make the decision since he's writing the functionality. The good news is that all the other decisions were agreed upon and this trivial one isn't distracting us from those...its in addition to it. We're all just too creative and too perfectionistic. :-)
Ben On Tue, May 8, 2012 at 12:23 PM, Burke Mamlin <[email protected]>wrote: > 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 >> > > ------------------------------ > 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]
