Is there a way for a module to specify which versions of it's dependent modules it has been tested with, so that it not only says, it requires a module later than x.x, but it has been tested with x.x and x.x
Joaquín ___________________________________________________________________ Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/> Moderador, GHDOnline.org <http://www.ghdonline.org/> On Tue, May 8, 2012 at 12:59 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > sorry, can't read thru my 'fro and shades**** > > ** ** > > how about omg (openmrs module group)**** > > or omodz**** > > or zippo**** > > or snomod (selected nested omods, or sertain number of omods)**** > > or modzilla (zillions of modules)**** > > or mvn (oops, that's taken) **** > > ** ** > > burke, i had managed to avoid this all day, why'd you have to call me out?? > **** > > **** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke > Mamlin > *Sent:* Tuesday, May 08, 2012 12:23 PM > > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"*** > * > > ** ** > > 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]
