How about assuming that a module ID without a period in it is org.openmrs.moduleid; otherwise, module IDs should be fully specified – e.g., com.burkeware.mymodule.
In other words, migrate toward module IDs being fully qualified. -Burke On Mon, May 14, 2012 at 11:06 AM, Ben Wolfe <[email protected]> wrote: > I like the idea of using the code@openmrs list for only org.openmrs > packaged modules. Perhaps that will remove the notion of it being a > possible bottleneck? > > Openmrs has no expectations of "org.openmrs.module" in the package. > However, it does expect to have unique module ids in a given install. > There are many places that make a call like > ModuleFactory.getModuleById("distribution"). > > If we truly wanted to allow a wild west of naming, we would simply have to > change all references and force the calls to be > ModuleFactory.getModuleByPackage("org.pih.distribution"). > > The module repo also has an expectation of unique module ids. So its urls > would need to be updated to use the full package as well. > > Ben > > > On Sun, May 13, 2012 at 5:23 PM, Darius Jazayeri <[email protected]>wrote: > >> I believe the maven archetype has a bug if you choose a different >> package, but our core code handles it fine. >> >> -Darius (by phone) >> On May 13, 2012 2:08 PM, "Burke Mamlin" <[email protected]> wrote: >> >>> Do we make any assumptions about the packaging of code within a module >>> (i.e., do we ever assume the package name instead of depending on >>> reference(s) to module package names or fully specified classes made in the >>> config.xml)? Hopefully not. >>> >>> -Burke >>> >>> On Sun, May 13, 2012 at 1:40 PM, Darius Jazayeri < >>> [email protected]> wrote: >>> >>>> Indeed, our tooling and documentation (either copying the basicmodule >>>> or using the maven archetype) pushes people to namespace their modules as >>>> org.openmrs.module.moduleid. >>>> >>>> It seems like the module package (and maven group ID) should be the >>>> solution to Burke's wanting a uuid in each new module. >>>> >>>> One possible convention could be that if you're using the >>>> "org.openmrs.module" namespace, you are suggested to email >>>> [email protected] and request the id, whereas if you're using any other >>>> namespace, you need to follow whatever policies the owner of that namespace >>>> sets out. >>>> >>>> For example: >>>> * org.openmrs.module.uiframework -> need to follow OpenMRS policy: ask >>>> [email protected] >>>> * org.pih.openmrs.uiframework -> need to follow PIH policy >>>> * com.djazayeri.uiframework -> do whatever I want >>>> >>>> The downside to this approach is that it makes it more of a task to >>>> take a module developed in another namespace, and turn it into an >>>> "OpenMRS-owned" module. >>>> >>>> That said, for the specific "uiframework" example, I'd have known from >>>> the beginning that I definitely want it to be a "core OpenMRS" module >>>> someday, so I'd have requested an org.openmrs.module space. >>>> >>>> Whereas the work I'm doing on "zip of omods", and the work Mark is >>>> doing on provider management could make sense to start off under org.pih. >>>> And there's no reason they couldn't live there long-term, really. >>>> >>>> Just brainstorming here, what do others think about this? >>>> >>>> -Darius >>>> >>>> >>>> On Sun, May 13, 2012 at 1:03 AM, Rowan Seymour >>>> <[email protected]>wrote: >>>> >>>>> Isn't the most useful function of a module id to serve as a unique >>>>> Java subpackage? >>>>> >>>>> On 12 May 2012 06:10, Burke Mamlin <[email protected]> wrote: >>>>> >>>>>> That's fine. >>>>>> >>>>>> Actually, I'd like to abandon our current [email protected] >>>>>> approach to module IDs by adding a UUID to the module config to >>>>>> ensure uniqueness... or by auto-assigning devs a UUID that can be used to >>>>>> namespace any modules they create. >>>>>> >>>>>> [email protected] has served us well in ensuring naming conventions >>>>>> are followed in our repository and helping highlight redundant efforts; >>>>>> however, it would be nice to get past the "getting approval" & "ensuring >>>>>> unique module IDs" aspects. With those gone, the remaining uses of >>>>>> [email protected] (applying conventions & recognizing/highlighting >>>>>> redundant efforts) could probably be done better & in a more public way >>>>>> as >>>>>> well. >>>>>> >>>>>> -Burke >>>>>> >>>>>> >>>>>> On Fri, May 11, 2012 at 6:56 PM, Darius Jazayeri <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Hi Code, (copying Dev) >>>>>>> >>>>>>> I have created the following modules, and deployed them to our maven >>>>>>> repo, and to the module repository: >>>>>>> >>>>>>> - uiframework (the UI framework formerly known as 2.x) >>>>>>> - uilibrary (standard widgets built on uiframework) >>>>>>> - appframework (the idea of "app" buttons on your homepage that >>>>>>> can be enabled per user and role) >>>>>>> >>>>>>> I didn't email [email protected] at the time because I put the code >>>>>>> in my github account, but it just occurred to me that since I've >>>>>>> deployed >>>>>>> these to maven and the module repo, I really *should* have >>>>>>> requested the module id. >>>>>>> >>>>>>> So, can I please get those retroactively blessed? :-) >>>>>>> >>>>>>> Our documentation about this is currently lacking. In a quick search >>>>>>> the only reference I found to emailing [email protected] is on this >>>>>>> page: https://wiki.openmrs.org/x/UwAJ and it's specifically talking >>>>>>> about access to the svn repo. >>>>>>> >>>>>>> Obviously I should be allowed to put my code at >>>>>>> github.com/djazayeri/openmrs-module-uiframework without asking >>>>>>> permission. But I *should* need to ask permission to take a module >>>>>>> id in the maven and module repos. Do we want to just rephrase our >>>>>>> documentation to say you need to ask [email protected] to claim a >>>>>>> module id in the OpenMRS repos? Or do want to consider something else? >>>>>>> >>>>>>> -Darius >>>>>>> >>>>>>> PS- working with git and github is wonderful. Like playing in cotton >>>>>>> candy clouds with sunshine and rainbows. The combination of >>>>>>> Eclipse+git+maven works a lot better than with svn, for not having to >>>>>>> worry >>>>>>> about annoying eclipse plugin and connector versions. The workflow * >>>>>>> is* more complicated, but I mostly haven't had to deal with that >>>>>>> yet. >>>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> Click here to >>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>>>> OpenMRS Developers' mailing list >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Rowan Seymour* >>>>> tel: +250 783835665 >>>>> http://twitter.com/rowanseymour >>>>> >>>>> >>>>> ------------------------------ >>>>> Click here to >>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>>> OpenMRS Developers' mailing list >>>>> >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
