Distributing multiple modules as an "ozip"

classic Classic list List threaded Threaded
23 messages Options
12
Darius Jazayeri-2 Darius Jazayeri-2
Reply | Threaded
Open this post in threaded view
|

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

[hidden email] from OpenMRS Developers' mailing list
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

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: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri [[hidden email]]
Sent: Monday, May 07, 2012 6:45 PM
To: [hidden email]
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:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Robby O'Connor Robby O'Connor
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

+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: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri [[hidden email]]
> Sent: Monday, May 07, 2012 6:45 PM
> To: [hidden email]
> 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:[hidden email]?body=SIGNOFF%20openmrs-devel-l>  from OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

In reply to this post by Darius Jazayeri-2
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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Robby O'Connor Robby O'Connor
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

+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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

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 <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Jeremy Keiper-3 Jeremy Keiper-3
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

I prefer a more specific name describing the trio, like reporting-full-package.ozip ... and the extension identifies it as a package and not directly uploadable as a single module itself.

I think AMPATH would use this as a way to maintain a this-is-what-we-use-in-production snapshot of modules, so it would be easy to get test instances up to speed with modules through the UI.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <[hidden email]> 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).

-Darius


On Mon, May 7, 2012 at 9:00 PM, Robby O'Connor <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Jeremy Keiper-3 Jeremy Keiper-3
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

As a module developer, I love the idea of packaging other modules with mine as a bundle.  However, it would be even more fantastic if (during loading the module), the user was prompted with: "This module requires [module name] version [version number].  Click here to download and install it from the OpenMRS Module Repository."

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


On Tue, May 8, 2012 at 7:26 AM, Jeremy Keiper <[hidden email]> wrote:
I prefer a more specific name describing the trio, like reporting-full-package.ozip ... and the extension identifies it as a package and not directly uploadable as a single module itself.

I think AMPATH would use this as a way to maintain a this-is-what-we-use-in-production snapshot of modules, so it would be easy to get test instances up to speed with modules through the UI.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support



On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <[hidden email]> 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).

-Darius


On Mon, May 7, 2012 at 9:00 PM, Robby O'Connor <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

In reply to this post by Darius Jazayeri-3
I think it is valuable to have a new extension to distinguish an omod from an ozip.

If we did end up with a single omod extension, I think we'd want to find some other key word to distinguish a standalone module from a package of modules ("reporting-full.omod"?) because I'd argue against "reporting+htmlwidgets+xstream.omod"  When you have a module that is dependent on 5+ modules (which I think will start to become a frequent occurrence, if not the norm) the name would start to get rather unwieldy and confusing.  Having an ozip is a way to make things simpler for a non-technical administrator who just wants, say, the mdrtb module, and doesn't know, or care, that it is dependent on underlying support modules like reporting, htmlwidgets, etc.

A few other thoughts I have:

- The "main module" maven goal will have to support nested module dependencies (the module requires a module that requires another module)
- Not a first-pass feature, but it would be helpful down the line to have dependency logic based on the OpenMRS version you are installing on.  For instance, if you are installing a module that uses program location, it requires the program location module, but only if you are using a version of OpenMRS prior to program location being included in core.  Or you are installing a module that works on 1.5+, but depends on a module that has a 1.5-1.6 version and a 1.7+ version.
- Another approach would be instead of having a ozip to have a module be able to contact the module repo itself and download it's dependencies; this would probably be the ideal way to do things if we weren't generally working in setting with poor connectivity

Mark


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri [[hidden email]]
Sent: Tuesday, May 08, 2012 2:22 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"

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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
augustine12th thomas augustine12th thomas
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

In reply to this post by Jeremy Keiper-3


Jeremy, the idea of specifying  the module name and version number will be great. It will solve most compatibility issues during module upload.

Thanks.

Miencha Agustine
Informatics
Ampth.


From: Jeremy Keiper <[hidden email]>
To: [hidden email]
Sent: Tuesday, May 8, 2012 2:28 PM
Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"

As a module developer, I love the idea of packaging other modules with mine as a bundle.  However, it would be even more fantastic if (during loading the module), the user was prompted with: "This module requires [module name] version [version number].  Click here to download and install it from the OpenMRS Module Repository."

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


