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