| 00:00:40 | *** Anuruddha__ has quit IRC |
| 00:01:22 | *** Anuruddha__ has joined #openmrs |
| 00:02:31 | *** Anuruddha has quit IRC |
| 00:04:44 | *** Anuruddha has joined #openmrs |
| 00:04:49 | *** Anuruddha_ has quit IRC |
| 00:05:54 | *** Anuruddha_ has joined #openmrs |
| 00:07:07 | *** Anuruddha__ has quit IRC |
| 00:08:21 | *** Anuruddha__ has joined #openmrs |
| 00:09:18 | *** Anuruddha has quit IRC |
| 00:11:48 | *** Anuruddha_ has quit IRC |
| 00:11:51 | *** Anuruddha has joined #openmrs |
| 00:13:07 | *** Anuruddha_ has joined #openmrs |
| 00:13:30 | *** Anuruddha__ has quit IRC |
| 00:15:24 | *** Anuruddha__ has joined #openmrs |
| 00:16:52 | *** Anuruddha has quit IRC |
| 00:18:27 | *** Anuruddha has joined #openmrs |
| 00:18:48 | *** Anuruddha_ has quit IRC |
| 00:19:53 | *** Anuruddha_ has joined #openmrs |
| 00:21:42 | *** Anuruddha__ has quit IRC |
| 00:23:43 | *** Anuruddha has quit IRC |
| 00:50:22 | *** Anuruddha__ has joined #openmrs |
| 00:50:25 | *** diadara has quit IRC |
| 00:53:35 | *** Anuruddha has joined #openmrs |
| 00:54:00 | *** Anuruddha_ has quit IRC |
| 00:55:08 | *** Anuruddha_ has joined #openmrs |
| 00:56:12 | *** Anuruddha__ has quit IRC |
| 00:58:17 | *** Anuruddha has quit IRC |
| 01:36:01 | *** Anuruddha__ has joined #openmrs |
| 01:39:15 | *** Anuruddha_ has quit IRC |
| 01:40:04 | *** wluyima has joined #openmrs |
| 01:40:16 | *** wyclif_ has quit IRC |
| 01:51:00 | *** wyclif_ has joined #openmrs |
| 01:51:33 | *** wluyima has quit IRC |
| 01:52:00 | *** wyclif_ has joined #openmrs |
| 02:47:34 | *** h3llborn has quit IRC |
| 02:52:31 | *** h3llborn has joined #openmrs |
| 02:59:31 | *** wluyima has joined #openmrs |
| 02:59:31 | *** wyclif_ has quit IRC |
| 03:11:27 | *** Anuruddha__ has quit IRC |
| 03:14:33 | *** wluyima has quit IRC |
| 03:15:14 | *** wyclif_ has joined #openmrs |
| 03:32:35 | *** Anuruddha has joined #openmrs |
| 04:04:41 | *** robbyoconnor has joined #openmrs |
| 04:04:41 | *** ChanServ sets mode: +v robbyoconnor |
| 04:08:42 | *** robbyoconnor has quit IRC |
| 04:11:39 | *** robbyoconnor has joined #openmrs |
| 04:11:39 | *** ChanServ sets mode: +v robbyoconnor |
| 04:11:44 | *** h3llborn has quit IRC |
| 04:17:10 | *** ruwanego has joined #openmrs |
| 04:28:35 | *** kavuri has joined #openmrs |
| 04:36:59 | *** ruwanego has quit IRC |
| 04:39:34 | *** ruwanego has joined #openmrs |
| 05:24:56 | *** ruwanego has quit IRC |
| 05:25:15 | *** ruwanego has joined #openmrs |
| 05:36:57 | *** ruwanego has quit IRC |
| 05:37:18 | *** ruwanego has joined #openmrs |
| 05:40:57 | *** ruwanego has quit IRC |
| 05:41:20 | *** ruwanego has joined #openmrs |
| 05:44:58 | *** ruwanego has quit IRC |
| 05:45:27 | *** ruwanego has joined #openmrs |
| 05:46:11 | *** Anuruddha has quit IRC |
| 06:03:04 | *** kishoreyekkanti has joined #openmrs |
| 06:29:58 | *** ruwanego has quit IRC |
| 06:30:28 | *** ruwanego has joined #openmrs |
| 06:37:57 | *** ruwanego has quit IRC |
| 06:38:29 | *** ruwanego has joined #openmrs |
| 06:56:52 | *** Anuruddha has joined #openmrs |
| 06:57:04 | *** kishoreyekkanti_ has joined #openmrs |
| 06:57:29 | *** kishoreyekkanti has quit IRC |
| 06:57:29 | *** kishoreyekkanti_ is now known as kishoreyekkanti |
| 07:25:37 | *** joeseff has joined #openmrs |
| 07:42:04 | *** ibewes has joined #openmrs |
| 07:47:17 | *** akwatuha has joined #openmrs |
| 07:57:56 | *** ruwanego has quit IRC |
| 07:58:16 | *** ruwanego has joined #openmrs |
| 08:02:44 | *** ruwanego has quit IRC |
| 08:03:05 | *** ruwanego has joined #openmrs |
| 08:04:11 | <akwatuha> Hi |
| 08:04:29 | <akwatuha> I would like to get more information on handling complex obs handler. |
| 08:10:48 | *** shortend has joined #openmrs |
| 08:46:07 | *** dkayiwa has joined #openmrs |
| 08:51:17 | *** joeseff has quit IRC |
| 09:03:01 | *** joeseff has joined #openmrs |
| 09:31:21 | *** ibewes has quit IRC |
| 09:48:29 | *** ibewes has joined #openmrs |
| 09:55:24 | *** harshadura has joined #openmrs |
| 10:02:12 | *** Anuruddha has quit IRC |
| 10:02:29 | *** Anuruddha has joined #openmrs |
| 10:14:38 | *** shortend has quit IRC |
| 10:15:09 | *** shortend has joined #openmrs |
| 10:48:15 | *** varad has joined #openmrs |
| 10:50:28 | <varad> Hi everyone! I'm a student from India and am interested in participating in GSoC-2013 with OpenMRS as my mentoring organization. |
| 10:51:20 | <dkayiwa> varad: welcome!!! |
| 10:51:43 | <varad> I'd like to know how I should start off |
| 10:52:29 | <dkayiwa> varad: https://wiki.openmrs.org/display/docs/Getting+Started+as+a+Developer |
| 10:52:30 | <OpenMRSBot> <http://ln-s.net/8bkO> (at wiki.openmrs.org) |
| 10:53:45 | *** harshadura has quit IRC |
| 11:01:02 | *** varad has quit IRC |
| 11:43:59 | *** shortend has quit IRC |
| 11:44:00 | *** ibewes has quit IRC |
| 12:00:11 | *** joeseff has quit IRC |
| 12:02:27 | *** GitHub128 has joined #openmrs |
| 12:02:27 | <GitHub128> [openmrs-core] dkayiwa pushed 1 new commit to master: http://git.io/55kk2w |
| 12:02:27 | <GitHub128> openmrs-core/master cdd0d58 dkayiwa: ORUR01Handler should load patient and concept from the datatabase -... |
| 12:02:27 | *** GitHub128 has left #openmrs |
| 12:09:57 | *** travis-ci has joined #openmrs |
| 12:09:57 | <travis-ci> [travis-ci] [openmrs/openmrs-core] [cdd0d58] [dkayiwa] The build was broken. - http://travis-ci.org/openmrs/openmrs-core/builds/5685153 |
| 12:09:57 | *** travis-ci has left #openmrs |
| 12:10:01 | <OpenMRSBot> <http://ln-s.net/+rqy> (at travis-ci.org) |
| 12:10:45 | <akwatuha> Thanks Daniel, let me take a look at it. |
| 12:15:26 | <dkayiwa> akwatuha: are you verad? :) |
| 12:18:55 | *** GitHub0 has joined #openmrs |
| 12:18:55 | <GitHub0> [openmrs-core] dkayiwa pushed 1 new commit to master: http://git.io/IWKqRw |
| 12:18:55 | <GitHub0> openmrs-core/master a9586d5 dkayiwa: Fixing failing unit test for: ORUR01Handler should load patient and... |
| 12:18:55 | *** GitHub0 has left #openmrs |
| 12:21:49 | *** GitHub18 has joined #openmrs |
| 12:21:49 | <GitHub18> [openmrs-core] dkayiwa pushed 2 new commits to 1.9.x: http://git.io/fykhUQ |
| 12:21:49 | <GitHub18> openmrs-core/1.9.x 0fe4760 dkayiwa: ORUR01Handler should load patient and concept from the datatabase -... |
| 12:21:49 | <GitHub18> openmrs-core/1.9.x 4991eac dkayiwa: Fixing failing unit test for: ORUR01Handler should load patient and... |
| 12:21:49 | *** GitHub18 has left #openmrs |
| 12:22:07 | <akwatuha> dkayiwa, I am not verad. I am Alfayo Kwatuha, a developer based at Ampath, Eldoret. I had requested information concerning building a complex obs handler. I thought your response was meant to point me to looking at ORUR01Handler as i continue working on the complex obs. |
| 12:22:37 | <dkayiwa> akwatuha: hahahaha. that was not even my response. it is automated from travis :) |
| 12:25:33 | <akwatuha> okay, interesting. I hope the response was to address part of my question. Let me take a look at it. |
| 12:28:09 | *** GitHub11 has joined #openmrs |
| 12:28:09 | <GitHub11> [openmrs-core] dkayiwa pushed 1 new commit to 1.9.x: http://git.io/psc0vA |
| 12:28:09 | <GitHub11> openmrs-core/1.9.x a692ed5 Daniel Kayiwa: ORUR01Handler should load an encounter's location from the database -... |
| 12:28:09 | *** GitHub11 has left #openmrs |
| 12:41:28 | <jkeiper> dkayiwa, Wyclif: akwatuha is following up on the complex observations work regarding sub forms |
| 12:41:43 | <dkayiwa> jkeiper: yes i noticed that :) |
| 12:42:28 | <jkeiper> dkayiwa: haha okay |
| 12:43:04 | *** suranga has joined #openmrs |
| 12:43:18 | *** ChanServ sets mode: +v suranga |
| 13:20:30 | *** harsz89 has joined #openmrs |
| 13:34:11 | *** Anuruddha has quit IRC |
| 13:43:32 | *** wyclif_ has joined #openmrs |
| 13:44:02 | <wyclif_> hi mseaton , djazayeri |
| 13:44:55 | <wyclif_> mseaton, , djazayeri which versions of openmrs do we want unit tests to be run against in sync |
| 13:50:19 | <dkayiwa> wyclif: all the way up to 1.10 :) |
| 13:50:41 | <dkayiwa> wyclif: but alteast up to 1.9.x |
| 13:54:24 | <wyclif_> dkayiwa, but 1.10 is not out |
| 13:54:48 | <dkayiwa> wyclif_: correct but it just would be good for it not to fail on 1.10 :) |
| 13:55:12 | <dkayiwa> it will eventually get out anyway :) |
| 13:55:25 | <wyclif_> dkayiwa, ok |
| 13:55:48 | <wyclif_> so it is 1.9.x to 1.10 |
| 13:57:00 | <dkayiwa> wyclif_: 1.8 inclusive |
| 13:57:18 | <wyclif_> dkayiwa, but sync requires 1.9.3? |
| 13:57:39 | <dkayiwa> wyclif_: oh i see.!!! |
| 13:57:41 | <dkayiwa> wyclif_: then you are right :) |
| 13:57:49 | <wyclif_> dkayiwa, actually 1.9.0 |
| 13:58:01 | <dkayiwa> wyclif_: k |
| 13:58:04 | *** Anuruddha has joined #openmrs |
| 13:58:11 | <wyclif_> dkayiwa, though i wonder why it requires 1.9.0 but we code it against 1.9.3 |
| 13:58:28 | <downey> !devmtg |
| 13:58:29 | <OpenMRSBot> downey: "devmtg" --- Reminder: Developer Forum Thursday at 10:00 AM Eastern Time - https://wiki.openmrs.org/display/RES/Developers+Forum |
| 14:00:16 | <dkayiwa> wyclif_: i think we are to have tests targeting all the versions we plan to support |
| 14:08:12 | <docpaul> hi alfayo! :) |
| 14:08:34 | <docpaul> dkayiwa: hi! |
| 14:08:42 | <dkayiwa> docpaul: hi |
| 14:08:48 | <dkayiwa> :) |
| 14:28:18 | *** rajiths has joined #openmrs |
| 14:31:15 | *** kavuri has quit IRC |
| 14:38:51 | *** sunbiz has joined #openmrs |
| 14:38:51 | *** ChanServ sets mode: +v sunbiz |
| 14:46:34 | *** sara has joined #openmrs |
| 14:46:51 | *** kishoreyekkanti has quit IRC |
| 14:51:10 | <sara> hi i have commited change to TRUNK 3811, pull request at https://github.com/openmrs/openmrs-core/pull/237 |
| 14:51:15 | <OpenMRSBot> <http://ln-s.net/+rtb> (at github.com) |
| 15:06:52 | *** robbyoconnor has quit IRC |
| 15:13:12 | *** sunbiz has quit IRC |
| 15:15:46 | *** lh has joined #openmrs |
| 16:03:44 | *** sara has quit IRC |
| 16:05:53 | *** rajiths has quit IRC |
| 16:14:25 | <dkayiwa> wyclif_: hi |
| 16:18:20 | *** Anuruddha has quit IRC |
| 16:27:33 | *** Anuruddha has joined #openmrs |
| 16:36:53 | *** sara has joined #openmrs |
| 16:39:25 | *** robbyoconnor has joined #openmrs |
| 16:39:25 | *** ChanServ sets mode: +v robbyoconnor |
| 16:45:31 | *** kishoreyekkanti has joined #openmrs |
| 16:50:46 | *** k-joseph has joined #openmrs |
| 17:02:40 | *** k-joseph has quit IRC |
| 17:02:54 | *** ruwanego has quit IRC |
| 17:03:32 | *** ruwanego has joined #openmrs |
| 17:06:55 | *** robbyoconnor has quit IRC |
| 17:12:08 | <wyclif_> hi dkayiwa |
| 17:12:33 | <dkayiwa> wyclif_: how do we tell hibernate about our sync interceptor? |
| 17:13:29 | <dkayiwa> wyclif_: as in i do not see any configuration sort of thing for it in the sync module |
| 17:14:38 | <wyclif_> dkayiwa, there is a bean added to the moduleApplicationContext, core loads it by type and adds it to the list of interceptors |
| 17:15:30 | <dkayiwa> wyclif_: yes i saw that bean. so core just knows its an interceptor? |
| 17:16:38 | <wyclif_> dkayiwa, core loads all beans that are subclasses of Interceptor when building the session factory |
| 17:16:48 | <dkayiwa> wyclif_: ok |
| 17:22:40 | *** k-joseph has joined #openmrs |
| 17:23:49 | *** andrea has joined #openmrs |
| 17:24:08 | *** andrea is now known as Guest16258 |
| 17:24:47 | <wyclif_> hi djazayeri mseaton |
| 17:25:21 | <djazayeri> wyclif_: hi |
| 17:26:34 | <wyclif_> djazayeri, mseaton when testing against multiple openmrs versions using profiles, do we want to add a profile for each minor release or for the latest in each release line? |
| 17:28:02 | <djazayeri> wyclif_: not sure. I would assume just the latest. |
| 17:28:16 | <wyclif_> djazayeri, ok and why does sync have 1.9.0 as the required version but we are coding it against 1.9.3? |
| 17:28:34 | <djazayeri> wyclif_: I don't know. |
| 17:30:50 | <wyclif_> djazayeri, ok thanks |
| 17:31:00 | * burke thinks that is a little odd |
| 17:32:42 | <mseaton> wyclif_: djazayeri: typically i would expect this if we need a particular version of openmrs to get our unit tests to pass, but don't necessarily want to force implementions to upgrade just for this reason |
| 17:34:08 | <wyclif_> mseaton, but that can cause problems |
| 17:34:14 | <mseaton> wyclif_: how so? |
| 17:34:29 | <mseaton> wyclif_: it can cause problems either way, right? |
| 17:35:13 | <wyclif_> mseaton, because you can have changes in the newer version that dont exist in the required though this might not be common |
| 17:35:18 | <mseaton> i mean, either openmrs running is 1.9.3 and we build against 1.9.0 or openmrs running is 1.9.0 and we build against 1.9.3. is there a better option? |
| 17:35:59 | <wyclif_> mseaton, otherwise you might have to set up testing profiles for all the minor versions in between |
| 17:36:33 | <mseaton> wyclif_: that's an option, but you still need a default profile, which is the only one that will be run 99% of the time |
| 17:36:54 | <mseaton> wyclif_: and i don't know any other module that does this. do you? |
| 17:37:15 | <wyclif_> mseaton, i think implements should be forced to upgrade if necessary to the later version since upgrades between minor versions should typically take long since they typically have no database changes |
| 17:37:57 | <mseaton> wyclif_: are you the one who wants to go upgrade 40 sync'd servers throughout a country with a new war? |
| 17:38:02 | <wyclif_> mseaton, should not take long to upgrade between minor versions, sorry! |
| 17:38:12 | <wyclif_> mseaton, hmm.. |
| 17:38:26 | <mseaton> wyclif_: in theory maybe, but in practice... |
| 17:38:29 | <wyclif_> mseaton, then they would probably wait to upgrade sync too |
| 17:38:42 | <mseaton> wyclif_: not if there is a key fix they are waiting for. |
| 17:38:43 | <dkayiwa> :) |
| 17:39:25 | <dkayiwa> wyclif_: we devs surely need some implementer experience :D |
| 17:39:31 | <wyclif_> mseaton, i think if it is key, then it would rationalize why they should upgrade all servers, but this is just my opinion but we can ignore it |
| 17:39:32 | <mseaton> wyclif_: upgrading modules can typically be done remotely via the UI, and is generally percieved to be less risky |
| 17:39:36 | <dkayiwa> wyclif_: to fully know their pain :) |
| 17:40:08 | <mseaton> wyclif_: what happens if you change the omrs version in sync pom to 1.9.0? |
| 17:40:15 | <mseaton> wyclif_: do unit tests fail? |
| 17:40:27 | <wyclif_> mseaton, probably not |
| 17:40:37 | <mseaton> wyclif_: i wouldn't be so sure :) |
| 17:40:52 | <mseaton> wyclif_: but if not, then i see no reason why not to change it. |
| 17:40:53 | <dkayiwa> mostly likely some test will fail :) |
| 17:41:10 | <dkayiwa> but we can fix them |
| 17:41:34 | <mseaton> wyclif_: so the question becomes - is it better to ignore tests in order to have our omrs version = 1.9.0 in the pom, or is it better to do the tests, but increase our version to 1.9.3 |
| 17:41:37 | <mseaton> i think it is the latter. |
| 17:42:37 | <djazayeri> We don't *have* to have the requireVersion and the version we build against be the same, do we? |
| 17:42:47 | <mseaton> wyclif_: dkayiwa put another way: if we find a sync bug that exists in 1.9.0 but not in 1.9.3, does this mean we should stop supporting 1.9.0 altogether? |
| 17:42:58 | <mseaton> for sync? |
| 17:43:04 | <mseaton> djazayeri: that's my point |
| 17:43:17 | <mseaton> djazayeri: are you agreeing with me? |
| 17:43:30 | <dkayiwa> mseaton: i agree |
| 17:43:49 | <wyclif_> if there is a bug in 1.9.0 that fails sync, then i guess we need to stop supporting it |
| 17:43:52 | <djazayeri> mseaton: I'm agreeing that it's okay to require an older version, but test against a newer, as long as we've documented the issue right. |
| 17:44:10 | <mseaton> wyclif_: does this mean we should stop supporting openmrs 1.6? there are bugs there that don't exist in 1.9 |
| 17:44:13 | *** sunbiz has joined #openmrs |
| 17:44:13 | *** ChanServ sets mode: +v sunbiz |
| 17:44:31 | <wyclif_> djazayeri, how about coding against a later version is what am concerned about |
| 17:44:35 | <djazayeri> If it's *bad* failure, we could stop supporting 1.9.0, but not fore "minor bugs" |
| 17:44:41 | <mseaton> wyclif_: i think we can _encourage_ users to upgrade |
| 17:45:03 | <mseaton> djazayeri: wyclif_ : yes, i think it needs to be a judgement call as to the severity of the bug |
| 17:46:24 | <mseaton> djazayeri: wyclif_ but if we have 10 bug fixes in the sync module, and 1 of these fixes requires 1.9.4, and we increase the minimum version to 1.9.4 because of it. then, say, rwanda will not get any of these 10 fixes at all since they are not able to upgrade the war quickly. whereas if we had left the version at 1.9.0, then 9/10 fixes will work for them. |
| 17:46:24 | <mseaton> so they'll still be much better off. |
| 17:49:07 | <djazayeri> mseaton: I completely agree with you, and I think it's a *requirement* that we do it this way. We should treat it as a technical issue of "what do we devs have to do to make it behave that way" |
| 17:49:35 | <wyclif_> mseaton, this might sound weird, in that case i would release 2 versions of sync one with the 9 fixes and requires the older version, the another that includes the 10th bug and requires the newer version |
| 17:51:02 | <wyclif_> u rather dont include the fix in the version that doesnt support it |
| 17:56:14 | *** dkayiwa has quit IRC |
| 17:56:42 | *** dkayiwa has joined #openmrs |
| 17:58:02 | <wyclif_> mseaton, djazayeri what do you think of instead to release 2 versions of module that require different versions and one excludes the fix it doesnt support, that way the user still gets all the fixes that are supported by their openmrs version |
| 18:00:39 | <wyclif_> djazayeri, mseaton FYI i have noticed sync tests fail when i run it against 1.9.0 |
| 18:01:30 | <dkayiwa> wyclif: i experienced the same too |
| 18:02:57 | <wyclif_> dkayiwa, and this is what will typically happen probably whenever you have the required version different from what you coded against |
| 18:03:27 | <dkayiwa> wyclif_: sure |
| 18:07:18 | <wyclif_> dkayiwa, are you confortable with maven profile setup |
| 18:07:32 | <dkayiwa> wyclif_: no |
| 18:10:49 | *** k-joseph has quit IRC |
| 18:11:24 | <mseaton> wyclif_: 2 things. the first is that i do not have the time or desire to maintain multiple versions like this |
| 18:12:26 | <mseaton> wyclif_: the second is that in the case i describe, the fix itself is not in the sync module. it's in 1.9.3 (eg.). so there is nothing different between the two versions of the sync module. it's just that when run against 1.9.0 a unit test fails, and against 1.9.3 the unit test passes |
| 18:13:35 | <mseaton> and this is because a fix was applied in the 1.9.x line of openmrs to fix a core bug. sync happened to uncover this core bug. |
| 18:17:07 | <mseaton> wyclif_: what i would recommend is that you look at what unit tests fail against 1.9.0, and start a discussion as to whether these issues are significant enough to warrant us moving to prevent users from using sync on 1.9.0 in the future, thus changing the required version to 1.9.3. |
| 18:17:32 | *** sara has quit IRC |
| 18:20:08 | *** k-joseph has joined #openmrs |
| 18:24:51 | *** wluyima has joined #openmrs |
| 18:24:52 | *** wyclif_ has quit IRC |
| 18:25:03 | *** wyclif_ has joined #openmrs |
| 18:26:00 | <k-joseph> dkayiwa: hi |
| 18:26:07 | <dkayiwa> k-joseph: hi |
| 18:27:03 | <k-joseph> dkayiwa: when and how are retired concepts showed as retired, am not understanding what et members are in this case? |
| 18:27:17 | <dkayiwa> k-joseph: which ticket |
| 18:27:21 | <k-joseph> !ticket TRUNK-3840 |
| 18:27:23 | <OpenMRSBot> k-joseph: [#TRUNK-3840] Retired concepts arent showed as retired when listed as set members - OpenMRS JIRA - https://tickets.openmrs.org/browse/TRUNK-3840 |
| 18:28:55 | <dkayiwa> k-joseph: do you first of all have a concept set you are looking at? |
| 18:29:19 | <k-joseph> dkayiwa: yes i have it |
| 18:29:34 | <dkayiwa> k-joseph: does it have any members that are retired? |
| 18:30:43 | <k-joseph> :) |
| 18:32:41 | <k-joseph> dkayiwa: i clicked retired button and i thought this makes it all retired |
| 18:33:16 | <dkayiwa> k-joseph: do you know what set members are? |
| 18:33:46 | <k-joseph> dkayiwa: i dont know that yet |
| 18:34:12 | <dkayiwa> k-joseph: can you create a concept set? |
| 18:34:13 | <k-joseph> dkayiwa: and even how to retire members of a certain concept |
| 18:35:15 | <k-joseph> dkayiwa: i can create a concept. is that concept set |
| 18:36:41 | *** GitHub123 has joined #openmrs |
| 18:36:41 | <GitHub123> [openmrs-core] andreapat opened pull request #253: Trunk 3289a (master...TRUNK-3289a) http://git.io/hvgbWg |
| 18:36:41 | *** GitHub123 has left #openmrs |
| 18:37:25 | <dkayiwa> k-joseph: can you check the ANTIRETROVIRAL DRUGS concept? |
| 18:38:11 | <k-joseph> dkayiw: i have already checked it out, no wthere\ |
| 18:38:23 | <dkayiwa> k-joseph: do you have demo data? |
| 18:39:32 | <k-joseph> dkayiwa: yes i do |
| 18:39:32 | <k-joseph> dkayiwa: i checked that option while installing |
| 18:39:33 | <sunbiz> downey: hey... thanks for the COTM hoodie. Looks really nice... amazing quality |
| 18:40:10 | <sunbiz> downey: but too little OpenMRS branding... just a small icon, not even the text :( |
| 18:40:16 | <dkayiwa> k-joseph: can you create a concept which is a ConvSet? |
| 18:42:59 | <k-joseph> dkayiwa: what is concept which is a ConvSet?, am not full getting this |
| 18:43:32 | <dkayiwa> k-joseph: where the Class is ConvSet |
| 18:44:17 | <k-joseph> dkayiwa: ok |
| 18:44:43 | <k-joseph> dkayiwa: done with that |
| 18:44:56 | <dkayiwa> k-joseph: which data type did you choose? |
| 18:45:25 | <k-joseph> dkayiwa: text |
| 18:45:37 | <dkayiwa> k-joseph: choose Coded |
| 18:45:50 | <dkayiwa> k-joseph: and then add answers |
| 18:55:53 | <k-joseph> dkayiwa: ok, fine now |
| 18:56:56 | <dkayiwa> k-joseph: so do you see you answers that you added to the concept? |
| 18:58:18 | <k-joseph> dkayiwa: yes, i see them |
| 18:58:52 | <dkayiwa> k-joseph: how many did you add? |
| 18:59:19 | <k-joseph> dkayiwa: 2 |
| 18:59:29 | <dkayiwa> k-joseph: so those are the members |
| 19:03:50 | *** andreapat has joined #openmrs |
| 19:05:17 | <andreapat> where is cpower? |
| 19:05:57 | <andreapat> mseaton, djazayeri: are we scrumming? |
| 19:06:14 | <mseaton> !scrumon mseaton |
| 19:06:14 | * OpenMRSBot says the DAILY SCRUM MEETING is STARTING. This meeting should not last longer than 15 minutes. Please hold other comments until the end of the meeting, or message someone privately. Thank you! ScrumMaster mseaton- you may begin when ready. |
| 19:06:49 | <mseaton> order: mseaton, andreapat, wyclif, dkayiwa, djazayeri... |
| 19:07:21 | <mseaton> no substantive updates on my end since yesterday. continuing on code review, irc. |
| 19:07:24 | <mseaton> no blockers |
| 19:07:44 | <mseaton> andreapat: ? |
| 19:08:16 | <andreapat> Wednesday - Thursday morning |
| 19:08:17 | <andreapat> Design call |
| 19:08:17 | <andreapat> Dev call |
| 19:08:17 | <andreapat> TRUNK-3289 |
| 19:08:17 | <andreapat> Debug in Eclipse |
| 19:08:18 | <andreapat> Fix failing test |
| 19:08:20 | <andreapat> committed, pushed TRUNK-3289 |
| 19:08:21 | <k-joseph> dkayiwa: ok, i now see, retired members are indicated by middle strikes, that is clear and i think that is what at first the ticket demanded, now according to wyclif, these middle strikes are affecting some links on the admin page and my version has this problem as well, i think that this is the fix to make |
| 19:08:21 | <andreapat> pull requst: https://github.com/openmrs/openmrs-core/pull/253 |
| 19:08:23 | <andreapat> Thursday afternoon - Friday |
| 19:08:25 | <andreapat> Update wiki documentation for debugging in Eclipse |
| 19:08:28 | <andreapat> Pick new ticket |
| 19:08:29 | <OpenMRSBot> <http://ln-s.net/+s0A> (at github.com) |
| 19:08:29 | <andreapat> Discussion: |
| 19:08:31 | <andreapat> Just saw emails from mseaton, djazayeri - will fix javadoc ect and do |
| 19:08:35 | <andreapat> new pull request |
| 19:08:55 | <wyclif_> Wednesday: |
| 19:08:55 | <wyclif_> -Listened in to university call |
| 19:08:55 | <wyclif_> -Revisted SYNC-245 after chat with Mike - rom History of Changes page, unable to reset a record as a new sync record if any of the child server records are in the "waiting to synchronize" state |
| 19:08:55 | <wyclif_> -SYNC-294 - Ensure outgoing sync error details are properly logged and available to the administrator |
| 19:08:55 | <wyclif_> -design call |
| 19:08:57 | <wyclif_> -Helped Andrea debug some failing tests |
| 19:08:59 | <wyclif_> Thursday: |
| 19:09:01 | <wyclif_> -dev call |
| 19:09:03 | <wyclif_> -Code review of tickets in community dev smimlane |
| 19:09:05 | <wyclif_> -pick another sprint ticket |
| 19:09:07 | <wyclif_> |
| 19:09:09 | <wyclif_> Blockers: None |
| 19:09:20 | <mseaton> andreapat: please also squash your commits |
| 19:09:27 | <dkayiwa> Committed and back ported: ORUR01Handler should load patient and concept from the datatabase - TRUNK-3929 |
| 19:09:28 | <dkayiwa> Back ported to 1.9.x: ORUR01Handler should load an encounter's location from the database - TRUNK-3896 |
| 19:09:28 | <dkayiwa> Committed: Support the ability to sync Lists - SYNC-296 |
| 19:09:28 | <dkayiwa> Dev Call |
| 19:09:28 | <dkayiwa> Now working on: Sync fails to save collections of non-openmrs objects if the owning object has no updates - SYNC-307 |
| 19:09:29 | <dkayiwa> No Blockers |
| 19:09:37 | <andreapat> mseaton: will squash |
| 19:09:47 | <mseaton> dkayiwa: did you see my comments on SYNC-296? |
| 19:10:06 | <dkayiwa> mseaton: yes seen them |
| 19:10:21 | <mseaton> dkayiwa: thoughts? |
| 19:11:19 | <dkayiwa> mseaton: i fully agree. though setting up such a test seems like lots of work. domain object, hibernate mapping file, service layer, data access layer, etc :) |
| 19:11:46 | <dkayiwa> mseaton: as in for an object that has a list collection |
| 19:11:51 | <mseaton> dkayiwa: should be a piece of cake for you! :) |
| 19:12:08 | <mseaton> dkayiwa: i agree. a lot of work. but i think necessary. |
| 19:12:22 | <dkayiwa> mseaton: it is not complicated ofcourse, but takes quite some hours :) |
| 19:12:31 | <dkayiwa> mseaton: ok |
| 19:12:46 | <mseaton> dkayiwa: do you have any other evidence that we now support lists? what is your success criteria? |
| 19:13:10 | <dkayiwa> mseaton: no unit test at all :) |
| 19:13:18 | <dkayiwa> mseaton: just in theory :) |
| 19:13:47 | <mseaton> dkayiwa: ok. well, let's test that theory! |
| 19:14:06 | <dkayiwa> mseaton: :D |
| 19:14:19 | <mseaton> does anyone else have anything to discuss in scrum? djazayeri ? sunbiz ? jkeiper ? |
| 19:14:29 | <djazayeri> nothing sync'y from me |
| 19:14:51 | <mseaton> wyclif_: did we resolve the openmrs version discussion? |
| 19:15:01 | <mseaton> wyclif_: or do we need to hash out more? |
| 19:15:45 | <wyclif_> mseaton, did you read my suggestion? |
| 19:16:06 | <mseaton> wyclif_: which suggestion is that? did you see all my subsequent comments? |
| 19:16:19 | <sunbiz> mseaton: nope... nothing from my side |
| 19:16:44 | <sunbiz> I'd like to see multiple maintained version of the modules as well |
| 19:16:55 | <sunbiz> so I like wyclif_ idea |
| 19:17:02 | <wyclif_> i personally think form the scenario you gave, i would release 2 versions of sync, one with the 9 fixes and requires/code agiast a lower version and another with the 10th fix that requires a later version |
| 19:17:26 | <mseaton> wyclif_: the sync module itself does not contain the 10th fix. you get that right? |
| 19:17:29 | <sunbiz> its much more work... but I think might be good option instead of too much complexity |
| 19:18:11 | <djazayeri> sunbiz, wyclif_ : given the (limited) resources that are available for the sync module, that seems like a complete non-starter to me... |
| 19:18:14 | <wyclif_> i mean i would exclude the 10th fix from the version that doesnt support the later openmrs version |
| 19:18:26 | *** kishoreyekkanti has quit IRC |
| 19:18:31 | <sunbiz> but I thought the same for the webservices.rest as well... |
| 19:18:32 | <mseaton> wyclif_: there is no fix. the fix is in openmrs |
| 19:18:33 | <wyclif_> djazayeri, releasing a module doent take that long |
| 19:18:58 | <sunbiz> instead of writing complex code... to find the compatible classes... I'd like separate versions of modules that work with separate versions of OpenMRS |
| 19:19:02 | <djazayeri> wyclif_: maintaining two versions and backporting every new fix *does* take a huge amount of effort |
| 19:19:12 | <sunbiz> and they die their deaths along with the core EOL |
| 19:19:25 | <wyclif_> djazayeri, dut you dont backport to a release version |
| 19:19:36 | <wyclif_> djazayeri, but you dont backport to a released version |
| 19:19:57 | <mseaton> wyclif_: i still think you are not understanding my scenario |
| 19:19:57 | <djazayeri> wyclif_: but you're suggesting releasing two different versions of sync (and presumably maintaining both going forwards) |
| 19:20:04 | <wyclif_> djazayeri, what is said is you release a new minor version with the 9 fixes |
| 19:20:18 | <burke> creating one module that is smart about versioning is more work for devs & less work for implementers. OpenMRS <3 implementers. :-) |
| 19:20:23 | <djazayeri> wyclif_: but regardless, as mseaton says, there are no changes to the sync module here. It's just a core bug that gets fixed in 1.9.3 |
| 19:21:05 | <sunbiz> burke: yes, loving the implementers can be done through the module repository |
| 19:21:07 | <sunbiz> :D |
| 19:21:24 | <wyclif_> djazayeri, sync shouldnt be concerned about core bugs unless they affect it or make it fail |
| 19:21:27 | <sunbiz> burke: asking them to build off code is not "true" love |
| 19:22:07 | <wyclif_> djazayeri, if a core bug affects sync, then sync should require and be build against the version with the fix and later |
| 19:22:22 | <mseaton> wyclif_: should we not support htmlformentry on 1.8 if there is a bug in core that improperly saves obs? |
| 19:22:28 | <sunbiz> burke: well branded product (version numbers/codenames) is good love :) |
| 19:23:04 | <mseaton> wyclif_: should we comment out all of the unit tests for htmlformentry that might test this behavior working? |
| 19:23:17 | <sunbiz> burke: and in the longer term simple code might be implementer love compared to complex/smart versioning |
| 19:23:24 | <sunbiz> !seen burke |
| 19:23:24 | <OpenMRSBot> sunbiz: burke was last seen in #openmrs 3 minutes and 6 seconds ago: <burke> creating one module that is smart about versioning is more work for devs & less work for implementers. OpenMRS <3 implementers. :-) |
| 19:24:16 | <mseaton> !scrumoff |
| 19:24:16 | * OpenMRSBot says the DAILY SCRUM MEETING has ENDED. This channel is now returned to normal hacking operations. Post-scrum meeting follow-up conversations may now begin. |
| 19:24:50 | <djazayeri> wyclif_, mseaton : I need to go get lunch now, but my parting thoughts are that I 100% agree with Mike here, and we *must* let sync run on 1.9.0, so that PIH Rwanda can use it. That's a key requirement, because if we don't meet that, we'll get much less of Mike's time. |
| 19:24:55 | <wyclif_> mseaton, i would say yes |
| 19:25:24 | <mseaton> wyclif_: seriously? |
| 19:25:27 | <wyclif_> mseaton, becasue you will be saving bad data in that case which makes the module basically useless |
| 19:25:30 | <djazayeri> I think the solution here is to have different profiles for testing against 1.9.0 and 1.9.3 |
| 19:25:47 | <wyclif_> djazayeri, how about 1.9.2 and 1.9.1 |
| 19:26:00 | <djazayeri> wyclif_: what is the specific bug that we're talking about here, though? |
| 19:26:02 | <wyclif_> djazayeri, and already the tests fail on the 1.9.0 profile |
| 19:26:06 | <mseaton> djazayeri: wyclif_ what's the point? |
| 19:26:29 | <djazayeri> wyclif_: Just 1.9.0 (which is the min supported version) and 1.9.3 (which is the latest) |
| 19:26:29 | <wyclif_> mseaton, djazayeri the tests in sync fail with the 1.9.0 profile |
| 19:26:55 | <djazayeri> wyclif_: why? what's the actual error. We need to talk about the concrete example. |
| 19:27:00 | <wyclif_> mseaton, because 1.9.2 alters the database |
| 19:27:15 | <wyclif_> in the order table |
| 19:27:56 | <mseaton> wyclif_: so in that case, just having different test data sets should fix things? |
| 19:29:00 | <mseaton> wyclif_: djazayeri i'm not that concerned about sync here specifically. i'm more concerned with the overall disagreement over how to approach this situation. |
| 19:29:54 | <djazayeri> mseaton: (final message before I walk away from my computer): I agree with what I think is your position that we should generally prefer modules to support the oldest OpenMRS version that's feasible. |
| 19:32:53 | <k-joseph> dkayiwa: hi |
| 19:33:08 | <wyclif_> mseaton, i think the key question here is do we want to have a future proof solution or a solution that might only work in the short run |
| 19:33:12 | <dkayiwa> k-joseph: hi |
| 19:34:42 | <k-joseph> dkayiwa: did you see my last question at [22:07:29] |
| 19:34:45 | <k-joseph> ? |
| 19:35:25 | <wyclif_> mseaton, what 1.9.3 has new method that wer eare calling, this would fail in 1.9.0, because something is not occuring right now it doesnt mean we should ignore it |
| 19:35:25 | <dkayiwa> k-joseph: yes |
| 19:35:38 | <wyclif_> mseaton, mean to sat what if |
| 19:35:48 | <wyclif_> sorry about my typos |
| 19:36:17 | <k-joseph> dkayiwa: what do you have to say a bout it? |
| 19:36:25 | <wyclif_> mseaton, what if 1.9.3 has new method that were are calling and was just added in it, this would fail in 1.9.0, because something is not occurring right now it doesn't mean we should ignore it |
| 19:36:26 | <dkayiwa> k-joseph: you are correct |
| 19:38:15 | <wyclif_> mseaton, i'm fine with the way you want to do though |
| 19:39:24 | <djazayeri> Can we keep the version we code against as 190 and only test 193 via profile? |
| 19:40:15 | <wyclif_> djazayeri, am fine with it if that is what the majority thinks is right to do |
| 19:41:41 | <wyclif_> djazayeri, also if we are coding against 1.9.3 then we need profiles for 1.9.0, 1.9.1, 1.9.2 and 1.9.3 |
| 19:42:29 | <wyclif_> djazayeri, i prefer your suggestion, coding against 1.9.0 and add profiles for all later versions |
| 19:42:33 | <djazayeri> It's that our standard practice? To have test profiles for every release? |
| 19:42:48 | <djazayeri> I didn't think we did that... |
| 19:43:31 | <downey> sunbiz: secret society ;) |
| 19:43:34 | <k-joseph> dkayiwa: ok, then this seems to be because some links have retired class, according to wyclif comment still, now i want to fix this, and i need to know what these are and what , and how to trace them, and clean them |
| 19:43:45 | <cpower> andreapat: getting sidetracked and losing track of time is why he wasn't here at scrum time. Sorry everyone. I'll set better alarms |
| 19:43:57 | <sunbiz> downey: thanks so much for it... |
| 19:44:14 | <sunbiz> sadly had to pay the customs... |
| 19:44:20 | <dkayiwa> k-joseph: can you ask on the ticket? |
| 19:44:33 | <andreapat> cpower, you are forgiven |
| 19:44:40 | <k-joseph> ok |
| 19:44:53 | <sunbiz> downey: they said the rule is NOK200 or higher in value... so if its not really valuable, please ask the sender next time to undervalue it :| |
| 19:45:02 | <sunbiz> :-/ |
| 19:45:02 | <wyclif_> k-joseph, that is right, adding a retired class to have a strike through introduces a bug where some links get the strike because they wrongly have that class on them, one soltion is to search for them and remove it or not use it at all |
| 19:46:35 | <wyclif_> k-joseph, you can use eclipse to search for the text "class='retired'" and fix those if you think they shouldn't have the class, i know some exist on the admin page |
| 19:47:07 | <k-joseph> wyclif_: ok thanks a lot for that |
| 19:47:14 | <wyclif_> k-joseph, if you apply that comment i reverted and you visit the admin page, you will see them |
| 19:51:04 | *** harsz89 has quit IRC |
| 19:51:27 | <wyclif_> mseaton, do you agree with djazayeri 's proposed solution, i.e changing the version we code against 1.9.0 and add profile for all earlier versions |
| 19:51:38 | *** Mkop1 has quit IRC |
| 19:52:58 | <wyclif_> mseaton, that way we have the required and what we are coding against the same and still support 1.9.0 |
| 20:04:24 | <wyclif_> mseaton, am waiting for you to push come code |
| 20:04:31 | <wyclif_> mseaton, am waiting for you to push some code |
| 20:23:32 | * sunbiz <3 the Spanish and functions thread on the list!! :) |
| 20:24:28 | <dkayiwa> sunbiz: the female functions are so so 8) |
| 20:35:48 | <mseaton> wyclif_: sorry was in another meeting. |
| 20:36:30 | <mseaton> wyclif_: clearly if sync uses a new method that's in 1.9.3 and not in 1.9.0 then we need to up the dependency to 1.9.3 in config.xml |
| 20:36:48 | <mseaton> wyclif_: but that's a different case. |
| 20:37:07 | <mseaton> wyclif_: we don't support earlier versions than 1.9.0. do you mean later versions? |
| 20:37:25 | <sunbiz> dkayiwa: yup!! :) but methods are male |
| 20:37:30 | *** GitHub106 has joined #openmrs |
| 20:37:30 | <GitHub106> [openmrs-core] wluyima pushed 1 new commit to master: http://git.io/lRP2UQ |
| 20:37:30 | <GitHub106> openmrs-core/master e60d95e Bhashitha: Add search button to Concept search -TRUNK-3836... |
| 20:37:30 | *** GitHub106 has left #openmrs |
| 20:38:02 | <wyclif_> mseaton, i meant the versions between 1.9.0 and 1.9.3 |
| 20:38:21 | <dkayiwa> sunbiz: they better be :) |
| 20:38:23 | <mseaton> wyclif_: what i want to avoid is having to ignore valid, useful unit tests, which pass against a current version (eg. 1.9.3), but fail against an earlier version (eg. 1.9.0) because we insist upon depending on 1.9.0 |
| 20:38:45 | <sunbiz> dkayiwa: I guess it tells something about objectivity |
| 20:38:56 | <dkayiwa> sunbiz: oh yes :) |
| 20:38:59 | <wyclif_> mseaton, we still have the tests for 1.9.3 via profiles if we drop it to 1.9.0o |
| 20:39:06 | <mseaton> wyclif_: if the test failures can be fixed by having different profiles for each (eg. all we need to do is have a different test data set since the data model changed) then that should work |
| 20:39:18 | <wyclif_> mseaton, am fine with that |
| 20:39:35 | <mseaton> wyclif_: but i don't know how to tell the system to run test X with profile 1.9.3 and not with profile 1.9.0 |
| 20:39:58 | <sunbiz> oops... lh is in the room!! |
| 20:40:03 | <mseaton> wyclif_: we can change the test data, but if the issue is deeper than that (eg. logic in a core method), i'm not sure what else we can do |
| 20:40:14 | * lh waves |
| 20:40:16 | <wyclif_> mseaton, mvn test -DTestClassName -P openmrsVersion |
| 20:40:25 | <sunbiz> dkayiwa: we better find a place to hide from lh |
| 20:40:31 | <djazayeri> mseaton, wyclif_ : in the test method: if (OpenmrsConstants.VERSION >= "1.9.3") ... |
| 20:40:36 | *** jblaya has joined #openmrs |
| 20:40:50 | <sunbiz> lh: see the discussion about Spanish lang... |
| 20:41:05 | <sunbiz> lh: functions are females and methods are male... |
| 20:41:22 | <wyclif_> mseaton, i committed the code already, i didnt change the versions in the poms and config, only added profiles for 1.10 and 1.9.0 |
| 20:41:57 | <mseaton> djazayeri: wyclif_ can you set it up to ignore that test class in the profile itself, so that when we later move up the minimum version to 1.9.4 for example, this conditional logic disappears? |
| 20:42:12 | <dkayiwa> sunbiz: to hide from lh you would need to first of all know if he or she is a method or function :) |
| 20:43:19 | <wyclif_> i guess my argument was because today they didn't break into my house, i shouldn't do anything about it to safe guard myself tomorrow |
| 20:43:29 | <sunbiz> dkayiwa: lh is a function... a functionary from the GSoC world and speaks about feminism and other things |
| 20:44:21 | <dkayiwa> sunbiz: oh i see!!! Surely lh is great functionality :) |
| 20:45:26 | <sunbiz> dkayiwa: https://twitter.com/lhawthorn |
| 20:45:49 | <wyclif_> mseaton, almost all tests fail because they the test dataset is executed for all subclasses of BaseModuleContextSensitiveTest |
| 20:46:26 | <dkayiwa> sunbiz: oh oh oh oh oh oh oh d:) |
| 20:47:22 | <lh> sunbiz, and being excellent to each other. :) |
| 20:47:27 | <sunbiz> dkayiwa: did u read the last tweet |
| 20:47:28 | * lh is a function, fwiw |
| 20:48:04 | <mseaton> wyclif_: it will be annoying to have to update 2 different test dataset files just to support the 1.9 release. :/ |
| 20:48:11 | <dkayiwa> sunbiz: from rikkiends ? |
| 20:48:45 | <mseaton> djazayeri: why isn't that column nullable! :) |
| 20:48:46 | <sunbiz> dkayiwa: yes... how some1 got fired for sexist jokes |
| 20:49:23 | <sunbiz> lh: BTW thanks for the gr8 tweets |
| 20:49:31 | <lh> sunbiz, yw :) |
| 20:49:45 | *** k-joseph has quit IRC |
| 20:50:20 | *** travis-ci has joined #openmrs |
| 20:50:20 | <travis-ci> [travis-ci] [openmrs/openmrs-core] [e60d95e] [Bhashitha] The build passed. - http://travis-ci.org/openmrs/openmrs-core/builds/5697834 |
| 20:50:20 | *** travis-ci has left #openmrs |
| 20:50:25 | <OpenMRSBot> <http://ln-s.net/+s2R> (at travis-ci.org) |
| 20:50:47 | <wyclif_> mseaton, i leave the version things in the hands of the people who oversee the module, i guess what iw ant to know is i should profiles for 1.9.1 and 1.9.2? |
| 20:51:45 | <wyclif_> mseaton, actually i added the profile for 1.9.0 but i didnt attempt to make the tests pass i think that should be a separate ticket, right? |
| 20:51:57 | <cpower> I rap in a update and I get no props...what the heck! |
| 20:52:22 | <cpower> what do I have to do to get a reaction out of you people |
| 20:52:59 | <cpower> I mean even boos is better than getting ignored |
| 20:53:03 | <sunbiz> cpower: I did react |
| 20:53:28 | <cpower> sunbiz: thanks! |
| 20:53:29 | <sunbiz> cpower: generally no1 does to those scrum updates... so I thought I'd reply |
| 20:54:10 | <sunbiz> cpower: but felt guily soon after... considering that there might be 1000 ppl who might receive yet another email |
| 20:54:15 | <sunbiz> that they could have avoided |
| 20:54:19 | <sunbiz> *guilty |
| 20:54:36 | <sunbiz> *been avoided |
| 20:54:42 | <mseaton> wyclif_: yes, that can be a separate ticket i guess. i suppose adding in profiles for all minor releases makes sense, as long as they are only run on request and just requires a few lines of code in the pom, and not new test data for each |
| 20:55:09 | <wyclif_> mseaton, ok |
| 20:55:52 | <wyclif_> mseaton, the default all tests are only run against the version defined in the properties |
| 20:55:59 | <mseaton> yep |
| 20:56:15 | <mseaton> wyclif_: why do you even need to enable 1.9.1 or 1.9.2? |
| 20:56:17 | <wyclif_> mseaton, sorry for bugging you |
| 20:56:23 | <cpower> sunbiz: if you are on our mailing lists you are not worried about one more piece of mail. |
| 20:56:58 | <wyclif_> mseaton, i just added them but you only run tests against the manually if you set the profile argument |
| 20:57:19 | <mseaton> wyclif_: can't you just do: mvn clean package -DopenMRSVersion=1.9.1 |
| 20:57:20 | <wyclif_> mseaton, so they are not enabled by default |
| 20:57:31 | <wyclif_> mseaton, yes you can |
| 20:57:43 | <wyclif_> mseaton, so the default is 1.9.3 |
| 20:58:00 | <mseaton> wyclif_: so what does it mean to add testing support for 1.9.1 and 1.9.2 ? |
| 20:58:02 | <wyclif_> mseaton, and is it id what gets used if no profile is specified |
| 20:58:43 | <wyclif_> mseaton, if you wan to test against those versions you have to explicitly tell maven by specifying the profile |
| 20:58:46 | <mseaton> wyclif_: my question is: what does a "profile" offer us. can't we just set the openMRSVersion property dynamically at runtime by passing in the appropriate argument to mvn clean package ? |
| 20:59:06 | <wyclif_> mseaton, right, and that is what the profiles do |
| 20:59:20 | <wyclif_> mseaton, instead of you doing it manually |
| 21:00:15 | <wyclif_> mseaton, basically any mvn command you run that requires a build/tests it defaults to 1.9.3 and never uses the profiles unless you say so |
| 21:00:39 | <wyclif_> mseaton, and i guess this is what you want, right? |
| 21:00:43 | <mseaton> wyclif_: but your profiles don't differ at all except the version of the openMRSVersion property within them |
| 21:00:52 | <mseaton> wyclif_: so what do they really offer? |
| 21:00:55 | <wyclif_> mseaton, correct |
| 21:01:05 | <mseaton> wyclif_: i can see the point if other dependencies need to differ |
| 21:01:15 | <djazayeri> mseaton: I think profiles are easier to run differently in CI. |
| 21:01:53 | <wyclif_> mseaton, what they offer is that you can switch between versions to run or build against with a single comand argument without editing anything |
| 21:02:31 | <wyclif_> mseaton, otherwise you wanted to run tests against 1.10, you would have to edit all the poms |
| 21:02:52 | <mseaton> wyclif_: i understand that :) but in this specific case so far, you get the exact same behavior without having the profiles in the pom by running : mvn clean install "-DopenMRSVersion=1.9.1" |
| 21:03:00 | <wyclif_> mseaton, sorry the pom with the version and they are good to run tests on a remote machine |
| 21:03:10 | <wyclif_> mseaton, yes |
| 21:03:15 | <mseaton> wyclif_: you can pass in properties (and change their values form their defaults) at runtime |
| 21:03:18 | <dkayiwa> :)] |
| 21:03:41 | <wyclif_> mseaton, you are right, but i dont understand in the first place why the ticket was created then |
| 21:03:50 | <dkayiwa> :) |
| 21:04:14 | <mseaton> ask mark :) |
| 21:04:51 | <dkayiwa> he could just be a profile fun :) |
| 21:04:53 | <wyclif_> mseaton, because just setting the property on the command line does it too |
| 21:04:54 | <mseaton> seriously though. if wyclif_ and djazayeri you are saying that CI and other tools can deal with profiles natively, but not with properties, then ok |
| 21:05:10 | <wyclif_> mseaton, am not sure about that |
| 21:05:18 | <wyclif_> mseaton, may be djazayeri does |
| 21:05:21 | <djazayeri> mseaton: I believe that's the case, but that's somewhat speculation |
| 21:05:28 | <mseaton> wyclif_: and obviously it allows for the specifics of the profile to change without the command itself to change, which is nice if you are scripting with CI |
| 21:05:56 | <wyclif_> mseaton, right |
| 21:06:33 | <mseaton> djazayeri: wyclif_ ok i'm convinced. wyclif_ do you need to repeat the openmrs dependencies in each profile like you did? |
| 21:06:47 | <mseaton> wyclif_: or is it enough just to set the property |
| 21:08:38 | <wyclif_> mseaton, i repeat them, but i doubt if it is necessary, i can test and remove them if not requires |
| 21:08:50 | <mseaton> wyclif_: that would make me happy |
| 21:09:03 | <wyclif_> mseaton, will test and make changes if necessary |
| 21:09:33 | <mseaton> wyclif_: thanks. and i guess add in 1.9.1 and 1.9.2 while there :) |
| 21:10:18 | <wyclif_> mseaton, cool |
| 21:10:25 | <wyclif_> thanks guys |
| 21:37:08 | *** wluyima has quit IRC |
| 21:37:33 | *** wyclif_ has quit IRC |
| 22:21:14 | *** wyclif_ has joined #openmrs |
| 22:22:17 | *** wluyima has joined #openmrs |
| 22:50:03 | *** lh has quit IRC |
| 23:03:31 | *** jblaya has quit IRC |
| 23:19:09 | *** sunbiz has quit IRC |
| 23:26:51 | <OpenMRSBot> Recent updates in the world of openmrs: Saptarshi Purkayastha : Shout or Leave? - Open-source community governance <http://feedproxy.google.com/~r/SunnyTalksTech/~3/yukbGf6wk7M/shout-or-leave-open-source-community.html> |
| 23:42:10 | *** GitHub106 has joined #openmrs |
| 23:42:10 | <GitHub106> [openmrs-core] wluyima pushed 1 new commit to master: http://git.io/OQ3CyQ |
| 23:42:10 | <GitHub106> openmrs-core/master 70ae7e3 jeffblack360: TRUNK-3098: Add unit-test getConceptsByAnswer_shouldFindAnswersForConcept |
| 23:42:10 | *** GitHub106 has left #openmrs |
| 23:42:10 | *** dkayiwa has quit IRC |
| 23:52:14 | *** travis-ci has joined #openmrs |
| 23:52:14 | <travis-ci> [travis-ci] [openmrs/openmrs-core] [70ae7e3] [jeffblack360] The build passed. - http://travis-ci.org/openmrs/openmrs-core/builds/5702317 |
| 23:52:14 | *** travis-ci has left #openmrs |
| 23:52:21 | <OpenMRSBot> <http://ln-s.net/+s6B> (at travis-ci.org) |
| 23:53:50 | *** portablejim has joined #openmrs |