Timestamps are in GMT/BST.
[5:04] * PeterDietz_OSU (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (*.net *.split)
[5:04] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (*.net *.split)
[5:04] * scottatm (~scottatm@voyager114.evans.tamu.edu) Quit (*.net *.split)
[5:04] * ablemann (~alexleman@147.226.128.170) Quit (*.net *.split)
[5:04] * ianthe (~ianthe@cowu.be) Quit (*.net *.split)
[5:04] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) Quit (*.net *.split)
[5:04] * ChanServ (ChanServ@services.) Quit (*.net *.split)
[5:06] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[5:06] * PeterDietz_OSU (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[5:06] * scottatm (~scottatm@voyager114.evans.tamu.edu) has joined #duraspace
[5:06] * ablemann (~alexleman@147.226.128.170) has joined #duraspace
[5:06] * ChanServ (ChanServ@services.) has joined #duraspace
[5:06] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) has joined #duraspace
[5:08] * ianthe (~ianthe@cowu.be) has joined #duraspace
[6:51] -holmes.freenode.net- *** Looking up your hostname...
[6:51] -holmes.freenode.net- *** Checking Ident
[6:51] -holmes.freenode.net- *** Found your hostname
[6:51] -holmes.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:51] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:51] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:56] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[12:07] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) Quit (Ping timeout: 252 seconds)
[12:08] * PeterDietz_OSU (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Ping timeout: 250 seconds)
[12:15] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) Quit (Ping timeout: 240 seconds)
[12:16] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[12:21] * PeterDietz_OSU (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[12:35] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) Quit (Ping timeout: 240 seconds)
[12:36] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[13:08] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) Quit (Ping timeout: 240 seconds)
[13:08] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:16] * cbeer (~cbeer@198.147.175.203) has joined #duraspace
[13:21] * cbeer (~cbeer@198.147.175.203) Quit (Client Quit)
[13:31] * cbeer (~cbeer@198.147.175.203) has joined #duraspace
[13:31] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[14:13] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[14:15] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[15:48] * cbeer (~cbeer@198.147.175.203) Quit (Quit: cbeer)
[15:48] * cbeer (~cbeer@198.147.175.203) has joined #duraspace
[16:11] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[16:12] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[19:10] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[19:50] * bojans (~Bojmen@91.119.5.188) has joined #duraspace
[19:52] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[19:53] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) has joined #duraspace
[19:53] <tdonohue> hi all, reminder our weekly DSpace Developer meeting starts here in about 7 mins: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-14
[19:56] -Martinp23- [Global Notice] Hi folks. It's upgrades wednesday tonight - hold on tight and please keep arms and legs inside the ride at all times. To start with we'll have a bit of rehubbing, then the following servers will restart: leguin, gibson, wolfe, hitchcock and pratchett. I'll let you know when it's all done. Thanks.
[19:58] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[20:00] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:00] <tdonohue> Hi all, time for our weekly DSpace Developers Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-14
[20:01] <tdonohue> I thought we'd use today to get updates on 1.8 and also perhaps review some bugs that are still listed as "fix for 1.8.0" as well as a few which were just reported during testathon (see the agenda for the list of bugs)
[20:01] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[20:01] <tdonohue> first up though...Some folks still owe us 1.8 documentation!
[20:02] <robint> The two Richards have both promised docs
[20:02] <robint> for CC Rewrite and Sword2
[20:02] <robint> I'll chse them again, a bit more forcefully
[20:02] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (*.net *.split)
[20:02] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (*.net *.split)
[20:02] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (*.net *.split)
[20:02] * bojans (~Bojmen@91.119.5.188) Quit (*.net *.split)
[20:02] * PeterDietz_OSU (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (*.net *.split)
[20:02] * scottatm (~scottatm@voyager114.evans.tamu.edu) Quit (*.net *.split)
[20:03] * ablemann (~alexleman@147.226.128.170) Quit (*.net *.split)
[20:03] * ChanServ (ChanServ@services.) Quit (*.net *.split)
[20:03] <tdonohue> ok, cool. we also need docs from PeterDietz_OSU & kshepherd then :)
[20:03] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:03] <tdonohue> So, if you owe us docs (see agenda link) then expect that robint or I will be in touch
[20:03] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[20:03] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:03] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[20:03] * bojans (~Bojmen@91.119.5.188) has joined #duraspace
[20:03] * PeterDietz_OSU (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[20:03] * scottatm (~scottatm@voyager114.evans.tamu.edu) has joined #duraspace
[20:03] * ablemann (~alexleman@147.226.128.170) has joined #duraspace
[20:03] * ChanServ (ChanServ@services.) has joined #duraspace
[20:04] <robint> Sorry, very rude of me :)
[20:04] * mdiggory not sure I feel safe in here today...
[20:04] <tdonohue> everyone is back :)
[20:04] <aschweer> there they are again
[20:04] <robint> Welcome back !
[20:04] <mdiggory> "Services Down at irc.freenode.net"?
[20:04] <tdonohue> I said: we also need docs from PeterDietz_OSU & kshepherd then :)
[20:05] <tdonohue> also, that if you still owe us docs (see agenda link) then expect that robint or I will be in touch
[20:06] <tdonohue> Ok, I specifically wanted to ask to see if anyone has an ideas/time to spend on DS-768. From my understanding, kshepherd has gotten decently far, but he has rescheduled it for post-1.8.0 cause he needs feedback & help
[20:06] <tdonohue> https://jira.duraspace.org/browse/DS-768
[20:06] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[20:06] <tdonohue> it'd be good to finally get this fixed, if anyone can spend some time in the coming weeks. It's annoying that we cannot get XMLUI to throw a proper 404
[20:07] <hpottinger> I'm happy to run that patch on my testathon instance, someone talk me out of it :-)
[20:08] <aschweer> hpottinger: I think it sounds like a good idea
[20:08] <tdonohue> go for it!
[20:08] * mhwood tries unsuccessfully to talk him out of it
[20:08] <aschweer> to me it sounds like kshepherd is worried that his fix breaks other things (because of cocoon patches), and I guess we won't find out unless we run it
[20:09] <tdonohue> yea, I think that's right aschweer. We mainly need more testing / testers / eyes on what kshepherd has proposed
[20:10] <mdiggory> Perhaps I should take a look at this, I did recently rip apart cocoon servlet service once again
[20:10] <tdonohue> ok. sounds like we can test it out on hpottinger's test instance and see how it goes.
[20:10] <tdonohue> mdiggory: it'd be great if you could :)
[20:10] <hpottinger> will try to have it patched and running by 10pm tonight
[20:11] <tdonohue> mainly, I want to avoid having yet another release where our XMLUI just always says "200 OK" :)
[20:11] <mdiggory> We did plan to drop the code here
[20:11] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-cocoon-servlet-service-impl/
[20:12] <robint> Looks like its still just attached to the Jira issue
[20:13] <mdiggory> I beleive what we should do is dump the cocoon source under modules, commit it, patch it, release a SNAPSHOT, have testathon instances test building with the snapshot in place
[20:14] * sandsfish (~sandsfish@18.111.57.6) has joined #duraspace
[20:15] <tdonohue> i'm fine with that direction, as long as we get some more eyes on what kshepherd proposes first. I just don't want to post it to demo.dspace.org until we have some idea that it should 'work' :)
[20:15] <mdiggory> We might be better served to throw org/apache/cocoon/ProcessingException.html rather than ResourceNotFoundException, it would allow us to trap other conditions later as well.
[20:15] <mdiggory> Direct Known Subclasses:
[20:15] <mdiggory> ConnectionResetException, FormsException, InvalidContinuationException, ResourceNotFoundException
[20:17] <tdonohue> mdiggory, do you want to bring your ideas to DS-768 comments, or to dspace-devel? I think this sounds reasonable, just don't want to take up all the meeting on just this one issue (we've got many more that are still open as well)
[20:17] <hpottinger> looks like this is the patch I need to try: https://jira.duraspace.org/secure/attachment/11922/add_ResourceNotFoundException_to_xmlui_transformers.patch but willing to try something else, as long as I have a patch to apply
[20:17] <mdiggory> continue on, I'll comment in the ticket and start progress.
[20:17] <tdonohue> thanks mdiggory, sounds good! thanks for volunteering to help out
[20:18] <robint> hpottinger: You might want to liase with mdiggory to make sure you are going down the same path.
[20:18] <tdonohue> Ok, the only other topic I had for today was the list of currently open "issues" scheduled for 1.8.0 (including a few just reported for testathon, near the bottom of this list). They are embedded into the agenda at https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-14
[20:18] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (*.net *.split)
[20:18] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[20:19] <robint> Could I jump to DS-959 ?
[20:19] <tdonohue> sure, go ahead
[20:19] <robint> Ah, kompewter is absent
[20:19] <tdonohue> https://jira.duraspace.org/browse/DS-959
[20:19] <robint> Its the Tomcat 7 one
[20:20] <robint> I don't have a resolution. Would it be worth emailing the lists to get more eyes on this ?
[20:20] <robint> I think its becoming more important by the day.
[20:21] <tdonohue> yes, I see DS-959 as possibly the most important on that list. we really need to be supporting current versions of Tomcat
[20:21] <tdonohue> I don't have any ideas yet either, but maybe it is best to start a discussion on dspace-devel to see if anyone else has figured anything out
[20:22] <mdiggory> So my understanding is that on authentication tomcat initializes a new session, which causes the login eperson details to be lost?
[20:22] <tdonohue> mdiggory, correct. the SessionID changes after login, but only for XMLUI. The JSPUI works fine
[20:23] <mhwood> I already moved one to post-1.8.0. Testing framework changes aren't ready. (Ds-859) I want to get this done soon, but it's too late to go ripping up dspace-api and various POMs for 1.8.0.
[20:23] <tdonohue> thanks mhwood :)
[20:23] <mdiggory> Is there somethin set in Cocoon or int he HttpServletRequest that would trigger tomcat thinking it had authenticated?
[20:24] <tdonohue> could be... i don't know to be honest
[20:24] <tdonohue> it seems likely that it'd be something in Cocoon, since it's only affecting XMLUI.
[20:25] -Martinp23- [Global Notice] Hi folks. That's the end of today's ride. The server upgrades/restarts are complete for tonight. Please take all your belongings with you while leaving the ride. Thanks for your patience and have a good evening!
[20:25] <hpottinger> my brain is telling me that I saw similar complaints about login problems on a Cocoon-based CMS (Lenya?)
[20:27] <tdonohue> hmmm... if so, that could be a lead. well, maybe we should start this discussion back up on the dspace-devel list and try and see what we can come up with?
[20:27] <mdiggory> All I can say is that we do some pretty convoluted flips to hang onto the previous request, storing it and reconstituting it as the current request. That could throw up alarms in any Servlet Engine that was trying to be protective
[20:28] <tdonohue> i didn't realize that I guess. Maybe we need to look into doing less "flips", if possible
[20:29] <tdonohue> should we designate someone to restart this DS-959 discussion on dspace-devel? I feel like we are just "spinning our wheels" here
[20:29] <robint> I'll volunteer
[20:30] <tdonohue> (i.e. it might be good for all of us to go do some more searching around and come back with what we can find)
[20:30] <tdonohue> sounds good robint
[20:30] <mdiggory> continue, this bug needs more time
[20:30] <tdonohue> Another I wanted to highlight in that list of open issues: https://jira.duraspace.org/browse/DS-1018 (mostly cause this came as a surprise to me)
[20:31] <tdonohue> I wonder if we should discuss how we want to handle our '*-release.zip' versus our '*-src-release.zip' downloads
[20:32] <mdiggory> Yes, this was an adjustment that happened because dspace-parent dspace-xxx profiles are now activated by default, which means when these projects are absent in the dspace-release zip, having and running a dspace-parent pom will break
[20:32] <tdonohue> I had a slight worry that the current structure of the 1.8.0-rc1-release.zip would make it *harder* to switch over to the Source Release at a later date. (in that it could be more confusing)
[20:32] <mdiggory> the solution was to remove it altogether and eliminate the confusion
[20:33] <tdonohue> right, I understand the reasoning, mdiggory. I was just worrried it could actually add a different form of confusion
[20:33] <mdiggory> tdonohue: not really. just place it in the same place in the dspace-src-release
[20:33] <mdiggory> I beleive that folks will look at the directory contents and see the analog
[20:33] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:34] <tdonohue> no, that won't work. if you unzip the *-release.zip to /dspace-release, then you cannot unzip the *-src-release.zip to /dspace-release later, as you'll jumble up the directories won't you?
[20:34] <mdiggory> put dspace-release-xxxx/* into dspace-src-release-xxxx/dspace
[20:34] <mdiggory> that was never the intention
[20:34] <mdiggory> no one ever said to switch from release to src release, just unzip it on top of your current workspace
[20:35] <mdiggory> (or I never suggested doing such a thing)
[20:35] <tdonohue> ok. I can see that point.
[20:35] <mdiggory> I can see how it might seem plausable
[20:36] <tdonohue> the other issue though is what we call our directories now though... we used to just have [dspace] (install directory) and [dspace-source] (source directory). Are those still applicable if we now have *two types* of [dspace-source] directories based on what Zip you downloaded?
[20:37] <mdiggory> [sigh] but we still have to have two different sets of build instructions, even if we use the same directory structure
[20:38] <mhwood> [dspace-release]
[20:38] <mdiggory> because to build dspace-release you would need to be in dspace-release-xxx/dspace
[20:38] <mdiggory> and to build dspace-src-release you would need to be in dspace-src-release-xxx/.
[20:39] <tdonohue> mdiggory: actually we only have one set of build instructions currently (that's the heart of my question). Currently, we just say: 'run mvn package from [dspace-source]/dspace/'. But, obviously now we need two separate build instructions based on the ZIP file you chose
[20:39] <mdiggory> unless we we want to generate some alternative dspace-parent pom for the dspace-release
[20:39] <mdiggory> This comes back to why I wanted to push dspace-parent into its own module pom and not have any pom at the top
[20:40] <mdiggory> the builds would then be consistent
[20:40] <mdiggory> the adding of addon directories to you dspace-release/dspace/pom.xml would be consistent
[20:40] <sandsfish> has the idea been floated that we include a couple "install" shell scripts (.sh / .bat) so that the installation process was documented "in code" as it were?
[20:40] <mdiggory> however, we know theres a maven bug that stops this from working, and we had to drop this approach for the moment
[20:41] <tdonohue> I should step back here and just point out that I'm OK with *-src-release.zip & the *-release.zip having these separate structures, if everyone else is. But, doing so means that we need to write separate installation instructions for each (which is what I wanted to make sure was understood by all)
[20:42] <tdonohue> sandsfish: we could write a few "install" scripts. Just that no one has volunteered to do so :)
[20:42] <sandsfish> tdonohue: this should really just be a one or two liner, am i right? and if we name the install scripts the same in each distribution, these differences could be encoded in said scripts?
[20:42] <mdiggory> My goal in working on the build was to reduce complexity to the point that a platform specific build script was unneccessary
[20:43] <mhwood> It sounds like all we can do right now is document the differences. When Maven is fixed and we are ready to raise the minimum version past the bugfix then we have another fix that's less to understand.
[20:43] <robint> It is a bit untidy having seperate instructions but I think we should just live with that for the moment
[20:44] <mdiggory> An alternative is to have dspace-parent pom in dspace-release-xxx zip that does nto have profiles for the dspace-xxxx projects
[20:44] <hpottinger> I can say it threw me a bit when I went with the release tarball for 1.8.0 rc1 and didn't see the dspace folder
[20:44] <tdonohue> to be clear, we *could* likely find a way to make the *-release.zip have the same structure as the *-src-release.zip. It's just that the *-release.zip tarball would not let you run 'mvn' from the root folder (instead, you'd always need to go to [dspace-src]/dspace/)
[20:45] <mdiggory> yes we could
[20:45] <tdonohue> so, we have two choices: (1) fix the documentation, or (2) fix the tarball
[20:46] <robint> mdiggory:that sounds quite neat. Where would the binary parent pom live ?
[20:46] <tdonohue> that's why I wanted to bring this up. I wanted to be sure we were all in agreement over which direction we wanted to go
[20:46] <mdiggory> it would need to be a transform of the current one
[20:46] <mhwood> (3) Fix the documentation now; fix the packaging later when Maven is cooperating.
[20:46] <mdiggory> so we do not need to retain differences
[20:47] <mdiggory> Heres one more hypothetical....
[20:47] <mdiggory> currently we have [*-src-release.zip]/dspace/modules/ and [*-src-release.zip]/dspace-xxx
[20:48] <mdiggory> if dspace-xxx were placed under a directory from root that had its own pom.
[20:48] <mdiggory> that could use the ifFileExists activator in maven
[20:49] <mdiggory> then leaving the whole directory out would be the release build...
[20:49] <mdiggory> and then the builds would again be the same
[20:49] <tdonohue> so, something like, [*-src-release.zip]/dspace/modules/ and [*-src-release.zip]/dspace-src/dspace-xxx ?
[20:49] <mdiggory> but that requires folks accept that dspace-api / etc are in a different location now
[20:50] <mdiggory> [*-src-release.zip]/dspace/modules/dspace-api
[20:50] <mdiggory> no... soory ignore that
[20:50] <mdiggory> [*-src-release.zip]/modules/dspace-api
[20:50] <mdiggory> [*-src-release.zip]/dspace/modules/pom.xml
[20:50] <mdiggory> damn
[20:50] <mdiggory> why can't we use skype where you can edit you typos
[20:51] <mdiggory> [*-src-release.zip]/modules/pom.xml
[20:51] <mdiggory> [*-src-release.zip]/pom.xml
[20:51] <tdonohue> Another directory named "modules"? :) Though I guess that is consistent with [src]/dspace/modules/
[20:51] <mhwood> A telephone has typos?
[20:52] <tdonohue> skype text chat (IM) lets you edit your typos
[20:53] <mhwood> Maybe we need to rename the old 'modules'. We could call it 'local'....
[20:53] <mdiggory> well, its plausable that dspace/modules.... should have been called "overlays"
[20:53] <mdiggory> but thats loaded too
[20:54] <robint> "overlays" might cause some confusion with intellij overlays directories
[20:54] <mdiggory> true true
[20:54] <tdonohue> yea, true true. Just pointing out we'd then have a [src]/modules, [src]/dspace/modules/ and [src]/dspace/config/modules/ :)
[20:54] <tdonohue> I'm just noticing we like to name directories "modules" :)
[20:55] <mdiggory> well, when you checkou something from svn/repo/modules/... into your intellij project, it like that naming convention as well.
[20:55] <mdiggory> but only because we chose to call it ",odules"
[20:55] <robint> I quite like the design in general
[20:56] <robint> I'm sure we can solve the name issue if we want to
[20:56] <mdiggory> Agh... I'm trapped in "Being John Module", now every directory must be called "module"
[20:56] <tdonohue> in any case, I get your point mdiggory (no matter what we call it... if we called it [src]/modules/dspace-xxx or [src]/dspace-source/dspace-xxx or whatever)
[20:57] <tdonohue> I do like the design as well, to be honest. It puts more of a separation between [src]/dspace/ (the *assembly/build* directory) and the actual *java source* code
[20:57] <mdiggory> It would require testing before confirming.
[20:57] <robint> mdiggory: do you have the time right now ?
[20:58] <robint> Actually I could have a play around too
[20:58] <mdiggory> whats our timeframe for next release?
[20:58] <tdonohue> what do others think about these various ideas (many quiet folks here)
[20:58] <tdonohue> timeline posted on: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes
[20:58] <robint> mdiggory: next rc release ?
[20:59] <tdonohue> RC2 is tentatively scheduled for Oct 7
[20:59] <tdonohue> 1.8.0 final for Oct 21
[20:59] <mdiggory> ok, how many candidates do we anticipate needing?
[20:59] <hpottinger> I'm happy to update the documentation to match whatever we decide, just need to know how it's supposed to be. :-)
[20:59] <mdiggory> I guess that depends on how badly we can mess up a release candidate.
[21:00] <tdonohue> In the past, generally 2 RCs has been enough. But, we can always do more, if we need to work out kinks. But, the goal should still be to finish up with a 1.8.0 final around Oct 21ish
[21:00] <tdonohue> so, we can always do RC2 earlier and fit in more RCs if we wanted
[21:01] <tdonohue> the only "harder" deadline is that we've been promising 1.8.0 will be released in Oct.
[21:02] <robint> We don't need to decide this now
[21:03] <tdonohue> no, we don't. Just wanted to make sure we discussed it some, as it's potentially a larger change (depending on what we decide)
[21:03] <robint> If any of have time to test Mark's new design then we can go for another RC asap after Testathon
[21:03] <mdiggory> robint: if you want to do a first test thats fine, otherwise I will
[21:03] <tdonohue> sorry to have hijacked the meeting on DS-1018 :) Didn't mean for it to last this long, but I felt it was a good discussion
[21:04] <robint> Definitely worthwhile
[21:04] <mdiggory> ok, well on a side note.... sword and foresite release were hung up waiting for us to respond back to sonotype that we had made our first promotion from staging. I've alerted them.
[21:04] <tdonohue> I'd be willing to help test the new design (if someone else wants to post patches or create a quick SVN branch for it)
[21:05] <robint> mdiggory: Happy to have a bash
[21:05] <tdonohue> (i.e. I have time to help *test*, but likely not help *code* it)
[21:05] <stuartlewis> mdiggory: Thanks for looking after those two and getting them into maven.
[21:05] * sandsfish (~sandsfish@18.111.57.6) Quit (Quit: sandsfish)
[21:05] <mdiggory> absolutely.
[21:06] <tdonohue> Ok, last quick note: If anyone has time to help do some debugging & coding in coming weeks, please feel free to claim *any* issues on the list: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-09-14
[21:06] <mdiggory> I have been looking at the swordv2 dspace code as well... I'm hoping to make some comments/contributions if at all possible.
[21:06] <tdonohue> There are several older issues that actually have patches attached that just need some verification
[21:07] <tdonohue> in addition, we have some new bugs that have been reported already during testathon that need someone to claim & fix
[21:08] <tdonohue> (no rush on any of these --- we are still testing afterall. But, I just wanted to encourage folks to claim issues as they come in. Anything unassigned is likely not being worked on yet)
[21:08] <mdiggory> very interested in the versioning support in swordv2 because we have a different approach implemented for versioning in Dryad and I expect if we want to use SWORDv2 we are going to need to be careful.
[21:08] <robint> Sorry, but I've got to head off. Cheers
[21:09] <aschweer> I have to go to work. bye everyone
[21:09] <mhwood> I must go too. Thanks!
[21:09] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:09] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has left #duraspace
[21:09] <tdonohue> Beyond that. I hope everyone finds some time to help with Testathon! Have a good week!
[21:09] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Quit: Page closed)
[21:10] <KevinVdV> Need to go to sleep bye all
[21:10] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) Quit (Quit: KevinVdV)
[21:13] <hpottinger> tdonohue: I'm still having problems loading up the AIP for the sample community, have a sec to look at the error message?
[21:14] * keithgilbertson (~keithgilb@207.138.47.158) has left #duraspace
[21:23] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) has joined #duraspace
[21:26] <tdonohue> hpottinger: I sent you a response via email
[21:26] <hpottinger> tdonohue: thx!
[21:45] <hpottinger> kshepherd: re DS-768, does your caveat apply to the "Kim's cheap 404s" patch as well?
[21:45] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[21:47] <kshepherd> i *thought* it did.. maybe i actually fixed that problem, and then forgot that i did
[21:47] <kshepherd> hpottinger: what does your testing show?
[21:47] <hpottinger> in progress {stares at shoes}
[21:49] <kshepherd> i think yu might be onto something, the tomcat/non-cocoon error page works without caching..? i'd better re-test as well
[21:51] * hpottinger smacks his head, mumbles incoherently about maven, something about release, something something
[21:53] <hpottinger> going to have to patch my trunk checkout, then find the magic place to park it so maven will overlay it
[21:53] <kshepherd> tdonohue: still around? do you have time to quickly test the patch + new jar?
[21:54] <kshepherd> or mdiggory?
[21:55] <mdiggory> hy
[21:55] <kshepherd> hpottinger: yeah i find it easiest to keep a totally scratch trunk area lying around so i can test stuff out one change at a time ;)
[21:56] <mdiggory> hpottinger: I need to put some stuff into the svn location... or... maybe you can?
[21:56] <kshepherd> mdiggory: just making sure my patch really does throw a 404 (or whatever the correct response code is for a request) every time
[21:56] <tdonohue> kshepherd -- unfortunately I'm about to head out. But, I'll gladly help test tomorrow. Send me a note or post an update to DS-768, and I'll try to get to it then.
[21:56] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[21:56] <mdiggory> kshepherd: anythings better than whats happening now
[21:56] <kshepherd> heh
[21:57] <kshepherd> ok, since we're still in testathon, maybe the best thing is for me to get it in RC1 and see hwat happens
[21:58] <kshepherd> mdiggory: i might need some help with the mvn release of that cocoon artifact, if it turns out we still need the modified version
[21:58] <hpottinger> FYI, I am planning to just commando upgrade the cocoon jar, as per the description on Ds-768, and then patch my checkout of trunk, and manually move the file into a maven overlay folder (worried about that last bit)
[21:58] <kshepherd> (that'll be tomorrow morning for you ;))
[21:58] <mdiggory> yes, just send me the maven project, or commit it here:
[21:59] <kshepherd> hpottinger: just patch trunk, then build, then drop the jar in post-deploy.. i think that's easiest. no overlay necessary
[21:59] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-cocoon-servlet-service-impl/trunk/
[21:59] <kompewter> [ repo - Revision 6686: /modules/dspace-cocoon-servlet-service-impl/trunk ] - http://scm.dspace.org/svn/repo/modules/dspace-cocoon-servlet-service-impl/trunk/
[21:59] <kshepherd> mdiggory: ok will do
[21:59] <kshepherd> thanks
[21:59] <mdiggory> I'm just wanting the dspace-cocoon-servlet-service stuff
[21:59] <kshepherd> yep
[22:00] <mdiggory> 1.) we release the jar
[22:00] <mdiggory> 2.) your patch should adjust dspace-parent to use its new version
[22:01] <mdiggory> 3.) and adjust xmlui
[22:01] <kshepherd> yep. sounds good
[22:04] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:05] <hpottinger> kshepherd: OK, never done this before, but I'm thinking this is the jar I'm looking for? dspace-xmlui-api-1.8.0-rc2-SNAPSHOT.jar
[22:06] <kshepherd> nope, that's dspace-xmlui-api...
[22:07] <kshepherd> dspace-cocoon-servlet-service-impl is downloaded by maven during build, not compiled from the core source in trunk
[22:07] <hpottinger> hmm... trying to find the jar that has your "cheap 404s" patch in it...
[22:08] <kshepherd> but that's the existing one, so it's kinda irrelevant. you just need to drop that new one (attached to the JIRA issue) into [YOUR DEPLOYED XMLUI WEBAPP]/WEB-INF/lib
[22:08] <kshepherd> https://jira.duraspace.org/secure/attachment/11922/add_ResourceNotFoundException_to_xmlui_transformers.patch
[22:08] <kshepherd> that's the patch
[22:08] <mdiggory> you mean the dspace-cocoon-servlet-service-impl
[22:08] <kshepherd> hpottinger: sorry, i probably explained the build process badly
[22:09] <kshepherd> hpottinger: the patch i just linked to patches XMLUI. so that needs to be applied to trunk before you run "mvn package"
[22:09] <hpottinger> hmm... I've applied the XMLUI patch to my checkout of trunk, have run mvn package
[22:09] <kshepherd> the jar is a pre-built bunch of cocoon servlet stuff that has already been patched with some "dspaceisms". so that can be dropped into [xmlui]/WEB-INF/lib *after* you've built and deployed your XMLUI webapp
[22:09] <mdiggory> I recommended in the meeting using org/apache/cocoon/ProcessingException in that patch... as its more general and can be used to separate out continuation errors as well.
[22:10] <kshepherd> mdiggory: ok thanks i'll try it out
[22:11] <hpottinger> I'm not running the testathon from my trunk checout, though, I've got a copy of the release tarball I'm building from for testathon
[22:13] <kshepherd> ok well don't stress about it, i'll make sure i give it more testing today as well :)
[22:14] <mdiggory> once you guys commit the code to the scm I can run a quick SNAPSHOT release for you to test against before my end of day. But warning, I have about 45 minutes left
[22:14] <kshepherd> mdiggory: processingexception is a superclass of resourcenotfoundexceptoin?
[22:14] <mdiggory> from what I saw, yes
[22:14] <hpottinger> no worries, kshepherd, just wanted to make good on a promise to help
[22:14] <mdiggory> am I wrong?
[22:14] <kshepherd> mdiggory: heh, may as well leave it for your tomorrow, then -- i'll test and work on it in my daytime, by the time i leave here you'll be waking up
[22:15] <kshepherd> mdiggory: nope you're 100% correct
[22:16] * hpottinger gotta run pick up kids, will check back in toight
[22:17] <kshepherd> catch ya later
[22:17] <mdiggory> ok
[22:18] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[22:50] * bojans (~Bojmen@91.119.5.188) Quit (Remote host closed the connection)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.