On Tue, May 8, 2012 at 7:26 AM, Jeremy Keiper <[hidden email]> wrote:
I prefer a more specific name describing the trio, like reporting-full-package.ozip ... and the extension identifies it as a package and not directly uploadable as a single module itself.

I think AMPATH would use this as a way to maintain a this-is-what-we-use-in-production snapshot of modules, so it would be easy to get test instances up to speed with modules through the UI.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support



On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <[hidden email]> 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).

-Darius


On Mon, May 7, 2012 at 9:00 PM, Robby O'Connor <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

In reply to this post by Mark Goodrich-2
Jer: that second option should be easy.  Right now it just says "you require X module, do something about that" to the user.  Instead, the module page could easily catch that and provide a one-click-to-download-dependencies button for all the required modules.

Burke: I think calling them omods would be a mistake.  The file structure inside an omod vs ozip is very different. The ozip can have zips inside of it, no problem there.

As Mark put it, if a module contains more than a few dependencies the name will get way too long. Having reporting.omod and reporting-with-dependencies.ozip makes more sense to me.

Ben

On Tue, May 8, 2012 at 8:05 AM, Mark Goodrich <[hidden email]> wrote:
I think it is valuable to have a new extension to distinguish an omod from an ozip.

If we did end up with a single omod extension, I think we'd want to find some other key word to distinguish a standalone module from a package of modules ("reporting-full.omod"?) because I'd argue against "reporting+htmlwidgets+xstream.omod"  When you have a module that is dependent on 5+ modules (which I think will start to become a frequent occurrence, if not the norm) the name would start to get rather unwieldy and confusing.  Having an ozip is a way to make things simpler for a non-technical administrator who just wants, say, the mdrtb module, and doesn't know, or care, that it is dependent on underlying support modules like reporting, htmlwidgets, etc.

A few other thoughts I have:

- The "main module" maven goal will have to support nested module dependencies (the module requires a module that requires another module)
- Not a first-pass feature, but it would be helpful down the line to have dependency logic based on the OpenMRS version you are installing on.  For instance, if you are installing a module that uses program location, it requires the program location module, but only if you are using a version of OpenMRS prior to program location being included in core.  Or you are installing a module that works on 1.5+, but depends on a module that has a 1.5-1.6 version and a 1.7+ version.
- Another approach would be instead of having a ozip to have a module be able to contact the module repo itself and download it's dependencies; this would probably be the ideal way to do things if we weren't generally working in setting with poor connectivity

Mark


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri [[hidden email]]
Sent: Tuesday, May 08, 2012 2:22 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"

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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list
Bob Jolliffe Bob Jolliffe
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

Agree with not using omod extension for this.  Though ozip is kind of
non-descriptive.  as has been pointed out an omod is a zip file
anyway.  How about ".omods" ?

In general I can see this idea being really very useful.  I wonder is
it an intention that the mechanism is strictly to do with packaging
module+dependencies or can we view this more generally as a packaging
of any ensemble of modules?  For example it would be very useful to be
able to package an ensemble of modules which are required for a
particular facility setup.  Having the dependencies resolved would be
great but these might also be modules not directly dependent on each
other.

Watching with interest.  Thanks for the initiative Darius.

Bob

On 8 May 2012 13:14, Ben Wolfe <[hidden email]> wrote:

