+1 -- awesome idea! =)
--rob
On 5/7/2012 9:31 PM, Mark Goodrich wrote:
A big +1 for this.
We aren't publishing omods to the maven repo, but I would certainly vote for
doing this as well... when I was working on writing unit tests that test the
inter-operability of the sync module with other modules, my thought was to have
the sync omod published to the module repo, so another module could include it
and start it within it's own unit tests. I didn't have much luck figuring out
exactly how to do this, but I didn't get a chance to spend a heck of a lot of
time with it either. However, I think the ozip use case would be much
simpler... I figure shouldn't be hard to modify a maven deploy to deploy the
omod as well as the jars...
It would also be good to think of all of the possible error cases and how to
handle them: ie, if one of the dependencies requires a version of OpenMRS
higher (or lower) than the current version. I'm trying to think up other error
cases but nothing is coming to mind right now.
Mark
________________________________________
From: dev@openmrs.org [dev@openmrs.org] On Behalf Of Darius Jazayeri
[djazay...@gmail.com]
Sent: Monday, May 07, 2012 6:45 PM
To: openmrs-deve...@listserv.iupui.edu
Subject: [OPENMRS-DEV] Distributing multiple modules as an "ozip"
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<mailto: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]
_________________________________________
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]
