Timestamps are in GMT/BST.
[1:51] * ksclarke (~kevin@adsl-39-51-5.clt.bellsouth.net) has joined #duraspace
[3:20] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[6:23] * ksclarke (~kevin@adsl-39-51-5.clt.bellsouth.net) Quit (Quit: Leaving.)
[6:52] -sendak.freenode.net- *** Looking up your hostname...
[6:52] -sendak.freenode.net- *** Checking Ident
[6:52] -sendak.freenode.net- *** Found your hostname
[6:53] -sendak.freenode.net- *** No Ident response
[6:53] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:53] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:53] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:03] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[7:06] * Tonny_DK (~thl@130.226.36.117) Quit (Client Quit)
[7:07] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[9:38] * Mayank (~MnzNotebu@122.173.194.133) has left #duraspace
[9:39] * Mayank (~MnzNotebu@122.173.194.133) has joined #duraspace
[9:50] * grahamtriggs (~grahamtri@62.189.56.2) has joined #duraspace
[11:46] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[11:48] * alxp (~aoneill@blk-30-155-121.eastlink.ca) Quit (Client Quit)
[13:06] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[15:24] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[15:27] * cbeer (~chris_bee@198.147.175.203) has joined #duraspace
[15:27] * cbeer (~chris_bee@198.147.175.203) has left #duraspace
[15:39] * ksclarke (~kevin@adsl-39-51-5.clt.bellsouth.net) has joined #duraspace
[18:44] * keith-noadmin (~keith-noa@207.138.47.158) has joined #duraspace
[19:29] * Jrhoads (a00a0f16@gateway/web/freenode/ip.160.10.15.22) has joined #duraspace
[19:32] <Jrhoads> Hello. This is my first time on this channel. I was wondering if there was going to be a meeting today.
[19:32] * cccharles (~chris@compy486.uoguelph.ca) has joined #duraspace
[19:33] <mhwood> Meeting should begin at 15:00 GMT+5, about half an hour from now.
[19:33] <mhwood> Excuse me, GMT-5
[19:34] <Jrhoads> Excellent. I'll be here.
[19:48] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:52] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:52] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:53] <stuartlewis> Reminder - weekly DSpace development meetingdue to start in 8 mins here in #duraspace
[19:58] * Jrhoads (a00a0f16@gateway/web/freenode/ip.160.10.15.22) has left #duraspace
[19:59] * ryscher (~chatzilla@cpe-076-182-096-130.nc.res.rr.com) has joined #duraspace
[19:59] * JosephRhoads (a00a0f16@gateway/web/freenode/ip.160.10.15.22) has joined #duraspace
[19:59] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) has joined #duraspace
[20:00] <stuartlewis> Morning / afternoon / evening all! Welcome to this week's DSpace development meeting. As usual, all are welcome, and thanks for coming along.
[20:00] <stuartlewis> Tim Donohue is away this week at the Duraspace staff retreat, so I volunteered to lead.
[20:00] <PeterDietz> are we doing a jira review too, or just cut to the main event?
[20:00] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[20:01] <stuartlewis> Yep - we'll start with 20 mins of JIRA review, and follow that by talking about the curation system, and specifically about how to manage new curation tasks.
[20:02] * richardrodgers (~richardro@dhcp-18-111-30-140.dyn.mit.edu) has joined #duraspace
[20:02] <stuartlewis> If it is OK with everyone, we'll follow last week's routine, and go back to the 2minute-per-issue routine?
[20:02] <kshepherd> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-692+ORDER+BY+key+ASC
[20:02] <kshepherd> i think that's the list we're up to
[20:02] <stuartlewis> kshepherd will post the issues, I'll sum up at the end.
[20:03] <kshepherd> https://jira.duraspace.org/browse/DS-692
[20:03] <PeterDietz> I think I was going to convert this to a curation task
[20:03] <richardrodgers> yup, my recollection also
[20:04] <kshepherd> hmm, ok, we covered last week?
[20:04] <stuartlewis> OK - so we'll leave assigned to peterdietz.
[20:04] <kshepherd> i think i loooked at the wrong chat log
[20:05] <kshepherd> sorry all
[20:05] <kshepherd> https://jira.duraspace.org/browse/DS-701
[20:05] <kshepherd> (Remove unnecessary complexity of item mapping)
[20:06] <grahamtriggs_> quick DS-692 question - could XMLUI use CDATA sections for the metadata?
[20:07] <richardrodgers> question about DS-701 - does XMLUI behave differently?
[20:08] <PeterDietz> grahamtriggs_: I recall that we _were_ able to just CDATA a block and the page would render fine. We still wanted to clean it up a bit
[20:09] <grahamtriggs_> PeterDietz: that is probably fine in a local, selective field context. But generally speaking, it's not really appropriate to say that a technical issue with the user interface must be dealt with by changing the users data
[20:10] <grahamtriggs_> there may be very good reasons why non-XHTML safe code is stored in the field
[20:10] <stuartlewis> Any more comments on 692, or shall we go to 701?
[20:11] <kshepherd> richardrodgers: testing now.. (took me a while to find it!)
[20:11] <mhwood> Agree that metadata storage and presentation are separate. Storage should not change stuff; presentation may have to.
[20:11] <richardrodgers> thanks kshepherd
[20:13] <stuartlewis> Votes?
[20:13] <stuartlewis> It looks a good issue, but needs a patch.
[20:13] <richardrodgers> yes, needs a patch
[20:13] <mhwood> DS-701 +1 needs patch
[20:13] <stuartlewis> Do we want to leave the issue open pending a patch, or close it and await a patch?
[20:14] <stuartlewis> Any votes, or we'll leave it as total = +1
[20:14] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[20:15] <robint> +1. Leave open.
[20:15] <richardrodgers> +1 with patch
[20:15] <kshepherd> +1 needs improving, but not sure how far the patch would go, etc
[20:15] <stuartlewis> OK - +4. Next issue?
[20:15] <kshepherd> xmlui seems to have a 'browse mapped items' list but i'm having trouble testing it right now
[20:16] <kshepherd> https://jira.duraspace.org/browse/DS-705 - Returning CLOBs fields data from ORACLE
[20:16] * kshepherd reminds himself to get onto that JIRA bot again
[20:17] <stuartlewis> Anyone know the reason for this? To get around a TEXT field length limitation for metadata?
[20:17] <mhwood> I'm not sure what 705 is supposed to do for us.
[20:17] <kshepherd> I can't test oracle. +0 until i see a full patch with explanation
[20:17] <richardrodgers> I'd like a bit more context for this
[20:17] <stuartlewis> 0
[20:17] <mhwood> 0
[20:18] <stuartlewis> Ok - maybe we pass on this one, and we'll put a comment in JIRA asking the submitter for more details?
[20:18] <kshepherd> https://jira.duraspace.org/browse/DS-708 - Deprecate & Remove old 'org.dspace.app.mets.METSExport' class, as it is obsolete
[20:18] <robint> +1 to 708.
[20:18] <kshepherd> +1
[20:18] <mdiggory> so, store the entire CLOB in a string?
[20:18] <stuartlewis> Looks like we should leave this one to Tim, as he knows all this, and is the submitter and assigned.
[20:19] <stuartlewis> So, +1
[20:19] <richardrodgers> agreed +1 to Tim
[20:19] <mhwood> +1
[20:19] <JosephRhoads> +1
[20:19] <mdiggory> true
[20:19] <stuartlewis> Result = +5, leave assigned to Tim.
[20:20] <kshepherd> https://jira.duraspace.org/browse/DS-715 - Unification of license treatment in xmlui and jspui
[20:20] <stuartlewis> Looks like it is just waiting for the documentation to be updated.
[20:20] <stuartlewis> Claudia says the code is committed.
[20:20] <kshepherd> mdiggory: kinda looks like that..
[20:20] <stuartlewis> Next issue?
[20:21] <kshepherd> https://jira.duraspace.org/browse/DS-716 - Add an administrative metadata schema to DSpace
[20:21] <mhwood> +1
[20:21] <stuartlewis> Hmmm.... this one needs I special meeting all to itself I think!
[20:21] <stuartlewis> Therefore, shall we finish up with the JIRA review now, and move onto our special topic?
[20:22] <mdiggory> Certainly a can of worms...
[20:22] <JosephRhoads> +1 It might. There are several issues around this.
[20:22] <richardrodgers> Yes, there are several layers of issues in this ticket..
[20:22] <mdiggory> wheres our special topic?
[20:22] <kshepherd> mm
[20:22] <stuartlewis> OK then - today's topic: Curation tasks.
[20:23] <stuartlewis> This came about as we've been writing quite a few of these locally for different purposes.
[20:23] <mhwood> Unfortunately I'm going to have to leave for another meeting, but looking forward to catching up on the log.
[20:23] <stuartlewis> Some are local and specific, some (e.g. a link checker) are useful for others.
[20:23] <stuartlewis> Thanks mhwood. Bye.
[20:23] <kshepherd> cheers mhwood
[20:23] <stuartlewis> At present all curation-related classes are in a single package.
[20:23] <stuartlewis> So a few questions:
[20:23] <stuartlewis> 1) Do we put more tasks into trunk, or store themelsewhere?
[20:23] <richardrodgers> yes - but that was not intended as a long range solution
[20:24] <stuartlewis> 2) If in dspace-api trunk, do we structure them into useful packages etc?
[20:24] <stuartlewis> 3) Curation tasks are really useful - how do we get more people to invest in them?
[20:24] <richardrodgers> I think they can be any package, and don't in general belong in dpsace-api
[20:24] <stuartlewis> 4) Should we re-write other tasks (e.g. filter-media) as curation tasks.
[20:24] <mdiggory> The ServiceManager currently allows for wiring in beans from any provided addon jar, it would have been really good to see Curation use the service manager rather than the plugin manager,
[20:25] <kshepherd> i was assuming that for custom tasks we'd package under our own, custom name, eg. nz.ac.auckland.library.dspace.tasks
[20:25] <stuartlewis> So - any views on question 1?
[20:26] <mdiggory> In fact, I've been really pushing that tools that are wired via the pluginmanager get shifted to use ServiceManager... then you could do a great deal more in terms of aligning curation tasks, fitlermeda tasks and job scheduling
[20:26] <stuartlewis> (I'm thinking here about generic tasks we've written, like an extenisble link checker - it can be extended by overriding the methods to find links, and to check them for whatever you define as validity)
[20:26] <mdiggory> stuartlewis: that me expressing my view, they do not need to be in trunk... even with PluginManager
[20:27] <mdiggory> 2) I'm for breaking dspace-api into functional units that exemplify how to write your own non-trunk addons
[20:27] <stuartlewis> But is it easier if we do put them in dspace-api for now, and have the wired up any way that is best?
[20:27] <stuartlewis> Or should we put them elsewhere? dspace-curation ?
[20:28] <robint> I think we are conflating two issues.
[20:28] <mdiggory> problem with cramming everything under trunk/dspace-api is we continue to introduce entangled dependencies
[20:28] <robint> One is how/when to seperate out the curation sub-system from dspce-api
[20:29] <richardrodgers> I'd really like to get them out of dspace-api - that was done because we didn't have async add-on process ready for 1.7
[20:29] <robint> And the other is whether individual tasks have to live in the same place
[20:29] <richardrodgers> robint: the *framework* belongs in dspace-api, just not the tasks
[20:30] <robint> richardrodgers: Not sure I agree. Why not a Curation Service ?
[20:30] <richardrodgers> the framework = the API classes and the runtime support code
[20:30] <mdiggory> richardrodgers: I think I finally identified the problem point with that. I'm preparing such detail to be in the proposal.... but we need interfaces and services on the DSpaceObjects and find calls so we can effectively break the dependencies on dspace-api version releases inside the trunk.
[20:31] <mdiggory> this reflects back to DOI work that was ongoing in 2007 as well
[20:32] <PeterDietz> Is there any merit to storing curation tasks in something like: http://wordpress.org/extend/plugins/get-recent-comments/installation/
[20:32] <mdiggory> But I'm not fully convinced that the Curation Service framework needs to stay in dspace-api, just that it is dependent on a project that exoses an api for DSO's
[20:32] <kshepherd> the servicemanager vs pluginmanager thing is a fair debate to have... but we're always talking about this, and there's still no clear written guideline showing us how to play nicely. perhaps someone (mdiggory? :)) could port Curation to servicemanager and write it up as a tutorial/guide to be used as an example for hte rest of us?
[20:32] <mdiggory> which at the moment is dspace-api
[20:32] <mdiggory> kshepherd: Think you just hit on my OR proposal ;-)
[20:34] <mdiggory> Ok Ok Ok, sorry if I created divergent threads.... At the moment I agree that Curation Framework being in dspace-api is ok, but that other projects can provide their own addons with curation tasks in them
[20:34] <richardrodgers> my point was that the framework is quite distinct from the task implementations - it's another question whether dspace-api is the right artifact, I agree
[20:34] <mdiggory> without using ServiceManager, you have to hand edit the dspace.cfg to add them into the PluginManafer
[20:35] <mdiggory> if we migrated to the ServiceManager, they would automatically get registered when you added the maven dependency on the addon
[20:35] <richardrodgers> actually, no mdiggory - I extended PluginManager
[20:35] <mdiggory> great...
[20:35] <mdiggory> howso?
[20:36] <richardrodgers> It takes an optional module name-space, just like ConfigurationManager
[20:37] <richardrodgers> public static Object getSinglePlugin(String module, Class interfaceClass)
[20:37] <richardrodgers> throws PluginConfigurationError, PluginInstantiationException
[20:37] <mdiggory> what does that do then? I mustve missed this in the release documentation.
[20:37] <kshepherd> so, given that we're going with pluginmanager for now, is something like org.dspace.curate.tasks a good package path to use, so we separate sample/generic tasks from code?
[20:38] <grahamtriggs_> I'm not convinced by 'automatically registering' - it's great when it works, and a major headache when it doesn't. I don't see there is anything wrong with having things configured, just not in the mess of dspace.cfg (rather, in a spring context)
[20:38] <mdiggory> ok, I have to throw up the red flags here... we need to get a clear roadmap on the direction we should be going in with these subsystems.
[20:40] <grahamtriggs_> what I'm finding quite nice in the webmvc work is the use of annotations to define the controllers - I can set the context to scan for them and create them automatically, or I can leave the scan out and create bean instances manually. The annotations will still be processed and hooked in either way
[20:41] <richardrodgers> Actually, I think the Plugin/Configuration issues are distinct from how to position/distribute tasks, which was where we started?
[20:41] <mdiggory> grahamtriggs: thats all well and good, sure we can do similar in Spring in the ServiceManager if we wanted... but at the moment we currently autowire to bring together the services, including those providers that some of the services use.
[20:42] <mdiggory> richardrodgers: not if it relies on customization made to the Plugin manager to define what packages those tasks are looked in
[20:42] <stuartlewis> For now, would there be any objections to restructuring the curation package slightly, and committing generally useful tasks? These can then be ported later once the the wider discussion is sorted?
[20:43] <kshepherd> (and maybe porting filter-media, checksum-checker, etc)
[20:43] <robint> +1 to committing generally useful tasks. The user community would thank us for it.
[20:43] <mdiggory> I will say if you begin porting these other classes, we need to be very careful about the design
[20:43] <kshepherd> arch stuff aside, curation tasks are awesome :)
[20:44] <stuartlewis> kshepherd: +1
[20:44] <robint> kshepherd: another +1
[20:44] <mdiggory> at this point most everything under org.dspace.app could be dropped into a separate maven project with a dependency on dspace-api... if we loose that it will impact some of the planning for the async release
[20:44] <stuartlewis> We had a meeting with our repo managers last week, and our answer to most of their requests was "We should write a curation task for that".
[20:45] <stuartlewis> More maven modules = even slooooower build times :(
[20:45] <richardrodgers> they get addictive, don't they?
[20:45] <mdiggory> not if your not building theme every time.
[20:45] <kshepherd> i used to take the bus to work
[20:45] <kshepherd> now i come by curation task
[20:46] <mdiggory> problem is everone still thinks they "need to build dspace-api .... dspace--xmlui-webapp.... to construct the distribution.... stop doing that and suddenly your build is much shorter
[20:46] <hpottinger> kshepherd: do you have some of these tasks written up somewhere we could take a look?
[20:46] <robint> stuartlewis: you could argue that separating out modules allows you to drop the stuff you dont want locally
[20:47] <mdiggory> robint: bingo
[20:47] <kshepherd> hpottinger: the stuff we've been doing at UoA needs a loittle bit of polish, but we'll be sure to share soon
[20:47] <stuartlewis> mdiggory: A blog post about how to easily do that would be very welcome :)
[20:47] <mdiggory> modules mean I only assemble those features I want...
[20:47] <richardrodgers> yea, maybe we should put a spot where people can share what they are working on
[20:48] <mdiggory> I don't need a blog... just use dspace-release instead of dspace-src-release and your good to go....
[20:48] <mdiggory> then you just write your own modules that addon the stuff you want...
[20:49] <mdiggory> even to do the oh so horrid classpath overrides...
[20:49] <stuartlewis> But does that only affect time for punters? I'm worried about build time for developers.
[20:50] <grahamtriggs_> buy an i5 or better
[20:50] <kshepherd> heh
[20:50] <stuartlewis> I have an MBP with fast disk, but still takes a minute or two to build :(
[20:50] <mdiggory> well, with unit tests in the modules we write, we only doa full build and deploy if we are altering the install derectory somehow...the rest of the time we are just debugging and Unit testing in IDEA...
[20:51] <mdiggory> only do full builds to accomplish a complete integration test
[20:51] <mdiggory> so even as developers... modularity pays off
[20:51] <stuartlewis> We're going off topic though... :)
[20:52] <stuartlewis> So... are there any conclusions?
[20:52] <mdiggory> you asked ;-)
[20:52] <stuartlewis> 1) For now, we can commit useful general tasks to trunk
[20:52] <mdiggory> +1
[20:52] <stuartlewis> 2) Curation system might be usefully modularised as a later date.
[20:52] <mdiggory> +1 to commiting ones work that is
[20:52] <richardrodgers> +1 I'd bee n playing with a naming scheme as follows:
[20:52] * mdiggory early and often
[20:52] <stuartlewis> 3) Some publicity about the usefulness of curation tasks would be good.
[20:53] <richardrodgers> org.dspace.ctask.x where x was a 'family' type
[20:54] <stuartlewis> richardrodgers: That is similar to what we'd been thinking, e.g. x = linkchecker
[20:54] <richardrodgers> stuartlewis: I might still revive my contest - a new IPhone (or whatever) for best task by 1.8 (as voted by community)
[20:55] <kshepherd> cool idea
[20:55] <mdiggory> iPad 2....
[20:55] <stuartlewis> Android? ;)
[20:55] <richardrodgers> OK mdiggory I agree IPad2 is way better.....
[20:55] <mdiggory> since its the device no one needs but everyone wants
[20:56] <stuartlewis> OK - time is almost up. Any further comments?
[20:57] <mdiggory> Can't seem to locate an Android tablet I don't have to get a subscription with in the US....
[20:57] <PeterDietz> Contest needs a user submitted directory/gallery. Would it be better to built a one-off webapp (i.e. rails), or eat some dog-food and have users submit their task to demo.dspace ?
[20:58] <mdiggory> Comment: please please please think about using ServiceManager before you start designing your solutions....
[20:58] <stuartlewis> mdiggory: Could you write and document an example for us to follow?
[20:58] <kshepherd> PeterDietz: we can show them off in dspace :) was it you that made that nice-looking xmlui gallery?
[20:59] <mdiggory> Discovery is the example.... so is dspace-stats... but perhaps we can improve this a-little so your not having to look directly at code...
[20:59] <stuartlewis> OK - well, time is up. As always, thank you for coming, and thank you for your valued input.
[20:59] <stuartlewis> Next meeting - same time, same place, next week.
[20:59] <mdiggory> Kudos thanks for leading in Tim's absence
[21:00] <stuartlewis> No problem.
[21:00] <richardrodgers> thanks stuartlewis
[21:01] <kshepherd> perhaps some updating/padding out to https://wiki.duraspace.org/display/DSDOC/DSpace+Services+Framework
[21:01] <mdiggory> little outdated...
[21:01] <mdiggory> but still true
[21:01] <robint> Thanks stuartlewis, time for tea. Cheers.
[21:01] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[21:02] <mdiggory> I've limited use of the calls to the "DSpace" object in favor of using Spring directly for wiring services.
[21:03] <JosephRhoads> Thanks stuartlewis for hosting.
[21:03] <richardrodgers> thanks all, bye
[21:03] * richardrodgers (~richardro@dhcp-18-111-30-140.dyn.mit.edu) Quit (Quit: richardrodgers)
[21:03] <kshepherd> cheers all
[21:05] <mdiggory> Ok... I'm going to write up some good example here that uptodate.
[21:05] <mdiggory> but we need to think about if this will go int he docs or the wiki initially.
[21:06] * keith-noadmin (~keith-noa@207.138.47.158) Quit (Read error: Connection reset by peer)
[21:06] * keith-noadmin (~keith-noa@207.138.47.158) has joined #duraspace
[21:08] <mdiggory> We need to work on keeping this advertised and uptodate...
[21:08] <mdiggory> https://wiki.duraspace.org/display/DSPACE/Modules
[21:22] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) Quit (Quit: Page closed)
[21:28] * JosephRhoads (a00a0f16@gateway/web/freenode/ip.160.10.15.22) has left #duraspace
[21:48] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs_)
[22:03] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[22:47] * ksclarke (~kevin@adsl-39-51-5.clt.bellsouth.net) Quit (Ping timeout: 252 seconds)
[22:48] * ksclarke (~kevin@adsl-39-51-5.clt.bellsouth.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.