> Jer: that second option should be easy.  Right now it just says "you require
> X module, do something about that" to the user.  Instead, the module page
> could easily catch that and provide a one-click-to-download-dependencies
> button for all the required modules.
>
> Burke: I think calling them omods would be a mistake.  The file structure
> inside an omod vs ozip is very different. The ozip can have zips inside of
> it, no problem there.
>
> As Mark put it, if a module contains more than a few dependencies the name
> will get way too long. Having reporting.omod and
> reporting-with-dependencies.ozip makes more sense to me.
>
> Ben
>
>
> On Tue, May 8, 2012 at 8:05 AM, Mark Goodrich <[hidden email]> wrote:
>>
>> I think it is valuable to have a new extension to distinguish an omod from
>> an ozip.
>>
>> If we did end up with a single omod extension, I think we'd want to find
>> some other key word to distinguish a standalone module from a package of
>> modules ("reporting-full.omod"?) because I'd argue against
>> "reporting+htmlwidgets+xstream.omod"  When you have a module that is
>> dependent on 5+ modules (which I think will start to become a frequent
>> occurrence, if not the norm) the name would start to get rather unwieldy and
>> confusing.  Having an ozip is a way to make things simpler for a
>> non-technical administrator who just wants, say, the mdrtb module, and
>> doesn't know, or care, that it is dependent on underlying support modules
>> like reporting, htmlwidgets, etc.
>>
>> A few other thoughts I have:
>>
>> - The "main module" maven goal will have to support nested module
>> dependencies (the module requires a module that requires another module)
>> - Not a first-pass feature, but it would be helpful down the line to have
>> dependency logic based on the OpenMRS version you are installing on.  For
>> instance, if you are installing a module that uses program location, it
>> requires the program location module, but only if you are using a version of
>> OpenMRS prior to program location being included in core.  Or you are
>> installing a module that works on 1.5+, but depends on a module that has a
>> 1.5-1.6 version and a 1.7+ version.
>> - Another approach would be instead of having a ozip to have a module be
>> able to contact the module repo itself and download it's dependencies; this
>> would probably be the ideal way to do things if we weren't generally working
>> in setting with poor connectivity
>>
>> Mark
>>
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
>> [[hidden email]]
>> Sent: Tuesday, May 08, 2012 2:22 AM
>> To: [hidden email]
>> Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"
>>
>> 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
>> <[hidden email]<mailto:[hidden email]>> 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
>> <[hidden email]<mailto:[hidden email]>> 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<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
> ________________________________
> Click here to unsubscribe from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

It definitely needs to work for any kind of module grouping, without there needing to be a "root" module as you put it Darius.

The ModuleUtil/ModuleFactory startup machinery should handle the dependency loading and starting order for you.  You just need to dump the omod files into the directory and call the module startup methods. (I think).  If this is the case you don't have a need for a "root" module or an xml file describing the load order.

Ben

On Tue, May 8, 2012 at 9:08 AM, Bob Jolliffe <[hidden email]> wrote:
Agree with not using omod extension for this.  Though ozip is kind of
non-descriptive.  as has been pointed out an omod is a zip file
anyway.  How about ".omods" ?

In general I can see this idea being really very useful.  I wonder is
it an intention that the mechanism is strictly to do with packaging
module+dependencies or can we view this more generally as a packaging
of any ensemble of modules?  For example it would be very useful to be
able to package an ensemble of modules which are required for a
particular facility setup.  Having the dependencies resolved would be
great but these might also be modules not directly dependent on each
other.

Watching with interest.  Thanks for the initiative Darius.

Bob

