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). > 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>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]
