Timestamps are in GMT/BST.
[6:31] -verne.freenode.net- *** Looking up your hostname...
[6:31] -verne.freenode.net- *** Checking Ident
[6:31] -verne.freenode.net- *** Found your hostname
[6:31] -verne.freenode.net- *** No Ident response
[6:31] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:31] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:31] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:15] * helix84 (~ctenar@195.178.95.132) has joined #duraspace
[11:46] * kshepherd2 (~kim@121-99-35-254.bng1.nct.orcon.net.nz) has joined #duraspace
[12:27] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:54] * kshepherd2 (~kim@121-99-35-254.bng1.nct.orcon.net.nz) Quit (Ping timeout: 245 seconds)
[12:58] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[15:00] -wilhelm.freenode.net- *** Looking up your hostname...
[15:00] -wilhelm.freenode.net- *** Checking Ident
[15:00] -wilhelm.freenode.net- *** Found your hostname
[15:00] -wilhelm.freenode.net- *** No Ident response
[15:00] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[15:00] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[15:00] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[16:10] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[17:12] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[19:06] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) Quit (Quit: Leaving.)
[20:00] <mhwood> Coming up in about one minute: DSpace developer meeting.
[20:00] <mhwood> https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-04-16
[20:00] <kompewter> [ DevMtg 2014-04-16 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-04-16
[20:01] <mhwood> Come one, come all.
[20:03] <hpottinger> howdy
[20:03] <mhwood> Well, that's two of us.
[20:03] <hpottinger> two committers, we don't have quorum
[20:04] * hpottinger elbows helix84 and kshepherd
[20:05] <hpottinger> well, how are YOU mhwood?
[20:06] <mhwood> Doing alright. Got myself a bigger teacup.
[20:06] <hpottinger> oh, thanks for the reminder, I should reload on tea and perhaps guests will arrive in the mean time?
[20:07] <hpottinger> brb
[20:07] <mhwood> Go for it. I'll be here.
[20:07] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:07] <PeterDietz> hi all
[20:07] <mhwood> Welcome! Now we are three (as soon as hpottinger returns).
[20:07] <mhwood> https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-04-16
[20:07] <kompewter> [ DevMtg 2014-04-16 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-04-16
[20:09] <mhwood> Sorry, we're a bit disorganized today.
[20:09] <hpottinger> I'm back
[20:09] <hpottinger> now we can make some decisions!
[20:10] * hpottinger cracks his knuckles.
[20:10] <mhwood> OK, first item: 3.3 and 4.2 status.
[20:10] <PeterDietz> Perhaps related to business services, I've been toying with an idea related to that for some time. Get REST to support whatever business logic you need, then yank that code out of UI. Then wire up UI to call REST to make it happen
[20:10] <mhwood> 3.3: I need to follow up a couple of tickets and get this rolling.
[20:11] <mhwood> That deserves some thought.
[20:11] <hpottinger> re 4.2: I'd like to test DS-1906, it would be a good bug fix
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1906 ] - [DS-1906] Shibboleth attributes may need to be reconverted - DuraSpace JIRA
[20:12] <mhwood> Yes, if we can have that one in a reasonable amount of time, it would be good to get it in.
[20:12] <mhwood> Anything else on minor releases?
[20:13] <hpottinger> I have a self-appointed deadline of "1 sprint" to finish up some hardware migration stuff, can try to work in testing 1906 as part of my "kicking the tires"
[20:13] <mhwood> Great!
[20:14] <mhwood> Item 2: maven enforcer plugin
[20:15] <mhwood> The initial use would be to warn us of transitive SNAPSHOT dependencies.
[20:15] <hpottinger> aka "The loving iron fist of Maven" +1
[20:15] <hpottinger> I like this idea
[20:16] <mhwood> Related: DS-1971
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1971 ] - [DS-1971] 'bte-io' (v 0.9.2.3) dependency from EKT has an invalid SNAPSHOT dependency in its POM - DuraSpace JIRA
[20:17] <mhwood> (And an issue to come back to: EKT has a fix for 1971 but wants a ruling on Java version used to build the artifact.)
[20:20] <mhwood> Any other comments on m-enforcer-p? Who will write the ticket?
[20:20] <hpottinger> I think the ruling is clear: we're OK with 1.7 for 4.0... the knot that needs untying is, will that break deploying DSpace 3.x?
[20:23] <mhwood> Good point. Problem is being too new to link with classes built for 3.x. 3.x documentation says we support Java 1.6 or 1.7, so I'd say it's better to build BTE with 1.6.
[20:24] <mhwood> I will so reply to the query, if there is no objection.
[20:24] <hpottinger> I"m going to look at the pom for 3.x just to see what version we're asking for
[20:24] <mhwood> BTE was indeed used in 3.x, yes?
[20:26] <mhwood> Other discussion of having m-enforcer-p check for only transitive SNAPSHOT dependencies?
[20:29] <hpottinger> I gave my +1 I like the idea a lot
[20:29] <hpottinger> https://github.com/DSpace/DSpace/blob/dspace-3_x/dspace-api/pom.xml#L373
[20:29] <kompewter> [ DSpace/dspace-api/pom.xml at dspace-3_x · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/dspace-3_x/dspace-api/pom.xml#L373
[20:31] <mhwood> So it was indeed in 3.x.
[20:31] <mhwood> Seems to be a different version, though.
[20:32] <hpottinger> correct, I think building the newer version, targeted at 1.7, should be fine
[20:32] * hpottinger is a bear of very little brain, though
[20:33] <mhwood> I think what I will say is that the issue with BTE 9.0.2.x only affects DSpace 4.x, and for that we could work with either Java 6 or 7, but of course they may have other dependents with more stringent requirements.
[20:35] <hpottinger> https://github.com/EKT/Biblio-Transformation-Engine/network
[20:35] <kompewter> [ Network Graph · EKT/Biblio-Transformation-Engine · GitHub ] - https://github.com/EKT/Biblio-Transformation-Engine/network
[20:36] <hpottinger> the "dspace-version" appears to be a few commits ahead, if I'm reading that graph correctly?
[20:38] <hpottinger> sorry, didn't mean to derail anythign with shiny graphics :-)
[20:39] <mhwood> It looks as though 0.9.2 is what DSpace is using. We asked EKT specifically for backport of some fixes or some such to 0.9.2 because 0.9.3 had breaking changes of some sort. Then there is an 0.10 branch presumably with pretty new work that we haven't seen.
[20:39] <mhwood> They've been really nice about this, and IMHO we need to make certain that we come up-to-date with their later branches for 5.0.
[20:40] <hpottinger> I agree, and this is the heart of some cool features for DSpace
[20:41] <hpottinger> so, anyway, for 4.0 on, Java 7 is a-OK
[20:43] <mhwood> They already have one built with 1.6. I think we can use that one? Backward compatibility is (usually) a given in Java. But an artifact compiled by 1.7 could not be linked by a 1.6 JRE. Is that right?
[20:43] <hpottinger> correct
[20:44] <hpottinger> there's some "weird stuff" in 1.7 that 1.6 wouldn't "get"
[20:44] <hpottinger> mostly to do with exception handling
[20:44] <mhwood> So I think the best thing for them would be to deploy their 1.6-compiled artifact to Central. We should be able to use it on a 1.7 JRE, and if they have dependents still on 1.6 those should not be affected.
[20:46] <hpottinger> that's conservative, and safe, don't know what we'd lose, but it sounds like it would work
[20:46] <mhwood> I will so comment the ticket then.
[20:47] <mhwood> "Thank you for promptly addressing this issue.
[20:47] <mhwood> I think that DSpace should work with dependencies that are built by Java 1.6 or 1.7. You may have other dependents for which 1.7 would be too new. The conservative thing to do would be to go ahead and deploy your 1.6-built artifact to Central."
[20:48] <hpottinger> excellent!
[20:48] <mhwood> Posted.
[20:48] <mhwood> Do we have a volunteer to write the ticket for adding m-enforcer-p?
[20:49] <hpottinger> I can
[20:50] <mhwood> Thanks. I think that disposes of all specific agenda items, then. PeterDietz brought an "other topic": using REST to migrate business logic out of the UIs.
[20:51] <hpottinger> +1 business logic layer
[20:51] <hpottinger> also, this enforcer ticket I'm going to add, I'm going to accept it and label it as "low-hanging-fruit"
[20:51] <mhwood> OK.
[20:51] <hpottinger> and "volunteer needed"
[20:56] <mhwood> Any discussion of PeterDietz idea?
[20:56] <mhwood> hpottinger I saw your +1
[20:56] <hpottinger> :-)
[20:57] <hpottinger> Peter, talk us through what you have in mind?
[20:57] * hpottinger wishes for a whiteboard.
[21:00] <mhwood> Sounds like this would be a step toward detaching the UIs altogether. Weakening the coupling between frontend and backend might be beneficial.
[21:00] <hpottinger> I always forget how this thing works, I have to actually mention a handle, right, PeterDietz?
[21:00] <PeterDietz> hi, yanked away, back
[21:01] <mhwood> Sorry to make you wait.
[21:01] <PeterDietz> no, I feel bad for holding you guys up.
[21:01] <hpottinger> DS-1972
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1972 ] - [DS-1972] add Maven enforcer plugin and configuration to prevent transitive SNAPSHOT dependencies - DuraSpace JIRA
[21:01] <mhwood> Thanks.
[21:02] <PeterDietz> So. How does one go about making cleanups in DSpace? i.e. what will motivate us/one to clean up everything? Perhaps making an attempt TO break things,
[21:03] <mhwood> Can you break it down into smaller pieces that could be done individually, at least far enough to tease out one non-huge bit of work as a proof-of-concept?
[21:04] <PeterDietz> The goal here isn't TO break things, but for commonly repeated business logic, build a clean way to do something through a service i.e. REST, one example could be for getting configs
[21:04] <hpottinger> so, you're talking about refactoring the UIs
[21:04] <PeterDietz> Then, wherever configs are asked for in all the UI's force them to consume that data via REST.
[21:05] <hpottinger> if REST is going to do configs, REST needs AuthZ
[21:05] <mhwood> Putting it in REST should make it impossible for business logic to live in the UIs anymore, because they would (at some point) lose direct access to the necessary information and instead have to ask for it across a network link.
[21:05] <PeterDietz> I don't know if others would want to do such a thing. But, I'm not sure I want all these things living in the DSpace tree. i.e. xmlui, jspui, others
[21:05] <mhwood> I hear that.
[21:06] <PeterDietz> hmm, so maybe there's a few things going on. Business logic, could be things like access to constants, i.e. ITEM=2, or it could be access to Item.findAll
[21:07] <mhwood> The network roundtrip adds a little latency, but it's local or in-house so not bad. A lot of products are going that way. You could, for example, put the web services on internal networks and only expose the thinner UI shell to the public.
[21:07] <PeterDietz> My goal would be that instead of JSPUI implementing Item.delete its own way, and XMLUI doing that its own way, to make some utlitiy in dspace-core that does that
[21:08] <hpottinger> I like the idea of doing configs via REST... I especially like the idea that doing so bumps into missing functionality (AuthZ/N) which, if added, will greatly improve REST
[21:09] <mhwood> I like the idea of taking authNZ decisions away from the UIs.
[21:09] <hpottinger> I espcially like that we get our missing business logic layer :-)
[21:11] <hpottinger> I would say that the way to approach refactoring would be to gradually make the existing methods all consumers of the API
[21:11] <hpottinger> you'd need a "hit list" of methods you want to refactor
[21:11] <mhwood> I apologize, but I'm going to have to go pretty quickly. I should note that we've passed the official end-of-meeting time. I invite continuing discussion.
[21:12] <hpottinger> I'm not an officially-trained developer, though, and changing the existing methods to consume an API may not be "best practice"
[21:13] <hpottinger> oddly enough, I even own Martin Fowler's refactoring book, I should actually read it
[21:13] * mhwood has a tottering stack of books "I should read".
[21:15] <mhwood> I hate to run out on you all, but I've got to dash. Whatever discussion happens now, perhaps you could bring this up again when we have more in attendance?
[21:15] <hpottinger> will do
[21:15] <mhwood> Thanks. Bye, all!
[21:15] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:16] <hpottinger> just us and the lurkers now
[21:17] <hpottinger> Book: http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672
[21:17] <kompewter> [ Refactoring: Improving the Design of Existing Code: Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts: 9780201485677: Amazon.com: Books ] - http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672
[21:17] <hpottinger> Library? http://www.worldcat.org/search?qt=worldcat_org_all&q=0201485672
[21:17] <kompewter> [ Results for '0201485672' [WorldCat.org] ] - http://www.worldcat.org/search?qt=worldcat_org_all&q=0201485672
[21:21] <hpottinger> so, anyway, PeterDietz, I like this idea, how can we help?
[21:21] <PeterDietz> I'll keep thinking about a best approach for cleaning up DSpace. and/or whatever will be valuable projects to tackle
[21:23] <hpottinger> I really like the idea of moving config to REST
[21:23] <PeterDietz> Part of me thinks to just leave major parts of DSpace alone, build new features into REST. If rest needs utilities that exist tucked away in a UI, I'll duplicate it yet-again, but put it in dspace-api, then yank it out of the UI, but make it use the dspace-api call.
[21:23] <PeterDietz> Because maybe I don't want to rock the boat too hard at first,
[21:24] <hpottinger> we do have this fancy config service based on Spring
[21:24] * kshepherd2 (~kim@47.72.154.177) has joined #duraspace
[21:24] <PeterDietz> yeah, spring's a lot
[21:24] <hpottinger> woah, two kshepherds
[21:25] <hpottinger> PeterDietz is rocking the boat, kshepherd2.
[21:26] <PeterDietz> But, a cleaned up DSpace, doesn't neccessarily add value to any end-users, just makes it less mucky for active developers. But, where will you find active developers? Working on the Dspace internals? Or would developers want to focus on consuming a REST api, and building out a new frontend... Or would people just still be focused on doing things with existing UI's.
[21:27] <PeterDietz> A future might be some rails-UI (running off of REST). But the current is going to have to bring value for your xmlui crew??
[21:27] * hpottinger does not take the bait
[21:27] <hpottinger> I will *not* launch into a diatribe against Cocoon.
[21:28] <PeterDietz> There is some I would want to save that lives in xmlui, but not in the cocoon/xslt part
[21:28] * PeterDietz read the above as XMLUI saves lives
[21:29] <hpottinger> "not the cocoon/xslt part" LOL
[21:30] <PeterDietz> The part of the UI's that is super tricky to replicate is how complex submission and workflow is.
[21:31] <PeterDietz> Therefore, I'm tempted to promote a hybrid approach. The easy stuff can be built in a client-app, for the hard stuff, redirect to (JSP/XML) UI
[21:32] <hpottinger> good enough for a start
[21:32] <hpottinger> must wander for a moment, brb
[21:35] <hpottinger> back
[21:36] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[21:36] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[21:36] <hpottinger> whoops, left the room by accident
[21:38] <PeterDietz> thats fine, I gotta commute home. Catch you on jabber later
[21:38] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Remote host closed the connection)
[21:38] <hpottinger> ok
[21:39] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[22:00] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[22:12] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[22:12] * edInCo (~smuxi@seta.coalliance.org) Quit (Remote host closed the connection)
[23:07] * PeterDietz (~peterdiet@162-231-20-67.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[23:25] * kshepherd2 (~kim@47.72.154.177) Quit (Ping timeout: 245 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.