On 8 May 2012 13:14, Ben Wolfe <[hidden email]> wrote:
> Jer: that second option should be easy.  Right now it just says "you require
> X module, do something about that" to the user.  Instead, the module page
> could easily catch that and provide a one-click-to-download-dependencies
> button for all the required modules.
>
> Burke: I think calling them omods would be a mistake.  The file structure
> inside an omod vs ozip is very different. The ozip can have zips inside of
> it, no problem there.
>
> As Mark put it, if a module contains more than a few dependencies the name
> will get way too long. Having reporting.omod and
> reporting-with-dependencies.ozip makes more sense to me.
>
> Ben
>
>
> On Tue, May 8, 2012 at 8:05 AM, Mark Goodrich <[hidden email]> wrote:
>>
>> I think it is valuable to have a new extension to distinguish an omod from
>> an ozip.
>>
>> If we did end up with a single omod extension, I think we'd want to find
>> some other key word to distinguish a standalone module from a package of
>> modules ("reporting-full.omod"?) because I'd argue against
>> "reporting+htmlwidgets+xstream.omod"  When you have a module that is
>> dependent on 5+ modules (which I think will start to become a frequent
>> occurrence, if not the norm) the name would start to get rather unwieldy and
>> confusing.  Having an ozip is a way to make things simpler for a
>> non-technical administrator who just wants, say, the mdrtb module, and
>> doesn't know, or care, that it is dependent on underlying support modules
>> like reporting, htmlwidgets, etc.
>>
>> A few other thoughts I have:
>>
>> - The "main module" maven goal will have to support nested module
>> dependencies (the module requires a module that requires another module)
>> - Not a first-pass feature, but it would be helpful down the line to have
>> dependency logic based on the OpenMRS version you are installing on.  For
>> instance, if you are installing a module that uses program location, it
>> requires the program location module, but only if you are using a version of
>> OpenMRS prior to program location being included in core.  Or you are
>> installing a module that works on 1.5+, but depends on a module that has a
>> 1.5-1.6 version and a 1.7+ version.
>> - Another approach would be instead of having a ozip to have a module be
>> able to contact the module repo itself and download it's dependencies; this
>> would probably be the ideal way to do things if we weren't generally working
>> in setting with poor connectivity
>>
>> Mark
>>
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
>> [[hidden email]]
>> Sent: Tuesday, May 08, 2012 2:22 AM
>> To: [hidden email]
>> Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"
>>
>> 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
>> <[hidden email]<mailto:[hidden email]>> 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
>> <[hidden email]<mailto:[hidden email]>> 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<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
> ________________________________
> Click here to unsubscribe from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list
Rowan Seymour-2 Rowan Seymour-2
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

Is there a reason we're not pursuing a way of managing module dependencies dynamically? Like a real package-manager?

Building static bundles of modules is certainly convenient for people with bad internet, but a much better solution surely would be to have OpenMRS resolve and fetch dependencies at install time. The static bundles mean that you'll often not get the latest versions of the dependencies but whatever versions were available to the developer at compile time and people may already have those dependencies installed so you wasting bandwidth.

Rowan

On 8 May 2012 15:31, Ben Wolfe <[hidden email]> wrote:
It definitely needs to work for any kind of module grouping, without there needing to be a "root" module as you put it Darius.

The ModuleUtil/ModuleFactory startup machinery should handle the dependency loading and starting order for you.  You just need to dump the omod files into the directory and call the module startup methods. (I think).  If this is the case you don't have a need for a "root" module or an xml file describing the load order.

Ben


On Tue, May 8, 2012 at 9:08 AM, Bob Jolliffe <[hidden email]> wrote:
Agree with not using omod extension for this.  Though ozip is kind of
non-descriptive.  as has been pointed out an omod is a zip file
anyway.  How about ".omods" ?

In general I can see this idea being really very useful.  I wonder is
it an intention that the mechanism is strictly to do with packaging
module+dependencies or can we view this more generally as a packaging
of any ensemble of modules?  For example it would be very useful to be
able to package an ensemble of modules which are required for a
particular facility setup.  Having the dependencies resolved would be
great but these might also be modules not directly dependent on each
other.

Watching with interest.  Thanks for the initiative Darius.

Bob

