All, Another thing to talk about is the hbm file declaration. Currently we put the declaration in the config file. If we want to keep this approach, that means we need t o move the config file to the API layer too (this would means core need to know how to read the config file from the API jar file instead of the OMOD).
This also means we need to change the template for the API pom file to include resource filtering and string substitution. I'm not sure how our maven resource filtering and string substitution works. But last time I check, there's a reference to OMOD folder in the code (I could be wrong). That means we need to change this code as well :) *this thread probably longest thread in this list* :) On Fri, Nov 11, 2011 at 10:04 AM, Mark Goodrich <[email protected]> wrote: > Thanks Rowen… do the creator(s) of the script have time to take this on? > > > > We definitely should also update the script to put the hibernate mapping > layer into the api project… I was only skimming the thread on this issue, so > could someone who has a good sense of what needs to be done here enter a > ticket for that as well? > > > > Thanks, > > Mark > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Rowan Seymour > Sent: Friday, November 11, 2011 7:33 AM > > To: [email protected] > Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes > > > > https://tickets.openmrs.org/browse/TRUNK-2856 > > > > Wasn't sure what project to put in under - the original ticket to create the > scripts was under TRUNK so I put it there. I've listed the issues I found > when I did the htmlformentry conversion. Don't know if anyone else has had > the same issues. > > > > We also discussed previously moving the hibernate mapping layer into the api > project... so maybe that is something this script could do though I don't > think it's as simple as putting moduleApplicationContext.xml and all the > *.hbm.xml files in the api project because developers may be defining all > their controllers etc in moduleApplicationContext.xml > > On 11 November 2011 13:48, Mark Goodrich <[email protected]> wrote: > > Rowen, > > That would be great if you could enter a ticket re: fixes to mavenization > scripts. I was planning on opening a ticket regarding fixing the omod/api > layout, but I wasn't sure if that had been fixed already. Were there > certain steps you took to change the project layout after running the > scripts? I tried quickly a few weeks back, but I remember it wasn't as > simple as just changing the project names. > > Mark > > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Rowan Seymour > [[email protected]] > Sent: Friday, November 11, 2011 3:05 AM > > To: [email protected] > Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes > > Before Git fans start migrating all their modules... it'd be great to get > some more information onto > https://wiki.openmrs.org/display/docs/Migrating+to+Git so that we can all be > consistent. Also it'd would be good that people doing migrations have access > to a single authors.txt account mapping file which we can all add to, though > obviously this contains people's email addresses so we don't want to make > that too public. > > It also seems like mavenization would be sensible first step before > git-ization, so it would be great if someone could fix the mavenization > scripts so they work with the agreed omod/api project layout, and a few > other problems I've noticed. Shall I open a ticket for this? > > @Kishore can you add some info to > https://wiki.openmrs.org/display/docs/Migrating+to+Git about which scripts > you used for the conversion of htmlformentry? > > On 11 November 2011 00:16, Darius Jazayeri > <[email protected]<mailto:djazayeri%[email protected]>> wrote: > I was originally skeptical of Burke's "just give everyone access, and deal > with issues if they become a problem" viewpoint. But it's grown on me. > > I think it'd be fair and good if the default JIRA setup for projects that we > host on OpenMRS JIRA is that all OpenMRS committers can assess tickets. The > module owner gets an email about this anyway. And I think it's fine to let a > module owner opt-out of this if they're going to be more proactive, and want > more control. > > -Darius > > On Thu, Nov 10, 2011 at 12:41 PM, Michael Seaton > <[email protected]<mailto:[email protected]>> wrote: > Hi Michael, > > Thanks, I understand your position. What I'm saying is that I _did_ observe > a bug before and I _was_ able to fix it, but the owner of the module was out > of contact for a period of time and without asking Darius to add me as an > approver, I was unable to move that ticket forward. > > I'm not saying that there aren't points pro and con here. But I would like > to get the community's input on this, and if the consensus is to let the > community police itself and not add process restrictions unnecessarily, then > I would hope that we're open to changing the way things operate. > > Regards, > Mike > > > > > On 11/10/2011 03:25 PM, Michael Downey wrote: > Hi Mike, > > On Thursday, November 10, 2011 at 3:01 PM, Michael Seaton wrote: > > 1. I could check out the module code, reproduce the error, commit a fix back > to trunk of the module > 2. I could create a ticket to report this particular issue > 3. I could _not_ mark this ticket as "Ready For Work", "Claim Issue", or > "Assign Issue". That seems restricted. > 4. Because of 3, I could also not perform "Committed Code" on the issue > That sounds more likely -- I think a fundamental assumption is that the > critical path for issue management is that bugs are generally observed (and > reported) before they are fixed. It's good for communication and it's good > change management. > > For OpenMRS core, I personally would be concerned with allowing everyone to > do issue triage due to potential quality and release planning issues. Of > course, there is inherent delay in such a model as it scales - see > Mozilla's challenges with triage [0] for example. On the other hand, a > module developer or may choose otherwise (which is fine, of course) and can > add multiple individuals or indeed all JIRA users into the "Approver" role > which can triage issues. Fortunately, JIRA like GitHub has decentralized > administration which allows this flexibility and independence, which I agree > is important for a large distributed project like OpenMRS. > > Regarding the example at hand, I notice you are listed as in the Approver > role for this project - I assume that's a recent addition and you'd be able > to triage tickets for this project in the future. > > Michael > > [0] > http://tylerdowner.wordpress.com/2011/08/27/some-clarification-and-musings/ > ________________________________ > > Click here to > unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > ________________________________ > Click here to > unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > > ________________________________ > Click here to > unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > > > > ________________________________ > > Click here to > unsubscribe<mailto:[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] > > > > -- > Rowan Seymour > tel: +250 783835665 > http://twitter.com/rowanseymour > > ________________________________ > > Click here to unsubscribe from OpenMRS Developers' mailing list > > ________________________________ > Click here to unsubscribe from OpenMRS Developers' mailing list -- Thanks, Nyoman Ribeka _________________________________________ 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]
