Timestamps are in GMT/BST.
[0:29] * peterdietz_ (uid52203@gateway/web/irccloud.com/x-ozywefjepctdcxdv) has joined #duraspace
[0:36] * peterdietz (uid52203@gateway/web/irccloud.com/x-atlruwurhqsmeofq) Quit (*.net *.split)
[0:36] * peterdietz_ is now known as peterdietz
[1:06] * peterdietz (uid52203@gateway/web/irccloud.com/x-ozywefjepctdcxdv) Quit (Quit: Connection closed for inactivity)
[6:27] -hobana.freenode.net- *** Looking up your hostname...
[6:27] -hobana.freenode.net- *** Checking Ident
[6:27] -hobana.freenode.net- *** Found your hostname
[6:27] -hobana.freenode.net- *** No Ident response
[6:27] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:27] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:27] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:28] * cknowles (uid98028@gateway/web/irccloud.com/x-foduzvunhmxwgcit) has joined #duraspace
[9:33] * cknowles (uid98028@gateway/web/irccloud.com/x-foduzvunhmxwgcit) Quit (Quit: Connection closed for inactivity)
[9:43] * cknowles (uid98028@gateway/web/irccloud.com/x-nzlgfoouwaveennp) has joined #duraspace
[12:25] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:13] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has joined #duraspace
[13:43] * cknowles (uid98028@gateway/web/irccloud.com/x-nzlgfoouwaveennp) Quit (Quit: Connection closed for inactivity)
[14:28] * peterdietz (uid52203@gateway/web/irccloud.com/x-uxoevnzhfrwelgwx) has joined #duraspace
[14:31] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[14:42] * kdweeks (~Adium@2001:468:c80:a103:f1b0:847b:b2cd:54b5) has joined #duraspace
[14:51] * kdweeks (~Adium@2001:468:c80:a103:f1b0:847b:b2cd:54b5) Quit (Quit: Leaving.)
[14:51] * cknowles (uid98028@gateway/web/irccloud.com/x-vhjiqiavjxbkubjv) has joined #duraspace
[14:58] * terry-b (~terry-b@71-212-24-25.tukw.qwest.net) has joined #duraspace
[17:53] * cknowles (uid98028@gateway/web/irccloud.com/x-vhjiqiavjxbkubjv) Quit (Quit: Connection closed for inactivity)
[19:08] * cknowles (uid98028@gateway/web/irccloud.com/x-autwgscimyglkdmp) has joined #duraspace
[19:14] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[19:48] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[19:52] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hello all, welcome to our weekly DSpace DevMtg. The agenda for today is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-09-16
[20:00] <kompewter> [ DevMtg 2015-09-16 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-09-16
[20:01] <tdonohue> As in recent weeks, we'll first begin with updates on the Service API refactor. As of this morning, it looks like we still have work to do on both REST API and JSPUI.
[20:02] <tdonohue> For the JSPUI, as I noted on dspace-devel, I did split out a list of all subfolders so that individuals can claim them & we can check them off when completed. That list is at the top of this wiki page: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:02] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:03] <KevinVdV> Well I can prob get the jsp’s to compile by next week ….. but I don’t want to keep pushing stuff on my own.
[20:03] <tdonohue> I also would like to add a sidenote that as of this morning, 'vagrant-dspace' is now fully compatible with the Service API refactor. This means that it can be used as a testing/development tool. https://github.com/DSpace/vagrant-dspace
[20:03] <kompewter> [ DSpace/vagrant-dspace · GitHub ] - https://github.com/DSpace/vagrant-dspace
[20:04] <tdonohue> I'll admit, I was hampered this week when I found vagrant-dspace didn't work with the Service API (and I use vagrant-dspace frequently)...and I've been fixing it so that I can chip in more directly (and others can help *test* more easily)
[20:05] <tdonohue> KevinVdV: You've done an amazing amount of work here. I'm hoping to be more useful this week as well. But, if you have time to help keep chipping away, you are still more than welcome to (but I hate to make this all rely on you...we need more helpers)
[20:05] <mhwood> To claim a folder, just edit the list and add my name next to it, right?
[20:05] <KevinVdV> Well the last couple of days I was busy finishing the xml workflow migration (which I finished today, so I will have time for the JSPUI)
[20:06] <tdonohue> peterdietz: any updates on the REST API status? Is that something you are working on
[20:06] <tdonohue> mhwood: yep, the same as before. Just add your name next to a folder if you'll do it. Some folders may already be partially complete (and I've yet to verify *which* ones as I wasn't able to fully test in vagrant-dspace)
[20:06] <KevinVdV> Ps: on the jsp status, starting up intellij to see which folders I already fixed
[20:07] <peterdietz> yeah. Sorry to be a bottle neck. I've been making improvements to it. I have been doing integration testing using BrunoNZ (Brazil), he had some bash scripts that create, edit, update, delete content, and it fails mid-way. Just weird context related errors
[20:07] <KevinVdV> So I will claim those but leave the checkbox open
[20:07] <tdonohue> peterdietz: any timelines? We need something that compiles...currently everything actually "compiles" except REST :)
[20:07] <peterdietz> I've focused at work on build spring-security-saml integration (for Shibboleth / ADFS to work native in DSpace), but have done some time on REST
[20:08] <tdonohue> (so those testing are forced to do "-P -dspace-rest" and turn off the REST API to actually get a successful build of Services API)
[20:08] <peterdietz> I can make the fixes mentioned in the PR, and follow with improvements
[20:08] <mhwood> Box can be checked as soon as 'mvn clean package' succeeds, no?
[20:08] <tdonohue> peterdietz: please do make the immediate fixes ASAP. There's plenty of time for improvements (even post merger to "master")
[20:09] <KevinVdV> Well I don’t think anybody expects a single person to test an entire web application
[20:10] <KevinVdV> (Or so I hope)
[20:11] <tdonohue> KevinVdV: definitely not. The goal right now is to get everything to *compile* and ensure that XMLUI & JSPUI are "minimally functional" (i.e. don't immediately break). More detailed testing can be done later on, and no one individual will be expected to fully test a webapp
[20:11] <tdonohue> Essentially, I'd just like us to have a codebase that "seems to be working well enough"... and we can then do more detailed testing to fix the minor bugs/issues that have popped up.
[20:13] <tdonohue> Are there any other updates to share on Services API work?
[20:13] <peterdietz> KevinVdV: what is wrong with removing dspaceobject.update() ? https://github.com/DSpace/DSpace/pull/1026#discussion_r39141648
[20:13] <kompewter> [ [DS-2701] REST API by peterdietz · Pull Request #1026 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1026#discussion_r39141648
[20:13] <peterdietz> Doesn't service make a commit as the action happens?
[20:13] <tdonohue> Oh, and I did notice this one other PR (for RDF cleanup) sitting around: DSPR#1040 (probably should get in sometime soonish)
[20:14] <kompewter> [ https://github.com/DSpace/DSpace/pull/1040 ] - DS-2701: cleanup or org.dspace.rdf by pnbecker
[20:14] <mhwood> I would like to suggest: if you see a good way to capture your testing as a mechanical approach, please write it down. We need to create functional tests so that people don't have to create this stuff over and over manually.
[20:14] <KevinVdV> The update triggers the actions, https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/CollectionServiceImpl.java#L573
[20:14] <kompewter> [ DSpace/CollectionServiceImpl.java at DS-2701-service-api · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/CollectionServiceImpl.java#L573
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:14] <KevinVdV> Actions == events
[20:14] <KevinVdV> Which are then processed on context.commit to reindex if needed
[20:16] <tdonohue> Any other questions/concerns regarding Services API stuff? We can take as much time as we need today on this...(as it is highest priority by far)
[20:17] <mhwood> So what is blocking the merge?
[20:17] <KevinVdV> The jsp files & the rest api
[20:17] <tdonohue> mhwood: REST API doesn't compile
[20:18] <tdonohue> And JSP files are broken (while JSPUI compiles, it throws immediate errors if you bring it up)
[20:18] <KevinVdV> Please claim the jsp file folders & those not claimed after the weekend I will TRY to fix for next week.
[20:18] <KevinVdV> So that we can finish the JSPUI next week before/during the meeting
[20:18] <mhwood> So, any JSP throwing errors is a blocker?
[20:19] <tdonohue> mhwood: It'd be nice to get JSPUI "minimally functional". I'm not saying it needs to be 100% perfect. But, we should be able to do common tasks...it shouldn't explode :)
[20:20] <KevinVdV> http://stackoverflow.com/questions/12960926/is-there-a-way-to-compile-all-jsp-files-in-intellij-idea
[20:20] <kompewter> [ java - Is there a way to compile all JSP files in IntelliJ IDEA? - Stack Overflow ] - http://stackoverflow.com/questions/12960926/is-there-a-way-to-compile-all-jsp-files-in-intellij-idea
[20:20] <mhwood> Given the nature of the beast, that could take some time. The tools don't help nearly as much with embedded Java.
[20:20] <tdonohue> So, with regards to both XMLUI and JSPUI, we just need something that PR-builders can actually build PRs against. If we give them an "exploding" UI, it hurts EVERYONE who is trying to pass us PRs for 6.0
[20:20] <KevinVdV> untested though
[20:23] <tdonohue> So, do we have a plan for the next few days here? peterdietz, do you see a "fixed" REST API (at least compilable, minimally usable) possible by early next week? Anyone else willing to help claim some JSPs to fix up? (hint: vagrant-dspace can help you spin up a test instance quickly now)
[20:24] <mhwood> I will try to clear some time to work on JSP, but it's been forever since I've done any of that....
[20:24] <KevinVdV> Well I will attempt to get all unclaimed jsp’s to compile by next week…. all help is appriciated ofc.
[20:24] <peterdietz> i will focus on REST, my heavy weight of SAML is completed.
[20:24] <tdonohue> I'll also do my best to help chip in on JSPs this week
[20:25] <KevinVdV> Make sure to claim a folder before starting, so we don’t do duplicate work :)
[20:25] <tdonohue> definitely.
[20:25] <KevinVdV> I already indicated the ones I have started/finished on
[20:27] <tdonohue> Ok. Sounds like a plan then. Any final thoughts/questions on this?
[20:28] <tdonohue> Hearing none...next topic for today. DSpace 6.
[20:29] <tdonohue> I don't have much to really say here, but wanted to see if anyone has topics for DSpace 6. Currently, it seems like Services API is eating up most/all of our efforts on 6 (which doesn't bode well for our 6.0 timelines thus far). But, there's no way around it right nwo
[20:29] * aschweer (~andrea@239.73.69.111.dynamic.snap.net.nz) has joined #duraspace
[20:29] <mhwood> That is my impression as well.
[20:30] <tdonohue> I will mention that I still *hope* to have a refactored ConfigurationService (to use Apache Commons Config) ready for 6.0. But, it's been delayed by conflicts with Services API (early PR is out there though)
[20:30] <mhwood> Since anything else is likely to need rework.
[20:30] <KevinVdV> The service api will be bigest change in DSpace since the XMLUI
[20:31] <tdonohue> I completely agree, KevinVdV. I think it's much needed, and massive. I just wish it was "flashy" to end users :)
[20:32] <tdonohue> So, the sooner we get Service API done/ready, the sooner we can make sure we have a few other "flashy" looking features to get into this release
[20:32] <KevinVdV> Agreed !
[20:32] <tdonohue> (And I think we have plenty to choose from on our "wishlist" already: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status#DSpaceRelease6.0Status-WishlistforDSpace6.0 )
[20:33] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status#DSpaceRelease6.0Status-WishlistforDSpace6.0
[20:33] <tdonohue> Ok. so, I'm hearing no other discussion topics for DSpace 6 either (at this point)
[20:34] <mhwood> IIRC DS-1782 is addressed by Services work?
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-1782 ] - [DS-1782] DSpace needs local object identifiers - DuraSpace JIRA
[20:34] <tdonohue> yes, mhwood. Service API comes with UUIDs now
[20:34] <KevinVdV> Yeah afraid I stole your thunder there ….
[20:34] <tdonohue> So, that ticket could be changed to link up to 2701
[20:35] <mhwood> Eh, as long as it's done somehow, I can fix an old SWORD ticket.
[20:36] <tdonohue> The only other topic on today's agenda is just a reminder/notice about the DSpace UI Prototype Challenge (just announced this week): https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[20:36] <kompewter> [ DSpace UI Prototype Challenge - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[20:36] <tdonohue> I don't have anything else to say regarding the Prototype Challenge. But, if there are questions, I'd be glad to answer them.
[20:37] <tdonohue> (And yes, it's yet another thing for us to play around with this Fall/Winter... I wish the timelines could be different, but it's going to be a busy end of year it seems)
[20:38] <peterdietz> I hope we get lots of good submissions. Perhaps one will get blessed and be an officially supported UI, others can join a pile of alternatives, I'm hoping for drupal dspace module, wordpress dspace module, php dspace sdk, java dspace sdk, python sdk, etc...
[20:39] <tdonohue> That's it for topics for today. Anyone have anything else you'd like to discuss or brainstorm?
[20:39] <tdonohue> peterdietz: yep, we already have a handful of folks who've signed up immediately :)
[20:39] <peterdietz> I've heard so many great ideas for some value added service "on top of DSpace", that today, are too difficult to even get started. Well first, build your own client framework for consuming DSpace content... :(
[20:39] <mhwood> Ds-1782 has a task for generating UUIDs on existing objects, which might be adaptable.
[20:40] <peterdietz> But.. To have our dspace-frontend-starter, and then change things to have video playback button, larger icons, faces for authors, etc, etc
[20:41] <mhwood> I've been kidding myself that I might try my hand at a JSF UI, for the learning experience.
[20:41] <aschweer> some more eyes on DS-2699 would be great. Essentially, search is pretty broken in 5.3. My PR has been tested by at least 2 institutions for XMLUI and it appears to work better, but it still needs to be ported to JSPUI
[20:41] <kompewter> [ https://jira.duraspace.org/browse/DS-2699 ] - [DS-2699] Search not working as expected - DuraSpace JIRA
[20:41] <aschweer> and it's entirely possible that my approach is fundamentally not right, so it'd be great to have someone else look at it
[20:42] <aschweer> basically, I added a fix to 5.2 that allowed search queries to contain a colon-space sequence and auto-escaped that so solr didn't treat it as a fielded search
[20:43] <aschweer> my original fix broke all sorts of things, so tdonohue put a fix into 5.3 to sort that out. unfortunately I think that fix is a bit too keen and now you can't really do any searches with more than 1 word
[20:45] <tdonohue> aschweer: ugh. I'm not sure if I'll have time in the very near future to play with that again. But, will let you know
[20:45] <aschweer> thanks tdonohue
[20:46] <tdonohue> It might be helpful to link that PR up with the one that "broke things". I just want to see the overall "trend" here...maybe there's a clue to a "right way". It seems like we've now broken this in so many different ways previously (thinking that we had it fixed)
[20:47] <aschweer> will do
[20:47] <tdonohue> aha, found it. Here's the one from me that was in 5.3: DSPR#981
[20:47] <kompewter> [ https://github.com/DSpace/DSpace/pull/981 ] - DS-2602 : Fix Title/Date browsing, also properly escape special characters in Solr by tdonohue
[20:47] <aschweer> which in turn fixed the problem introduced by https://github.com/tdonohue/DSpace/commit/2575d73b2d5f2dd00f80c7903c0b8dbf788e4d9e
[20:47] <kompewter> [ DS-2461 Escape some colons in queries · tdonohue/DSpace@2575d73 · GitHub ] - https://github.com/tdonohue/DSpace/commit/2575d73b2d5f2dd00f80c7903c0b8dbf788e4d9e
[20:48] <tdonohue> It seems very odd to me that your new PR (DSPR#1045) seems to revert back to the same colon (":") escaping that caused the initial broken Browse-by-Title/Date.
[20:48] <kompewter> [ https://github.com/DSpace/DSpace/pull/1045 ] - Ds 2699 improve search by aschweer
[20:48] <aschweer> which came from my DSPR#944
[20:48] <kompewter> [ https://github.com/DSpace/DSpace/pull/944 ] - DS-2461 Escape some colons in queries by aschweer
[20:48] <aschweer> well part of the problem is that we don't want to escape anything other than colons in colon-space sequences
[20:49] <tdonohue> But, that colon (":") escaping is now in a new location...so maybe that helps...dunno
[20:49] <aschweer> my new PR uses a StringUtils replace, which doesn't use regex
[20:49] <mhwood> Time to take a step back and think again about what we are trying to provide? I get the feeling that we may have to have more information from the user to figure out what the Right Thing is. Is this an innocent user making a plain string query, or a Lucene expert trying to do something fancy? We may not be able to satisfy both with a single approach.
[20:49] <aschweer> the nice thing is that if we replace it only in the query string that comes from the user, if it's colon-space we can be pretty sure they don't want to do a fielded search IMHO
[20:50] <aschweer> generally, it's someone who pasted in a full / partial item title and expects that item to come up
[20:50] <aschweer> at least that's what my users have been telling me
[20:50] <mhwood> OK, just a thought.
[20:50] <aschweer> mhwood no it's good you're asking this, and this is why I think fresh eyes would be good
[20:51] <aschweer> I _think_ doing that one escape will improve UX without breaking anything, but I may very well be wrong
[20:51] <aschweer> right now in 5.3, you can't even explicitly specify the boolean operator / do a phrase search
[20:52] <tdonohue> aschweer: one immediate "sanity check" would be to ensure your fix doesn't again break Browse-by-Title/Date. I'm assuming it must not..but that was the initial colon escaping issue we hit
[20:52] <aschweer> tdonohue: yup I've tested that and it's fine
[20:53] <tdonohue> I figured you had. Just wanted to be sure we didn't revert back to a state where DS-2602 existed again :)
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-2602 ] - [DS-2602] Clicking on a letter when browsing by title or year when browsing by date does not work - DuraSpace JIRA
[20:53] <aschweer> the problem with my initial PR was that I had been doing the escaping in a different layer (directly in XMLUI) for my repos, then transferred the escaping to the Discovery layer for the PR without fully testing it. That's why it broke.
[20:54] <tdonohue> Ok. yea, that makes some sense. And then I fixed the "layer" issue, but wrongly escaped more chars :)
[20:54] <aschweer> exactly :)
[20:54] <tdonohue> So, that all makes sense in my head. When I get a chance, I'll try and test out the latest PR.
[20:55] <aschweer> excellent, thanks!
[20:55] <tdonohue> As a sidenote, it seems like we have enough tiny/annoying bugs still in 5.x, that we might start to think about a 5.4 at some point. I'm not trying to give us more work though...but if anyone wants to help lead that effort, it seems like there could be some quick fixes that could be added into it.
[20:56] <aschweer> yeah it's starting to sound like a 5.4 might be good
[20:56] <aschweer> some institutions with local customisations may hold off on upgrading to 6
[20:57] <mhwood> Odd idea: instead of escaping stuff, should we encode it? For example, index the title of something as "Colons: Threat or Menace?" and then similarly encode the queries. (That would require reindexing, of course.)
[20:57] <tdonohue> yep. I agree. I just don't know if a 5.4 will be "plausible" prior to 6.0...or if we'll have to have someone go back and do a 5.4 based on some of the 6.0 bug-fixes (post-6.0)
[20:58] <aschweer> yeah I have a few more bugfix type things that I'm waiting until after the service api refactor so I can do a 5.x and a 6.x PR
[20:58] <tdonohue> mhwood: one issue there would be if you'd miss some "hits"... would simply searching "Colons" still match "Colons:"?
[20:59] <tdonohue> and I'm not sure how Solr would deal with all that encoded stuff
[20:59] <aschweer> it also feels like messing with the data a bit too much -- what would we gain by doing that that we don't get by escaping the colon?
[20:59] <mhwood> Good point. I'm in a "try anything" mood due to banging my head against Ruby/Rails/Javascript all day.
[21:00] <aschweer> yeah and I should probably be quiet since I did ask for fresh eyes on this :)
[21:00] <mhwood> I was trying to think of a way to separate Solr's language from the data more strongly. Brainstorming.
[21:01] <KevinVdV> Needs to run, until next week.
[21:01] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) Quit (Quit: KevinVdV)
[21:01] <tdonohue> So, I notice we are at 1 hour. Any other pressing topics to discuss today? Otherwise, we might want to close up and go off to work on Services API (at least those that still have some time in the workday)
[21:02] <peterdietz> I'm just banging away.. head is currently banging against why I never get to the second debug line:
[21:02] <peterdietz> log.debug("Before findIDOrLegacy");
[21:02] <peterdietz> community = communityService.findByIdOrLegacyId(context, id);
[21:02] <peterdietz> log.debug("After findByIdOrLegacy");
[21:03] <peterdietz> I need to get a proper integration with IntelliJ Debug. I'll do trade labor, I'll give you a crash course on rest / saml, and you wire up my IDEA
[21:03] <mhwood> It throws something that gets swallowed silently somewhere up the call chain?
[21:03] <peterdietz> yeah. I'm catching all the method signature errors. RunTimeExceptions are not specified in signature, and can strike at any time?
[21:04] <mhwood> Yeah, just catch Throwable and see if you catch any.
[21:04] <aschweer> I have to go to work, bye everyone
[21:04] * aschweer (~andrea@239.73.69.111.dynamic.snap.net.nz) Quit (Quit: leaving)
[21:04] <peterdietz> I just get catch(Exception e).. Throwable is different?
[21:04] <tdonohue> I'm going to close up today's meeting. Feel free to continue code discussions though (here or in #dspace)
[21:04] <peterdietz> hopping over to #dspace
[21:05] <mhwood> And I have to go home. Hm, I would have to look up Exception but I think it subclasses Throwable.
[21:09] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:30] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
[21:48] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.