On 8 May 2012 13:14, Ben Wolfe <[hidden email]> wrote:
> Jer: that second option should be easy.  Right now it just says "you require
> X module, do something about that" to the user.  Instead, the module page
> could easily catch that and provide a one-click-to-download-dependencies
> button for all the required modules.
>
> Burke: I think calling them omods would be a mistake.  The file structure
> inside an omod vs ozip is very different. The ozip can have zips inside of
> it, no problem there.
>
> As Mark put it, if a module contains more than a few dependencies the name
> will get way too long. Having reporting.omod and
> reporting-with-dependencies.ozip makes more sense to me.
>
> Ben
>
>
> On Tue, May 8, 2012 at 8:05 AM, Mark Goodrich <[hidden email]> wrote:
>>
>> I think it is valuable to have a new extension to distinguish an omod from
>> an ozip.
>>
>> If we did end up with a single omod extension, I think we'd want to find
>> some other key word to distinguish a standalone module from a package of
>> modules ("reporting-full.omod"?) because I'd argue against
>> "reporting+htmlwidgets+xstream.omod"  When you have a module that is
>> dependent on 5+ modules (which I think will start to become a frequent
>> occurrence, if not the norm) the name would start to get rather unwieldy and
>> confusing.  Having an ozip is a way to make things simpler for a
>> non-technical administrator who just wants, say, the mdrtb module, and
>> doesn't know, or care, that it is dependent on underlying support modules
>> like reporting, htmlwidgets, etc.
>>
>> A few other thoughts I have:
>>
>> - The "main module" maven goal will have to support nested module
>> dependencies (the module requires a module that requires another module)
>> - Not a first-pass feature, but it would be helpful down the line to have
>> dependency logic based on the OpenMRS version you are installing on.  For
>> instance, if you are installing a module that uses program location, it
>> requires the program location module, but only if you are using a version of
>> OpenMRS prior to program location being included in core.  Or you are
>> installing a module that works on 1.5+, but depends on a module that has a
>> 1.5-1.6 version and a 1.7+ version.
>> - Another approach would be instead of having a ozip to have a module be
>> able to contact the module repo itself and download it's dependencies; this
>> would probably be the ideal way to do things if we weren't generally working
>> in setting with poor connectivity
>>
>> Mark
>>
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
>> [[hidden email]]
>> Sent: Tuesday, May 08, 2012 2:22 AM
>> To: [hidden email]
>> Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"
>>
>> 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
>> <[hidden email]<mailto:[hidden email]>> 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
>> <[hidden email]<mailto:[hidden email]>> 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<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
> ________________________________
> Click here to unsubscribe from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list



--
Rowan Seymour
tel: +250 783835665
http://twitter.com/rowanseymour


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

In reply to this post by Darius Jazayeri-3
On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

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 <[hidden email]> wrote:
On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

In reply to this post by Rowan Seymour-2
My immediate use case, and the one I'm going to spend time on this week, is the "need to be able to distribute application-level functionality in just one file". Hence the zip-of-omods approach. Also, I intentionally want to include specifically-tested versions of dependencies, so this mechanism can be used to manage tens or hundreds of installations, by moving them between a small number of module configurations.

I was going to mention in my original email, but cut for brevity, that a next piece of functionality would be to let the zip file contain a URL to check for updates, and functionality to download updates in the background and present them to the administrator for one-click install when they're ready.

I think it would be good if OpenMRS could fetch missing dependencies for a module you try to load. Perhaps if we tweaked the required-module tag in config.xml to also indicate a URL, and default to looking in modules.openmrs.org?

I also think it would be good to allow modules to include their dependencies in a /dependencies folder.

But neither of these are relevant to me today, and I don't have any cycles for them, but I'm happy to discuss with someone else who might implement them. :-)

Regarding naming, I was thinking of actually just using "zip" but "omods" is fine. (I originally though "opack", but Ben has said "ozip" enough times that I switched to that.)

-Darius

On Tue, May 8, 2012 at 7:51 AM, Rowan Seymour <[hidden email]> wrote:
Is there a reason we're not pursuing a way of managing module dependencies dynamically? Like a real package-manager?

Building static bundles of modules is certainly convenient for people with bad internet, but a much better solution surely would be to have OpenMRS resolve and fetch dependencies at install time. The static bundles mean that you'll often not get the latest versions of the dependencies but whatever versions were available to the developer at compile time and people may already have those dependencies installed so you wasting bandwidth.

Rowan

On 8 May 2012 15:31, Ben Wolfe <[hidden email]> wrote:
It definitely needs to work for any kind of module grouping, without there needing to be a "root" module as you put it Darius.

The ModuleUtil/ModuleFactory startup machinery should handle the dependency loading and starting order for you.  You just need to dump the omod files into the directory and call the module startup methods. (I think).  If this is the case you don't have a need for a "root" module or an xml file describing the load order.

Ben


On Tue, May 8, 2012 at 9:08 AM, Bob Jolliffe <[hidden email]> wrote:
Agree with not using omod extension for this.  Though ozip is kind of
non-descriptive.  as has been pointed out an omod is a zip file
anyway.  How about ".omods" ?

In general I can see this idea being really very useful.  I wonder is
it an intention that the mechanism is strictly to do with packaging
module+dependencies or can we view this more generally as a packaging
of any ensemble of modules?  For example it would be very useful to be
able to package an ensemble of modules which are required for a
particular facility setup.  Having the dependencies resolved would be
great but these might also be modules not directly dependent on each
other.

