The IRC channel is #sakai on the freenode network, you can join using a web client at http://webchat.freenode.net/?channels=sakai and you can view the complete logs at http://sakai.iriscouch.com/irc/_design/viewer/index.html
00:28 <SakaiGithub> [3akai-ux/1.4.0-release] NOJIRA revert pom versions to 1.4.0-SNAPSHOT in order to do a release:prepare - Anthony Whyte 00:52 <SakaiGithub> [3akai-ux] arwhyte tagged 1.4.0-release-tag at org.sakaiproject.nakamura.uxloader-1.4.0: http://git.io/Hzq0sA 00:52 <SakaiGithub> [3akai-ux/1.4.0-release-tag] [maven-release-plugin] prepare release 1.4.0-release-tag - Anthony Whyte 00:52 <SakaiGithub> [3akai-ux] arwhyte tagged org.sakaiproject.nakamura.uxloader-1.4.0 at 1.4.0-release-tag: http://git.io/Hzq0sA 00:52 <SakaiGithub> [3akai-ux/org.sakaiproject.nakamura.uxloader-1.4.0] [maven-release-plugin] prepare release 1.4.0-release-tag - Anthony Whyte 02:35 <GitHub170> [nakamura] arwhyte pushed 1 new commit to 1.4.0-release-a: http://git.io/6LdcOg 03:40 <GitHub66> [nakamura/1.4.0-release-tag] release_pre_process: Moving config files from 1.4.0-SNAPSHOT to 1.4.0 - Anthony Whyte 03:40 <GitHub190> [nakamura] arwhyte tagged org.sakaiproject.nakamura-1.4.0 at 1.4.0-release-tag: http://git.io/h4dFAQ 14:44 <lancespeelmon> mrvisser: let me know when you want to talk EC2 cluster 14:50 <MrVisser> lancespeelmon: is right now good for you? 14:50 <lancespeelmon> yes 14:51 <MrVisser> cool, I'll ring you up in skype 15:12 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-181 - Update to rails 3.2.6 and ruby 1.9.3-p194 - Christian Vuerings 15:12 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-181 - Add ruby debug back in - Christian Vuerings 15:28 <MrVisser> froese: assuming I haven't destroyed the puppet config, is rm -Rf /usr/local/sakaioae on an app server, then executing puppet a valid move to make? 15:33 <froese> mrvisser, yes sir 15:33 <MrVisser> froese: good cause I already did it :) looks good. I actually mv'd it somewhere for safe keeping, but looks like I can delete the backup. 15:34 <froese> nice 15:35 <MrVisser> froese: lots of these: 27.07.2012 08:33:06.556 *ERROR* [FelixStartLevel] org.apache.felix.configadmin Service [org.apache.felix.cm.ConfigurationAdmin,46] Persisting new bundle location failed (java.io.IOException: Permission denied) java.io.IOException: Permission denied 15:35 <MrVisser> are they normal? 15:37 <froese> yea thats because we lock the config files by default 15:37 <froese> so sling tries to write the bundleLocation line in there and it cant 15:37 <froese> it should be a WARN and not an error but whatever. 15:37 <froese> But it does mean you can't edit the configs in the web console if the file is locked 15:39 <froese> if you want to unlock it add locked => false to the oae::app::server::sling_config resources 15:44 <MrVisser> got it, thanks! 15:55 <SakaiGithub> [sakai-widgetlibrary] christianv pushed 2 new commits to master: http://git.io/8TkrDw 15:55 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-181 Add rvm-capistrano - Bert Pareyn 15:55 <SakaiGithub> [sakai-widgetlibrary/master] Merge remote-tracking branch 'origin/master' into OAEWDGT-181 - Bert Pareyn 16:01 <GitHub106> [nakamura] ctweney pushed 3 new commits to master: http://git.io/-TusZw 16:01 <GitHub106> [nakamura/master] Merge commit '83c29afa24b3386bed87e5f24343dc7df17143c1' into check140merges2 - Lance Speelmon 16:01 <GitHub106> [nakamura/master] Merge remote-tracking branch 'sakai/master' into check140merges2 - Lance Speelmon 16:01 <GitHub106> [nakamura/master] Merge pull request #941 from lancespeelmon/check140merges2 - Chris Tweney 16:07 <SakaiGithub> [sakai-widgetlibrary] christianv force-pushed master from d41526a to a0a59df: http://git.io/fvYbpw 16:07 <SakaiGithub> [sakai-widgetlibrary/master] Revert "OAEWDGT-181 Add rvm-capistrano" - Christian Vuerings 16:18 <froese> Can someone help e with a ruby question? 16:19 <froese> Ruby bombs on this line https://github.com/sakaiproject/nakamura-ruby/blob/master/lib/nakamura.rb#L179 16:19 <SakaiGithub> [sakai-widgetlibrary] christianv pushed 1 new commit to master: http://git.io/yCHkow 16:19 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-181 - use rvm-capistrano and set the rvm_type - Christian Vuerings 16:19 <froese> #{@serveruri.host} can't be interpolated correctly. But removing the brackets fixes it. 16:21 <froese> ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux] 16:37 <SakaiGithub> [sakai-widgetlibrary] christianv pushed 1 new commit to master: http://git.io/hwmjBg 16:37 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-181 - fix devise gem - try 1 - Christian Vuerings 16:40 <SakaiGithub> [sakai-widgetlibrary] christianv pushed 1 new commit to master: http://git.io/jvtzNw 16:40 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-181 - Fix devise error - try 2 - Christian Vuerings 16:42 <SakaiGithub> [sakai-widgetlibrary] christianv pushed 1 new commit to master: http://git.io/fQE9hg 16:42 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-181 - Add the gemfile.lock - Christian Vuerings 17:09 <thecarlhall> zacht, raydavis, we should probably get together some time about Duffy's 2 big PRs sitting out there. 17:09 <thecarlhall> at least one still has some work to be done, I think. 17:09 <zacht> he's back on Monday, right? 17:10 <raydavis> thecarlhall, I think the others may be obsolete. 17:10 <raydavis> And yes, there are some important things to talk through on the newer one. 17:11 <thecarlhall> raydavis, which ones are "the others"? 17:11 <thecarlhall> We can get together next week some time and figure things out. 17:13 <raydavis> thecarlhall, 831 (two months old) and 841 (one month old) 17:13 <thecarlhall> gotcha, thanks 17:45 <ctweney> zacht, your cobertura video is awesome 17:45 <zacht> ctweney Hold tight, I've improved everything. 17:45 <ctweney> can you share the pom.xml changes somewhere? 17:46 <zacht> ctweney Pull request imminent. 17:46 <ctweney> sweet 17:46 <ctweney> zacht also I envy your clicky mechanical keyboard 17:46 <zacht> ctweney I found a way to make the cobertura embed optional. 17:46 <zacht> ctweney So we can have a normal build unless we want a "special" one. 17:47 <ctweney> oh, awesome 17:47 <zacht> ctweney One of the luxuries of renting my own office is that I won't get murdered for using mechanical key switches. 17:47 <ctweney> so we can ship our code with those embeds, but just disabled? 17:47 <ctweney> zacht: I wish somebody would make a good ergo split adjustable keyboard with mechanical switches… sadly that's a chimera yet to be produced 17:48 <raydavis> I compensate by slamming the keys harder. 17:54 <stuartf> ctweney: I think thecarlhall was looking for a kb like that too, maybe you guys should make a kickstarter 17:55 <ctweney> funny you should say that stuartf, I was just googling and somebody posted just that idea on ycombinator 17:55 <ctweney> what I want is my goldtouch split but with mechanical keys 17:55 <stuartf> also, there was a model m15 http://www.shoppalstores.com/ibmmodelm/image//13h6689002.jpg 17:56 <stuartf> they're "ultra-rare" though 17:56 <thecarlhall> I found a split kb with mechanical keys but the wife would never go it in our shared office 17:56 <thecarlhall> and it was a bit spendy 17:59 <stuartf> I don't think I've seen a mechanical kb for less than $70 18:00 <thecarlhall> yeah 18:01 <ctweney> what I really really really want is one of these (but split, ergo, etc) http://www.datamancer.net/keyboards/keyboards.htm 18:03 <stuartf> I don't know if I'd like typing on those round typewriter keys 18:03 <thecarlhall> or $1300 http://www.datahand.com/ 18:05 <thecarlhall> those DataMancer kbs look awesome 18:07 <stuartf> lol, DAS sells earplugs as an accessory for their mechanical keyboards 18:08 <stuartf> or they did at one time, it looks like the link 404s now 18:09 <thecarlhall> hahah, nice 18:09 <thecarlhall> the KeyOvation keyboard is a retelling of the split IBM M (sans buckling spring) 18:09 <thecarlhall> http://www.thehumansolution.com/keyovation.html 18:11 <thecarlhall> anybody try a non-qwerty layout? I've been debating colemak for a while 18:12 <stuartf> I'm not a good enough typist on qwerty to consider learning another layout 18:15 <ctweney> that goldtouch (sans smart card) is what I use 18:15 <ctweney> great keyboard, but not clicky 18:17 <thecarlhall> ctweney, I may try that. I've been through several MS ergo keyboards over the years. 18:17 <thecarlhall> ctweney, I usually go through a keyboard every year or 2 18:41 <MrVisser> froese, that archive puppet type.. I'm trying to get it to download http://www.yourkit.com/download/yjp-11.0.8-linux.tar.bz2 but it's just-a-hangin' (2min timeout) then failing.. any advice with this thing? 18:42 <MrVisser> froese: I PM'd you the puppet def. 18:42 <froese> can you download it on the command line? 18:42 <MrVisser> yea, curl <…> >yjp.tar.bz2 works just fine 18:43 <froese> I think the name of the resource (the first string after the open bracket) should be yjp-11.0.8-linux 18:43 <MrVisser> trying 18:44 <MrVisser> doesn't look like it's working: 18:44 <MrVisser> notice: Scope(Archive::Download[yjp-11.0.8-linux.tar.bz2]): No checksum for this archive 18:44 <MrVisser> info: Applying configuration version '1343414645' 18:44 <MrVisser> then just hangs. 18:46 <zacht> ctweney cobertura-fu: https://github.com/sakaiproject/nakamura/pull/942 18:46 <zacht> ctweney and screencast part II: http://screencast.com/t/7Y5XTkM3iV 18:46 <froese> try the --debug flag 18:47 <zacht> ctweney I think it's going to work wonders for better integration testing. 18:47 <froese> mrvisser, see what that says, the checksum message will go away if you manually dl the file and md5 it, then add checksum => 'bleepbloop' 18:48 <MrVisser> oh I set checksum = false 18:52 <MrVisser> froese: the timeout doesn't include the download time, right? like if timeout is 2min, and it takes 4min to download, that should still work.. right? 18:52 <froese> i believe it only applies TO the download. 18:52 <froese> i think it will produce the warning message even when checksum => false 18:53 <MrVisser> froese: when you say it applies to the download, do you mean the time it takes to connect and start downloading, or the time it takes to complete the entire download ? 18:53 <froese> ahh dude i have no idea 18:54 <MrVisser> froese: alright, I'm going to disable timeout and wait it out. thanks for trying :) 18:54 <froese> I think it applies to the time it takes curl to exit successfully 18:55 <froese> yep, the entire curl command and checksum 18:55 <froese> https://github.com/efroese/puppet-archive/blob/master/manifests/download.pp#L80 18:57 <MrVisser> ahh, that's what that means. Thanks man, makes sense now. 19:03 <thecarlhall> zacht, what does cobertura in the server add/do differently than cobertura during the build? 19:05 <zacht> thecarlhall during the build, it measures coverage of your unit tests. In the server, it measures coverage of your integration tests. 19:05 <zacht> thecarlhall You can also measure coverage of functional tests. Or coverage of, say, a bug bash. 19:06 <thecarlhall> zacht, so in the server you can see how much of your code gets used after doing some operations? 19:06 <zacht> thecarlhall right. 19:06 <thecarlhall> which I guess is all it really tests during the build (what is used by the unit tests) 19:07 <zacht> yep. 19:07 <stuartf> do you actually have that working? 19:07 <thecarlhall> stuartf, http://screencast.com/t/7Y5XTkM3iV 19:08 <zacht> stuartf yes, but with a limitation: it currently only supports getting data out of one bundle at a time. 19:08 <denbuzze> zacht: ever saw this error when trying the webstart? - http://cl.ly/INH4 19:09 <zacht> stuartf Which is ok for what Chris and I are doing right now, which is focused on specific bundles. 19:09 <zacht> denbuzze No. 19:09 <zacht> denbuzze What version of OS X is that? 19:09 <stuartf> I did a bunch of stuff to have it build separate instrumented bundles and transform list.xml so you could have a launchpad that used them 19:10 <denbuzze> zacht: 10.7.4 (didn't update to mountain lion yet) 19:10 <zacht> stuartf I remember. I took a branch off of that and did some more work on it. 19:10 <denbuzze> zacht: just tried http://source.sakaiproject.org/release/oae/1.3.0/webstart/sakaioae.jnlp 19:11 <zacht> stuartf The instrumentation worked, but I could never get it to output its coverage data. 19:11 <zacht> denbuzze I'll try it now. 19:12 <stuartf> yeah, I think a lot of where I got stuck was around getting out the coverage info 19:12 <thecarlhall> zacht, why does it work only 1 bundle at a time? 19:12 <thecarlhall> zacht, couldn't you use a bundle listener to have it work on several/all? 19:13 <zacht> thecarlhall There's no limitation on how many bundles are instrumented. 19:13 <stuartf> also, I was using emma 19:13 <zacht> thecarlhall The tricky part is getting it to flush its data. 19:14 <thecarlhall> zacht, do you have to embed cobertura into ever bundle to be tested? 19:14 <zacht> thecarlhall It uses a system property to know where the data file is, so that is one destination system-wide. 19:14 <zacht> thecarlhall If we bundle-ized the cobertura jar, we wouldn't have to embed. 19:15 <thecarlhall> zacht, I'd rather do that than embed it every time 19:15 <zacht> thecarlhall That would be better. 19:15 <stuartf> zacht: pom.xml in https://github.com/stuartf/nakamura/commit/3344eae1e78b9bac569683b08226eba6aedf1134 is of particular interest 19:17 <stuartf> particularly the emma-bundle execution 19:18 <stuartf> and this has my xslt for building a launchpad out of the instrumented bundles https://github.com/stuartf/nakamura/commit/722571e2ce10f7a3b6984607d497cf5dbe3cf35a 19:19 <zacht> stuartf Is that adding the <classifier>emma</classifier> for list.xml? 19:20 <zacht> stuartf For the cobertura version, I don't think list.xml has to be changed. It uses the same bundles as before, they just happen to be instrumented. 19:24 <stuartf> zacht: right, the pom from the fisrt commit I linked adds the emma classifier and the xslt builds a list.xml that uses bundles that have the emma classifier 19:24 <stuartf> that way there's no risk of running an instrumented bundle that you think is uninstrumented 19:26 <stuartf> also, you don't have to run a special profile, whenever you build you get your instrumented bundles right along side the uninstrumented ones 19:27 <thecarlhall> zacht, did you find that listing the "don't import these" after the "import these" worked okay? We've seen problems with that order before 19:27 <zacht> denbuzze I get something similar, but not exactly the same: http://cl.ly/IMVQ 19:28 <zacht> thecarlhall The bundles seemed to be satisfied. What would the symptom be? 19:28 <thecarlhall> zacht, it ignores the !imports 19:29 <zacht> thecarlhall Those are in there because of the dependencies cobertura has (which we won't use). 19:29 <zacht> thecarlhall So without them, the bundle doesn't resolve. And with them, everything seems to be happy. 19:30 <thecarlhall> zacht, sounds like it works then. nice! 19:30 <thecarlhall> zacht, I don't know what caused it before but we had to put the !imports first or it would ignore them 19:30 <zacht> thecarlhall Do you mean that I sould put * first, and then the exclusions? 19:31 <zacht> thecarlhall oh, I see. 19:31 <thecarlhall> exclusion, inclusions, * 19:31 <thecarlhall> but sounds like that order isn't important any more 19:31 <thecarlhall> might've been a bnd thing 19:31 <denbuzze> zacht: ouch - you know the reason why this is happening? 19:32 <zacht> denbuzze I assume it's some kind of OS X security restriction. 19:32 <zacht> denbuzze I'm on Mountain Lion. You should find some Java security preferences in the Java Preferences app. 19:33 <zacht> denbuzze I haven't found anything yet that looks like the cause. 19:37 <stuartf> denbuzze, zacht: http://stackoverflow.com/questions/11136805/java-applet-with-self-signed-certificate-on-os-x-mountain-lion 19:38 <denbuzze> stuartf: thanks! 19:39 <stuartf> np 19:40 <zacht> stuartf++ 19:40 <zacht> denbuzze That worked for me. 19:41 <zacht> denbuzze Those instructions are for Mountain Lion, though. 19:49 <zacht> ACTION needs food. 19:49 <denbuzze> zacht stuartf: any of you guys know how to set the FSResource settings through a Curl command (this is a challenge ;) ) - or would you recommend using config files in /load? (This is for front-end devs/designers trying to get up to speed with 3akai-ux dev asap without a ruby/rvm dependency) 19:53 <stuartf> denbuzze: yep 19:54 <stuartf> denbuzze: curl -u admin:admin -F "[email protected]" -F config.json@TypeHint="nt:file" http://localhost:8080/devwidgets/mysakai2 19:55 <stuartf> denbuzze: er wait, that's how to post a widget config 19:55 <denbuzze> stuartf: but that requires a file, no? It's for setting /dev /devwidgets 19:55 <denbuzze> stuartf: so probably a POST to http://localhost:8080/system/console/configMgr/ 19:55 <stuartf> denbuzze: yeah, that was the wrong one 19:56 <stuartf> I don't think I've done configMgr through curl, but it should be possible because I've done it in ruby 19:56 <denbuzze> stuartf: yeah, I was peaking at the OAE-Builder 19:57 <stuartf> https://github.com/stuartf/nakamura-ruby/blob/master/lib/nakamura/osgiconf.rb 19:57 <stuartf> that's the call OAE-Builder uses 19:58 <denbuzze> stuartf: so the factoryPid would be "org.apache.sling.fsprovider.internal.FsResourceProvider" ? 19:58 <stuartf> yes 20:49 <raydavis> mrvisser1, zacht, I just entered a pull request that reverts a commit by you: KERN-3067 20:50 <raydavis> Let me know if I missed anything, OK? 20:56 <mrvisser1> raydavis: out of curiosity, what was the failure in the sparse querying system? things like method-signature incompatibilities? 20:57 <raydavis> mrvisser1 KERN-3066 20:57 <raydavis> A class variable was added in Lucene 4. 20:59 <mrvisser1> ah. I was under the impression when I made the change that there were no references to that sparse querying system anymore. Guess I was wrong.. sorry! 20:59 <raydavis> mrvissrr1, the sparse querying system is where the problem became apparent for me. The class version discrepancy would be a critical problem even if sparse querying was wiped entirely. 21:00 <raydavis> mrvisser1 ^^ 21:00 <mrvisser1> raydavis: the problem with having an unreleased version of lucene exported to the container was that it didn't work with anything else that required lucene. With infinispan that was a problem, but if it is off the table I guess it's not important in the medium-term future. 21:00 <raydavis> We can't tell bundles to build against a later version of Lucene & then get an earlier version at runtime. 21:02 <raydavis> mrvisser1, as you wrote in your comment on the original ticket, we don't have that flexibility. Any code that requires Lucene should be using the Lucene that is used at compile time. 21:02 <raydavis> search/impl compile time got its classes from solr, search/impl rutnime got its classes from 3.5.0 21:03 <raydavis> See the issue? 21:03 <mrvisser1> raydavis: The idea would be that bundles would not actually build against 4.0, they would import and build against 3.5 and not depend on the transitive dependencies of the solr bundle to get its lucene version. I think I verified that the sparsemap query system wasn't actually passing its lucene references into the solr bundle.. one sec. 21:04 <raydavis> mrvisser1, again: if you look at the search/impl/pom.xml you will see that Lucene dependencies are coming in at compile-time from the solr bundle. 21:04 <raydavis> That is why the Sparse query code is able to compile! 21:05 <mrvisser1> raydavis: absolutely :) one sec, checking some code 21:05 <raydavis> At any rate, we have Nakamura code that DOES assume Solr 4 classes, and therefore it also needs to assume Lucene 4 classes. 21:06 <raydavis> So (as I tried not very well to indicate in my JIRA comment), we should NOT be building against 3.5.0. 21:08 <raydavis> Mm, that exclamation mark up there makes me think I could use a vacation. :) 21:08 <mrvisser1> raydavis: I have no problems reverting that fix, it should be fine, pragmatically speaking. 21:09 <mrvisser1> by "fix", I mean "change", I suppose. 21:09 <raydavis> mrvisser1, cool, thanks, and sorry for my heat. I guess I'm feeling a bit under the gun, too. 21:11 <mrvisser1> raydavis: my investigation before suggests that the SparseResultSetFactory is the only place that actually references Lucene classes, and none of those Lucene classes are actually passed back into the Solr bundle. I think it would actually be possible to change that Version.LUCENE_40 to Version.LUCENE_35, and we could be just fine. That SparseResultSetFactory class is only using the Lucene lexer, it's not querying. 21:11 <raydavis> mrvisser1, I disagree that we would be just fine. 21:11 <raydavis> Unless you want to personally inspect every reference to an org.lucene class that gets checked in. 21:12 <mrvisser1> raydavis: I already did as part of my previous investigation. There are no other references to org.lucene.* in our code base. 21:12 <mrvisser1> the Solr bundle complete bubbles its use of lucene 4.0 21:12 <raydavis> mrvisser1, people continue to develop code. 21:13 <raydavis> What problem are you trying to solve? 21:13 <raydavis> What purpose is served by having Nakamura use 3.5.0 in some bundles and 4.0 in others? 21:14 <mrvisser1> raydavis: the problem is moot now. But the problem is that exporting an unreleased version of lucene to the container ensures that you won't be able to run anything else that depends on an actual version of lucene. 21:14 <raydavis> mrvisser1, we are assured of that anyway. 21:15 <raydavis> Again, we have code that depends on Solr 4, and Solr 4 depends on Lucene 4.0. They are the same source code tree. 21:15 <MrVisser> sorry ray, my internet is a little finnicky right now.. 21:16 <MrVisser> I missed anything you may have said after my last message as mrvisser1 21:16 <raydavis> "we have code that depends on Solr 4, and Solr 4 depends on Lucene 4.0. They are the same source code tree." 21:17 <MrVisser> raydavis: right. so, the solr bundle actually doesn't require that any other bundles actually muck with Lucene. It doesn't have to export it. It can just "enclose" lucene 4.0, and other bundles don't have to know anything about lucene 4.0. 21:18 <raydavis> mrvisser, that will only work if you forbid Java developers from referring to org.lucene. But why do you want to do that if you're allowing developers to refer to org.solr, which builds on Lucene? 21:18 <raydavis> What is the reward here? 21:19 <MrVisser> raydavis: those developers should be using the 3.5 dependency. The reward was that we could install another bundle that depends on a real version of lucene. 21:20 <raydavis> mrvisser, those developers should not & cannot use the 3.5 dependency. Our Solr/Lucene 4.0 version is the only real version in play. 21:20 <raydavis> I know it's uncomfortable to depend on a Sakai-specific snapshot, that's why I'm trying to finish the upgrade. 21:21 <MrVisser> raydavis: I think we'll have to agree to disagree on that one. But I +1 reverting none-the-less since it has broken things. Sorry for the trouble! 21:25 <raydavis> mrvisser, on a related but less disagreeable topic, thecarlhall and I are both wondering if we might someday find a way to avoid the embedded-Solr fuss altogether and just let the Solr server do all its Solr-server goodness itself. That would at least cut down on how many dependencies get shoved into nakamura/bundles/solr/pom.xml 21:27 <raydavis> Then we could just bundle up the Solr/Lucene client JARs as needed. 21:27 <MrVisser> raydavis: that would be interesting. and would certainly force better attention towards support for real production environments 21:52 <ctweney> zacht: I'm trying to follow your cobertura-fu and am having some problems. 21:53 <zacht> ctweney wassup? 21:53 <ctweney> zacht: I ran the instrumentation step and have a cobertura.ser file in target/cobertura… 21:53 <zacht> ok. 21:53 <ctweney> …but it never gets written to when I use the files bundle 21:54 <ctweney> here's how I launched nakamura; nohup java -Dfile.encoding=UTF8 -Xmx512m -XX:MaxPermSize=256m -server -Xdebug -Xrunjdwp:transport=dt_socket,address=9001,server=y,suspend=n -Dcom.sun.management.jmxremote -jar app/target/org.sakaiproject.nakamura.app-1.5.0-SNAPSHOT.jar -Dnet.sourceforge.cobertura.datafile=/Users/chris/dev/review/nakamura/bundles/files/impl/target/cobertura/cobertura.ser > sling/logs/stdout.log 2>&1 & 21:55 <zacht> ctweney When you refresh or otherwise stop the bundle, do you have this message in your log? "stopping bundle, writing code coverage data" 21:57 <zacht> ctweney Another thing to check is open the bundle in the console, and you should see: Bundle Classpath .,cobertura-1.9.4.1.jar 21:57 <ctweney> aha, files.impl bundle says net.sourceforge.cobertura.coveragedata -- Cannot be resolved 21:59 <zacht> ctweney Strange that I don't get that. So there's no mention of the cobertura jar in Bundle Classpath? 21:59 <zacht> ctweney That would mean that it's not being embedded. 22:00 <ctweney> oh now I've got it zacht, it works after I started the server and then redeployed the bundle with mvn clean install -P cobertura-instrument,cobertura-embed,redeploy $ST 22:01 <zacht> ctweney ok, cool! 22:05 <thecarlhall> zacht, what do you think of creating a cobertura bundle instead of embedding it? 22:06 <ctweney> zacht: despite the datafile argument on the java cmd line, cobertura wrote its .ser file out to the nakamura root folder 22:07 <thecarlhall> zacht, yes sir. Do you want me to add that to your PR or toss another PR out there? 22:07 <thecarlhall> zacht, I'm still really interested in removing cobertura stuff from the activator and having a generic bundle listener to do that work. 22:07 <thecarlhall> zacht, maybe a manifest header could identify a bundle that has been instrumented and it can act from there somehow. 22:08 <ctweney> strange, zacht, my report shows 100% coverage on everything 22:08 <ctweney> which seems optimistic 22:09 <zacht> thecarlhall That sounds great. You may run up against limitations of the Cobertura API, though. e.g. ProjectData.saveGlobalProjectData() probably only works on the classloader it's called from. 22:10 <zacht> ctweney That is what happens when you run a report on a cobertura.ser file that is not the same as the one that was produced during instrumentation. 22:10 <ctweney> aha 22:11 <zacht> ctweney from one of the docs: "The cobertura ser file produced when the classes within a given jar are instrumented record the number of executable lines within the jar along with various other meta-data. The cobertura ser file created (or modifications thereof) when the deployment artifact is executed only records information related to the lines of code which were executed. Consequently, a coverage report created using only the cobertura 22:11 <zacht> created by the execution of the deployment artifact will falsely report 100% coverage. 22:11 <zacht> This can take a few seconds to wrap your mind around. The trick is to understand that since the cobertura ser file created by the deployment artifact only records lines which were executed, a report based on such a ser file observes that 100% of what the ser file knows about has been covered." 22:12 <zacht> ctweney I see what's wrong. 22:13 <zacht> ctweney Your java system property needs to come _before_ -jar 22:14 <zacht> ctweney everything after nakamura.app-1.5.0-SNAPSHOT.jar is treated as an argument to the nakamura main method. 22:29 <thecarlhall> zacht, osgi doesn't seem to find the cobertura embedded dep after a build 22:29 <thecarlhall> Unresolved constraint in bundle org.sakaiproject.nakamura.user.impl [34]: Unable to resolve 34.0: missing requirement [34.0] package; (package=net.sourceforge.cobertura.coveragedata) 22:29 <thecarlhall> same for files.impl 22:30 <zacht> thecarlhall That sounds like the same thing ctweney encountered. He said it started working after a redeploy. 22:31 <thecarlhall> zacht, what about for first time starters though? this blocks the merge 22:32 <zacht> thecarlhall I think if cobertura were in its own bundle, we wouldn't run into that. 22:32 <thecarlhall> zacht, I'll create that bundle now to find out. Seems like it should find it since it is embedded but it may need more directives for that 22:33 <zacht> thecarlhall The only downside is that we either include the cobertura bundle in list.xml (meaning it's always there) or people have to modify list.xml to use the bundle. 22:33 <zacht> thecarlhall What does the bundle show for Bundle Classpath? 22:33 <zacht> thecarlhall in the console, I mean. 22:34 <thecarlhall> zacht, I don't see a classpath in the manifest 22:34 <thecarlhall> hang on, wrong machine 22:35 <zacht> thecarlhall If there's no cobertura.jar it means embedding never happened. 22:35 <thecarlhall> zacht, right and I don't see a classpath or embedded cobertura.jar 22:36 <thecarlhall> zacht, very weird. my code doesn't match yours though I pulled directly from the PR 22:36 <zacht> :`-( 22:37 <thecarlhall> pulling again 22:38 <thecarlhall> same effect after clearing and pulling again 22:38 <thecarlhall> user/impl/pom.xml is missing the additions 22:39 <thecarlhall> oh! 22:39 <thecarlhall> special profile 22:40 <thecarlhall> so, user/impl wants cobertura because of the activator but it doesn't get embedded until the special profile is used to build user/impl 22:41 <thecarlhall> zacht, bnd will see the use of cobertura and add it to the manifest 22:42 <zacht> thecarlhall I see. ok, that puts a damper on things. 22:42 <thecarlhall> zacht, I like having the instrumentation separated out like that but we should investigate how to do a build profile that does the extra stuff AND have a normal build that excludes the extra stuff safely 22:43 <zacht> thecarlhall That's what this is supposed to do. 22:43 <zacht> I just didn't get it right. 22:44 <thecarlhall> zacht, I think we can do this with a bundle listener + manifest header for instrumentation 22:45 <zacht> thecarlhall If we have a cobertura bundle, we can just use an ordinary dependency to it. 22:45 <zacht> thecarlhall I like the bundle listener idea, too. 22:45 <thecarlhall> we still have to handle what's going on in the activator which is where the listener comes in 22:45 <zacht> Gotta run. Have a good weekend. 22:45 <thecarlhall> later! 23:00 <ctweney> hey thecarlhall, I noticed in 1.5.0 that the sling console is missing the Components and Services tabs 23:05 <thecarlhall> ctweney, not by design. those shouldn't be gone 23:06 <thecarlhall> but now I see the same 23:06 <thecarlhall> I wonder if they split more stuff out of webconsole 23:06 <thecarlhall> ugh, I think I found it. 23:06 <thecarlhall> I'll test and submit a PR for it 23:07 <thecarlhall> in the meanwhile, try this: http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.webconsole.plugins.ds/1.0.0/org.apache.felix.webconsole.plugins.ds-1.0.0.jar 23:07 <thecarlhall> looks like obr is gone too 23:15 <thecarlhall> ctweney, yep, that adds those back. I'll JIRA it 23:15 <ctweney> you rawk thecarlhall++ 23:15 <thecarlhall> well, I kinda created that problem, too, but thankfully it was an easy fix 23:38 <SakaiGithub> [sakai-widgetlibrary] christianv pushed 3 new commits to master: http://git.io/hQqq3Q 23:38 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-168 added in page tabs - jsloane 23:38 <SakaiGithub> [sakai-widgetlibrary/master] OAEWDGT-168 added in page tabs - jsloane 23:38 <SakaiGithub> [sakai-widgetlibrary/master] Merge remote-tracking branch 'jsloane/OAEWDGT-168' into jsloane-OAEWDGT-168 - Christian Vuerings _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
