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