Watching with interest.  Thanks for the initiative Darius.

Bob

On 8 May 2012 13:14, Ben Wolfe <[hidden email]> wrote:
> Jer: that second option should be easy.  Right now it just says "you require
> X module, do something about that" to the user.  Instead, the module page
> could easily catch that and provide a one-click-to-download-dependencies
> button for all the required modules.
>
> Burke: I think calling them omods would be a mistake.  The file structure
> inside an omod vs ozip is very different. The ozip can have zips inside of
> it, no problem there.
>
> As Mark put it, if a module contains more than a few dependencies the name
> will get way too long. Having reporting.omod and
> reporting-with-dependencies.ozip makes more sense to me.
>
> Ben
>
>
> On Tue, May 8, 2012 at 8:05 AM, Mark Goodrich <[hidden email]> wrote:
>>
>> I think it is valuable to have a new extension to distinguish an omod from
>> an ozip.
>>
>> If we did end up with a single omod extension, I think we'd want to find
>> some other key word to distinguish a standalone module from a package of
>> modules ("reporting-full.omod"?) because I'd argue against
>> "reporting+htmlwidgets+xstream.omod"  When you have a module that is
>> dependent on 5+ modules (which I think will start to become a frequent
>> occurrence, if not the norm) the name would start to get rather unwieldy and
>> confusing.  Having an ozip is a way to make things simpler for a
>> non-technical administrator who just wants, say, the mdrtb module, and
>> doesn't know, or care, that it is dependent on underlying support modules
>> like reporting, htmlwidgets, etc.
>>
>> A few other thoughts I have:
>>
>> - The "main module" maven goal will have to support nested module
>> dependencies (the module requires a module that requires another module)
>> - Not a first-pass feature, but it would be helpful down the line to have
>> dependency logic based on the OpenMRS version you are installing on.  For
>> instance, if you are installing a module that uses program location, it
>> requires the program location module, but only if you are using a version of
>> OpenMRS prior to program location being included in core.  Or you are
>> installing a module that works on 1.5+, but depends on a module that has a
>> 1.5-1.6 version and a 1.7+ version.
>> - Another approach would be instead of having a ozip to have a module be
>> able to contact the module repo itself and download it's dependencies; this
>> would probably be the ideal way to do things if we weren't generally working
>> in setting with poor connectivity
>>
>> Mark
>>
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
>> [[hidden email]]
>> Sent: Tuesday, May 08, 2012 2:22 AM
>> To: [hidden email]
>> Subject: Re: [OPENMRS-DEV] Distributing multiple modules as an "ozip"
>>
>> 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
>> <[hidden email]<mailto:[hidden email]>> 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
>> <[hidden email]<mailto:[hidden email]>> 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<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to
>> unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
> ________________________________
> Click here to unsubscribe from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list



--
Rowan Seymour
tel: <a href="tel:%2B250%20783835665" value="+250783835665" target="_blank">+250 783835665
http://twitter.com/rowanseymour


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

In reply to this post by Ben Wolfe (openmrs)
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.  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 <[hidden email]> 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 <[hidden email]> wrote:
On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

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: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Tuesday, May 08, 2012 12:23 PM
To: [hidden email]
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.  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 <[hidden email]> 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 <[hidden email]> wrote:

On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Distributing multiple modules as an "ozip"

In reply to this post by Burke Mamlin
I'm fine with any of them. osquad, opckg, ozip, omods, etc.  I don't see a reason to debate over the name of the extension much longer. (shed painting anyone?)  Darius gets to make the decision since he's writing the functionality.  The good news is that all the other decisions were agreed upon and this trivial one isn't distracting us from those...its in addition to it.  We're all just too creative and too perfectionistic. :-)

Ben

On Tue, May 8, 2012 at 12:23 PM, Burke Mamlin <[hidden email]> wrote:
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.  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 <[hidden email]> 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 <[hidden email]> wrote:
On Tue, May 8, 2012 at 2:22 AM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
12