Timestamps are in GMT/BST.
[6:30] -orwell.freenode.net- *** Looking up your hostname...
[6:30] -orwell.freenode.net- *** Checking Ident
[6:30] -orwell.freenode.net- *** Found your hostname
[6:30] -orwell.freenode.net- *** No Ident response
[6:30] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:30] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:30] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[12:34] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:01] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[14:50] <DSpaceSlackBot> <pbecker> I just read the logs from last week's meeting. When I started to work on the RDF implementation I had it all on dspace-rdf. @mdiggory suggested to move as much as possible to dspace-api and to let only the web-frontend in dspace-rdf. That was a good advice I followed.
[14:50] <DSpaceSlackBot> <pbecker> So all conversion for DSpace-RDF is done by code in dspace-api.
[14:51] <DSpaceSlackBot> <pbecker> dspace-rdf does nothing else then answering web requests.
[14:51] <DSpaceSlackBot> <pbecker> We can think about moving oai in the same direction, but I'm afraid that the use of XOAI may make it hard to seperate the frontend from the backend.
[14:52] <DSpaceSlackBot> <pbecker> I hope that answers some of the question @philip.muench @sulfrian and @tdonohue were discussing.
[14:57] <DSpaceSlackBot> <philip.muench> @pbecker I think the main question regarding moving the import code to a OAIConsumer is if it shares classes with the webapp code. Having xoai.jar as a dspace-api dependency should not be such a problem?
[15:01] <DSpaceSlackBot> <pbecker> We probably all want to avoid code duplication. So we should separate the code in dspace-oai in the part that is needed for the frontend and the part that isn't. I just hope that there is not to many code that is really necessary for both.
[15:02] <DSpaceSlackBot> <pbecker> Making dspace-api dependent on xoai is probably not a problem, but something we might want to discuss. XOAI is officially maintained by DSpace. But does any one of us really know the code? Is there any development necessary and/or ongoing? Are there other projects using it?
[15:03] <DSpaceSlackBot> <pbecker> What we probably must avoid is that dspace-api needs code from dspace-oai to compile. We probably would end in a circular dependency (dspace-api -> dspace-oai -> dspace-api).
[15:04] <DSpaceSlackBot> <philip.muench> @pbecker There are some imports in XOAI.java (The import CLI tool) from packages in the xoai project or of classes that implement/extend xoai abstract classes/interfaces. I don't know if those are also used in the webapp. I will try to find out.
[15:05] <DSpaceSlackBot> <pbecker> @philip.muench thank you.
[15:12] <DSpaceSlackBot> <philip.muench> Well, already found the first candidate: org.dspace.xoai.services.api.CollectionsService. It is used both in XOAI and in DSpaceSetSpecFilter. Disclaimer: everything I'm talking about refers to dspace-6_x, a lot of refactoring has happened since then in master.
[15:23] <DSpaceSlackBot> <sulfrian> I am still unsure, if the OAI stuff should really keep all the metadata in the solr and does not use the database.
[15:26] <DSpaceSlackBot> <philip.muench> @sulfrian I think the main advantage is that the oai index does not hold a copy of the metadata, but a finished xml document containing the metadata, which basically means that the DOM construction step (the Crosswalks in early Dspace versions) is only done once per item / item modification, instead of for each query.
[15:28] <DSpaceSlackBot> <philip.muench> @sulfrian correction: It does contain the metadata as well, because filters wouldn't work otherwise.
[15:47] <DSpaceSlackBot> <sulfrian> Ah, I see. So the oai solr index is a glorified cache for the intermediate xml format of the items.
[17:13] <DSpaceSlackBot> <philip.muench> @sulfrian that is a possible interpretation, yes :slightly_smiling_face:
[17:22] <DSpaceSlackBot> <philip.muench> But I think it is a good idea to save the intermediate format. The crosswalks in older DSpace versions certainly took their time compiling OAI records...
[19:01] <DSpaceSlackBot> <tdonohue> Reminder our weekly DSpace DevMtg is in about one hour. Agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-10-25
[19:01] <kompewter> [ DevMtg 2017-10-25 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-10-25
[20:01] <DSpaceSlackBot> <tdonohue> <here>: It's DevMtg time. Rough aenda is linked above :point_up: Could we do a quick roll call to see who is joining us today?
[20:01] <DSpaceSlackBot> <tdonohue> Rough agenda that is ;)
[20:01] <DSpaceSlackBot> <mwood> Sure.
[20:01] <DSpaceSlackBot> <terrywbrady> here
[20:03] <DSpaceSlackBot> <tdonohue> Ok, we've got our usual 3-ish people for these "later" (20UTC) meetings....seems like the earlier meetings always have more eyes these days.
[20:03] <DSpaceSlackBot> <mwood> Only three? Cool, we should be able to make *lots* of decisions.
[20:03] <DSpaceSlackBot> <tdonohue> In any case, we can move along... the topics for this week are mostly the same as last...but, we'll have time to bring in new topics as we see fit
[20:05] <DSpaceSlackBot> <tdonohue> First up, on the DSpace 7 team side...not a ton to report. Making good progress overall, but a lot of it is on REST API endpoints, improved test coverage, minor UI bug fixes, etc. Nothing specific to talk about though
[20:05] <DSpaceSlackBot> <tdonohue> If there are questions/comments, I'm glad to try to answer them... but I didn't have anything specific to say on DSpace 7 work this past week
[20:06] <DSpaceSlackBot> <tdonohue> (and our next meeting is tomorrow at 15UTC, obviously, so more discussion will happen there)
[20:06] <DSpaceSlackBot> <terrywbrady> No questions here. I have been working on internal projects and have not had much time for dspace work.
[20:06] <DSpaceSlackBot> <mwood> That sounds familiar.
[20:07] <DSpaceSlackBot> <tdonohue> Sounds fine...in that case, moving on to the Code Mgmt topic (carryover from last week)...
[20:07] <DSpaceSlackBot> <tdonohue> @tom_desair has a PR for reporting code coverage on `master`. He says it's ready to go: https://github.com/DSpace/DSpace/pull/1865
[20:07] <kompewter> [ DS-3711: JaCoCo maven plugin by tomdesair · Pull Request #1865 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1865
[20:08] <DSpaceSlackBot> <tdonohue> This hooks up to Coveralls (as mentioned last week), and provides reports like this: https://coveralls.io/builds/13700121
[20:08] <kompewter> [ DSpace/DSpace | Build #4813 | Coveralls - Test Coverage History & Statistics ] - https://coveralls.io/builds/13700121
[20:09] <DSpaceSlackBot> <tdonohue> But, I'd appreciate some more eyes or comments on this... it's a new thing for us. The PR is pretty small though, as it really is just POM changes to trigger these reports and send them to Coveralls
[20:09] <DSpaceSlackBot> <tdonohue> Ideally, we merge this soonish...that way we can improve our coverage percentage, etc
[20:10] <DSpaceSlackBot> <tdonohue> (And I'll bring this up with the DSpace 7 team too tomorrow)
[20:10] <DSpaceSlackBot> <mwood> Improve...or know that we haven't. :-/
[20:10] <DSpaceSlackBot> <tdonohue> So, this is your chance to object or offer feedback. Otherwise, I'm gonna likely just move forward here in the next week and get this merged.
[20:11] <DSpaceSlackBot> <mwood> No comments yet on the specific patch, but in general yes, we should be monitoring our testing efforts and improving them.
[20:12] <DSpaceSlackBot> <tdonohue> And just to clarify, at this time, no plans to backport to other branches. This is just going into `master` and we'll monitor tests there...but not on other branches
[20:12] <DSpaceSlackBot> <mwood> Sensible.
[20:12] <DSpaceSlackBot> <terrywbrady> Makes sense
[20:13] <DSpaceSlackBot> <tdonohue> Ok, the last topic in this "Code Mgmt" section...is reviewing our Code Style. I haven't heard any feedback on the Wiki notes at: https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266
[20:13] <kompewter> [ Code Style Guide (WIP) - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=90967266
[20:14] <DSpaceSlackBot> <mwood> Yeah, I just now have been reading them.
[20:14] <DSpaceSlackBot> <tdonohue> Not sure if anyone has thoughts on changing our code style, or simply going with what we have (which is based on a nearly obsolete *Sun* code style)
[20:14] <DSpaceSlackBot> <mwood> How do we know it's obsolete?
[20:15] <DSpaceSlackBot> <tdonohue> Well, it's at least not maintained. Sun obviously is no longer an organization.. It's now hosted at Oracle under the heading "Not maintained"
[20:15] <DSpaceSlackBot> <tdonohue> Here's the Sun Code Style at Oracle: http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html
[20:15] <kompewter> [ Code Conventions for the Java Programming Language: Contents ] - http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html
[20:15] <DSpaceSlackBot> <terrywbrady> I don't like curly braces on a new line, but I do not care enough about that to stand in the way of consistency.
[20:15] <DSpaceSlackBot> <mwood> Ah, I'm just the other way -- I find it hard to read braces that don't align.
[20:16] <DSpaceSlackBot> <tdonohue> We don't actually have any consistency in our codebase (I checked a bit). That's why I'm questioning right now whether we redefine our code style to something we "like better", etc
[20:17] <DSpaceSlackBot> <tdonohue> I'm not against staying with our code style...but on the other hand, it might be nice to look at e.g. Fedora Commons code style (based roughly on Google's) to see if we should just align with other DuraSpace projects.
[20:17] <DSpaceSlackBot> <tdonohue> We wouldn't have to adopt it completely "as-is", but we could align ourselves better with others.
[20:18] <DSpaceSlackBot> <terrywbrady> If adoption has been sensible for Fedora, that sounds like a good starting point
[20:18] <DSpaceSlackBot> <tdonohue> Fedora adopted a code style when the (re)built Fedora as Fedora4. They've stuck with it since then.
[20:19] <DSpaceSlackBot> <mwood> We have source "features" that cause real problems. Run-on lines hundreds of characters long, that don't fit on any display. Mixed tab and space indentation that looks crazy if your local settings don't match some of the lines. Mixed indentation *in the same line* that makes editing unpredictable.
[20:19] <DSpaceSlackBot> <mwood> +1 "pick something and stick with it".
[20:20] <DSpaceSlackBot> <mwood> If we chase current fashion, we'll have a never-ending stream of gigantic reformatting patches.
[20:20] <DSpaceSlackBot> <tdonohue> Yep, exactly. Any simple code style checks/validation (in checkstyle) would solve those major issues
[20:20] <DSpaceSlackBot> <terrywbrady> I know I have been a culprit on white space consistency, so I am eager to have a standard in place to stick to.
[20:21] <DSpaceSlackBot> <tdonohue> So, I personally lean towards realign with Fedora's checkstyle, but start out slightly less strict than Fedora (as they also have checks that require JavaDoc comments on all public methods, etc)
[20:21] <DSpaceSlackBot> <terrywbrady> Also, it is frustrating to prepare a significant PR and only get feedback on style issues. Hopefully this will eliminate that from happening.
[20:22] <DSpaceSlackBot> <mwood> Now, I would vote for requiring documentation in a heartbeat.
[20:22] <DSpaceSlackBot> <tdonohue> Moving towards Fedora would mean moving to K&R style brackets (inline brackets, not new-line). But, would allow lines of 120 chars max, 4-space indentation (no tabs), no trailing spaces, etc
[20:23] <DSpaceSlackBot> <tdonohue> @mwood: I'm not against requiring javadocs in the long run, but that'd be a secondary step. Simply getting the *existing* code reformatted will be a massive step. Having to also write all missing JavaDocs makes it even harder
[20:23] <DSpaceSlackBot> <terrywbrady> In the fedora guide, the guidance on public methods/variables may not be enforceable for an existing code base. The other rules look very sensible
[20:24] <DSpaceSlackBot> <tdonohue> @terrywbrady: yes, we'd need to tweak the rules a bit no matter what we go with. Just wanted to find a good starting point
[20:25] <DSpaceSlackBot> <mwood> wonders if there's a NetBeans plugin to make braces *display* on a new line but *save* at the end of the previous line.
[20:26] <DSpaceSlackBot> <tdonohue> @mwood: dunno. But, a part of me wonders if the visual you are looking for will be vastly improved *anyhow* just by standardizing our indentations. The frustration now is that no standard indents + inline braces makes things ultra confusing
[20:27] <DSpaceSlackBot> <mwood> I had been thinking that a really minimal approach would do to start: just saying loudly, "you know, we have a style guide for this project <link>".
[20:27] <DSpaceSlackBot> <tdonohue> Once stuff is indented properly, you may not need the braces as much to see where code "sits"
[20:27] <DSpaceSlackBot> <mwood> My experience with Python suggests that I'll still be bothered.
[20:30] <DSpaceSlackBot> <mwood> Oh well, I got used to braces in place of neatly stacked DO stuff END
[20:30] <DSpaceSlackBot> <tdonohue> Understood, it's just hard for me to argue strongly for newline brackets when simply every other example (Sun, Google, Fedora) I find is standardizing on K&R style. I don't have much preference myself, admittedly
[20:30] <DSpaceSlackBot> <mwood> I won't fight on endlessly....
[20:30] <DSpaceSlackBot> <tdonohue> I just see benefit to aligning with others (lets programmers move more seamlessly between projects without having to re-program their IDE environment, etc)
[20:31] <DSpaceSlackBot> <mwood> That is so. However, fashions change, so if we're not careful we'll be aligning over and over.
[20:32] <DSpaceSlackBot> <mwood> The key thing to me is: how readable is it?
[20:32] <DSpaceSlackBot> <tdonohue> In any case, the devil is in the details here. I need to find time myself to move this forward (not seeing it in the near future, but maybe as holidays approach), and then coordinate with those who will be affected (DSpace 7 team, anyone else working on master or creating PRs on master)
[20:33] <DSpaceSlackBot> <tdonohue> So, while I think this is a *good idea*. I admit, I'm not sure this is happening immediately...but, I hope maybe we get it in by end of year. So, there's more time to discuss with others, and if enough folks say "new line brackets!!!", then we can go that route
[20:33] <DSpaceSlackBot> <mwood> Fair enough.
[20:34] <DSpaceSlackBot> <tdonohue> So, @mwood start gathering your army of new-liners ;)
[20:34] <DSpaceSlackBot> <mwood> It's down to training, I guess. I'm accustomed to recognizing blocks by the paired delimiters, and if they're unaligned then I can't use my brain's spatial processing for that. I'll have to learn a whole different set of structural cues.
[20:35] <DSpaceSlackBot> <mwood> But then, someone trained in that other way will be disturbed by all the vertical "noise" in my favorite style.
[20:36] <DSpaceSlackBot> <tdonohue> I'd say feel free to bring it up as a discussion topic on lists, in the Wiki page, etc. I'll also note my leanings (with possibly moving to Fedora-inspired styles) and we'll see how this plays out.
[20:36] <DSpaceSlackBot> <mwood> OK
[20:36] <DSpaceSlackBot> <tdonohue> I'm perfectly OK with going with "majority" here
[20:37] <DSpaceSlackBot> <tdonohue> So, topic-wise...those were really the only topics I *specifically* added to the agenda.
[20:38] <DSpaceSlackBot> <mwood> There's another dimension of tooling updates here: static code analysis.
[20:38] <DSpaceSlackBot> <tdonohue> We have time to discuss whatever is top of mind, or to look at recent tickets, etc
[20:38] <DSpaceSlackBot> <terrywbrady> We have a DSpace/IIIF meeting scheduled for next week: https://wiki.duraspace.org/pages/viewpage.action?pageId=90966793
[20:38] <kompewter> [ IIIF/DSpace Meeting Nov 3, 2017 at 1500 UTC - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=90966793
[20:39] <DSpaceSlackBot> <tdonohue> @mwood: "static code analysis"...any good examples you wanted to touch on?
[20:39] <DSpaceSlackBot> <mwood> I haven't spent much time on Error Prone, but it seems like a good complement to some of the others. It's much more opinionated about a small class of code smells that others take leniently.
[20:39] <DSpaceSlackBot> <tdonohue> @terrywbrady: glad to see the excitement about IIIF and good to see if moving forward!
[20:40] <DSpaceSlackBot> <terrywbrady> We have created some interesting prototypes here. We like the capabilities. We need to figure out how we would like to integrate the viewer with DSpace.
[20:41] <DSpaceSlackBot> <mwood> OTOH FindBugs and its descendants seem much more comprehensive. Left to myself, I might use both.
[20:41] <DSpaceSlackBot> <terrywbrady> On a separate note, I am still seeking approval on 3 PR's. I have a +1 on 2 of 3. https://github.com/terrywbrady/restReportTutorial/blob/master/README.md
[20:41] <kompewter> [ restReportTutorial/README.md at master · terrywbrady/restReportTutorial · GitHub ] - https://github.com/terrywbrady/restReportTutorial/blob/master/README.md
[20:42] <DSpaceSlackBot> <tdonohue> @mwood: ErrorProne by default is only really strongly opinionated about things that look like possible coding mistakes. See "On by default" section here: http://errorprone.info/bugpatterns
[20:42] <kompewter> [ 1 ] - http://errorprone.info/bugpatterns
[20:42] <DSpaceSlackBot> <tdonohue> FindBugs is definitely more extensive, and goes into things like performance, security, etc http://findbugs.sourceforge.net/bugDescriptions.html
[20:42] <kompewter> [ FindBugs Bug Descriptions ] - http://findbugs.sourceforge.net/bugDescriptions.html
[20:43] <DSpaceSlackBot> <tdonohue> So, yes, they could be used together...and there likely is some overlap. We actually do have findbugs already in our POMs, but not running by default
[20:44] <DSpaceSlackBot> <tdonohue> @terrywbrady: thanks for the reminder on the PRs. I will admit, I haven't had much time this past week for PR reviews, etc. I still unfortunately need to look at them.
[20:45] <DSpaceSlackBot> <terrywbrady> I understand. I have been pulled in many directions this month.
[20:45] <DSpaceSlackBot> <mwood> Same here, @terrywbrady. I want to learn to use that stuff, but need to block out some time.
[20:46] <DSpaceSlackBot> <mwood> We have folks here who want to pull bibliographic info out of our IR into other tools, and I am wondering just how consistent some of our metadata are....
[20:46] <DSpaceSlackBot> <terrywbrady> Thanks if you all have a chance. I hope the documentation makes it easy.
[20:48] <DSpaceSlackBot> <tdonohue> One quick question comes to mind RE the changes in https://github.com/DSpace/DSpace/pull/1862 Would this accidentally surface withdrawn items via REST API publicly? Or are there access restrictions here?
[20:48] <kompewter> [ [DS-3714] REST Collection Report - Need a paginated findByCollection call that can return withdrawn items by terrywbrady · Pull Request #1862 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1862
[20:48] <DSpaceSlackBot> <tdonohue> i.e. withdrawn items shouldn't be findable at all, unless you are a full Admin
[20:48] <DSpaceSlackBot> <terrywbrady> You have to either login with the right access OR configure the report tools to ignore authorization.
[20:49] <DSpaceSlackBot> <terrywbrady> Since we lock down the report tools, we ignore authorization as they run.
[20:49] <DSpaceSlackBot> <tdonohue> I'm talking about going at the REST API, to be clear...bypassing the report tools
[20:49] <DSpaceSlackBot> <tdonohue> If someone hits the REST API directly, could they see withdrawn items
[20:50] <DSpaceSlackBot> <terrywbrady> No. Not unless they configure rest to ignore authorization
[20:51] <DSpaceSlackBot> <tdonohue> Ok, I just wanted to be sure...as I saw it changes what is returned in specific REST requests...just wanted to be certain this was tested for security ;)
[20:52] <DSpaceSlackBot> <terrywbrady> Feel free to post a comment on that to the PR, and I will be happy to provide an explanation.
[20:53] <DSpaceSlackBot> <tdonohue> This whole discussion makes me wonder why we have that ignore authZ option anyhow...that's a potentially major security issue for REST
[20:53] <DSpaceSlackBot> <mwood> Good question.
[20:54] <DSpaceSlackBot> <terrywbrady> I created these tools in a version of DSpace that provided no mechanism for logging in.
[20:54] <DSpaceSlackBot> <tdonohue> maybe we should deprecate them?
[20:54] <DSpaceSlackBot> <terrywbrady> Then, the shibboleth authentication was not working in rest for some time.
[20:55] <DSpaceSlackBot> <tdonohue> @terrywbrady: I commented on the PR too, so you can answer this question there
[20:57] <DSpaceSlackBot> <terrywbrady> thanks
[20:57] <DSpaceSlackBot> <tdonohue> I do worry though that someone could have turned on "ignore authZ" early on (when it was not so harmful, as not much could be done)...and now that we add in more endpoints/features, it could start to become a security concern
[20:58] <DSpaceSlackBot> <tdonohue> So, at least in my mind, I wonder if we should deprecate now(ish) & remove it in DSpace 7.
[20:58] <DSpaceSlackBot> <mwood> [slippery slope] Should build.xml's 'update' target look for this and issue a warning?
[20:59] <DSpaceSlackBot> <terrywbrady> The REST calls will be rewritten in DSpace 7, so this component only has a life in DSpace 6.
[21:00] <DSpaceSlackBot> <tdonohue> True. Maybe we minimally make sure the warnings in docs & configs are very obvious. It doesn't seem like a setting we want to recommend turning "on" in DSpace 6
[21:01] <DSpaceSlackBot> <terrywbrady> I just hope that these tools get some use by another institution.
[21:02] <DSpaceSlackBot> <tdonohue> +1 I also hope they are possible to (relatively easily) move forward to the DSpace 7 REST API, once the equivalent endpoints are ready
[21:02] <DSpaceSlackBot> <tdonohue> I'm realizing we are now at 1 hour... I didn't have any other topics, and unfortunately do have to run. Good discussion though, and keep thinking on the Code Style ideas, and provide feedback (in email thread, wiki, etc)
[21:02] <DSpaceSlackBot> <tdonohue> Thanks all!
[21:03] <DSpaceSlackBot> <terrywbrady> Have a good week!
[21:03] <DSpaceSlackBot> <mwood> Thanks!
[21:04] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:35] * dyelar (~dyelar@dyelar.mrb.ku.edu) has joined #duraspace
[21:46] * tdonohue (~tdonohue@dspace/tdonohue) has left #duraspace
[21:50] * dyelar (~dyelar@dyelar.mrb.ku.edu) Quit (Quit: Leaving.)
[22:01] * dyelar (~dyelar@dyelar.mrb.ku.edu) has joined #duraspace
[22:18] * dyelar (~dyelar@dyelar.mrb.ku.edu) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.