Timestamps are in GMT/BST.
[0:15] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[0:58] * snail (~stuart@130.195.179.88) has left #duraspace
[1:06] * snail (~stuart@130.195.179.88) has joined #duraspace
[3:07] -barjavel.freenode.net- *** Looking up your hostname...
[3:07] -barjavel.freenode.net- *** Checking Ident
[3:07] -barjavel.freenode.net- *** Found your hostname
[3:07] -barjavel.freenode.net- *** No Ident response
[3:07] [frigg VERSION]
[3:08] * DuraLogBot (~PircBot@ec2-75-101-201-223.compute-1.amazonaws.com) has joined #duraspace
[3:08] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[3:08] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[3:13] * Disconnected.
[3:13] -barjavel.freenode.net- *** Looking up your hostname...
[3:13] -barjavel.freenode.net- *** Checking Ident
[3:13] -barjavel.freenode.net- *** Found your hostname
[3:13] -barjavel.freenode.net- *** No Ident response
[3:13] [frigg VERSION]
[6:40] -barjavel.freenode.net- *** Looking up your hostname...
[6:40] -barjavel.freenode.net- *** Checking Ident
[6:40] -barjavel.freenode.net- *** Found your hostname
[6:41] -barjavel.freenode.net- *** No Ident response
[6:41] [frigg VERSION]
[6:41] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:41] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:41] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[6:41] -barjavel.freenode.net- [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
[6:50] * Tonny_DK (~thl@nat-ansatte.cbs.dk) has joined #duraspace
[6:55] * Tonny_DK (~thl@nat-ansatte.cbs.dk) Quit (Quit: Leaving.)
[6:56] * Tonny_DK (~thl@nat-ansatte.cbs.dk) has joined #duraspace
[7:07] * Tonny_DK1 (~thl@130.226.36.117) has joined #duraspace
[7:10] * Tonny_DK (~thl@nat-ansatte.cbs.dk) Quit (Ping timeout: 240 seconds)
[9:01] * robint (81d7473d@gateway/web/freenode/ip.129.215.71.61) Quit (Quit: Page closed)
[9:31] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[12:05] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:27] * Tonny_DK1 (~thl@130.226.36.117) Quit (Quit: Leaving.)
[13:28] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[13:32] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:33] * ksclarke1 (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[13:35] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[13:43] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:01] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[14:02] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[14:04] * ksclarke1 is now known as ksclarke
[14:16] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[14:18] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[19:51] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:53] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[19:55] * cccharles (~user@131.104.62.55) has joined #duraspace
[19:58] <tdonohue> DSpace Developers Mtg will start here in a few minutes. Today's general agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-09-29
[19:58] * phnglui (~JamesRuss@131.187.102.6) has joined #duraspace
[20:00] <tdonohue> Ok, looks like it's top of the hour. So we may as well get started with the DSpace Developers Mtg
[20:00] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:01] <tdonohue> First up is a JIRA review -- here's a link to recent issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-13w&assigneeSelect=&sorter/field=created&sorter/order=ASC (We'll be starting shortly with DS-624)
[20:01] * gilbertsonk (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[20:01] <tdonohue> Cocoon "Malformed stream" error when submitting large files from IE : http://jira.dspace.org/jira/browse/DS-624
[20:02] <kshepherd> i recall a mailing list thread about this, too, but i've not encountered it myself
[20:03] <tdonohue> Yea, this does seem familiar to me as well -- anyone have thoughts on this, or want to volunteer to look into?
[20:03] <mhwood> Needs more information: Cocoon logs
[20:03] * sandsfish (~sandsfish@dhcp-18-111-1-134.dyn.mit.edu) has joined #duraspace
[20:03] <kshepherd> dspace-tech thread: http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg11127.html
[20:03] <kshepherd> (not much more info than the jira issue though)
[20:03] * JohnDavison (83bb6605@gateway/web/freenode/ip.131.187.102.5) has joined #duraspace
[20:03] <richardrodgers> seems like it should be investigated
[20:04] <tdonohue> aha, I do recall this -- to me, at the time, it seemed as though it was a "timeout" problem (the upload timed out, and cocoon threw an ugly error which made little sense). But, I never was able to get it to happen on my end
[20:05] <tdonohue> any volunteer to followup and/or investigate/test further?
[20:06] * kshepherd is just quickly trying to reproduce now
[20:07] * jc_OL (83bb420f@gateway/web/freenode/ip.131.187.66.15) has joined #duraspace
[20:07] <tdonohue> DS-624 -- keep open for now, needs a volunteer. Tim will add a comment to issue about our discussion
[20:07] <kshepherd> the instructions from the email as to how to reproduce (not yet tried by me):
[20:07] <kshepherd> >>>> *. Log as dspacedemo+ad...@gmail.com
[20:07] <kshepherd> >>>> *. Access to "01 - OR2010 Collection 2" collection.
[20:07] <kshepherd> >>>> *. Submit a 13Mb file only specifying "title" (mandatory field).
[20:07] <kshepherd> (that collection's gone now, but that shouldn't be relevant)
[20:08] <tdonohue> Ok -- I thought I had tried that back then and was unable to reproduce (later on in email thread) -- but, it still could use more analysis
[20:09] <tdonohue> I'm gonna move on for now -- but, help testing DS-624 is welcome -- need to reproduce it
[20:09] <tdonohue> API for exchange of Usage Data over OAI-PMH or SUSHI : http://jira.dspace.org/jira/browse/DS-626
[20:10] <kshepherd> i'll volunteer if i can reproduce and actually think i'm capable of fixing :P
[20:10] <PeterDietz> looks like this was posted during OR'10
[20:10] <kshepherd> (re 624)
[20:10] <tdonohue> kshepherd -- ok, how about I assign DS-624 to you, and you can comment on what you find initially -- we can reassign later if necessary
[20:10] <richardrodgers> looks fine - but I'm not sure what the ticket wants..
[20:10] <kshepherd> tdonohue: yep that's fine
[20:10] <mhwood> Wants for someone to implement it.
[20:11] <PeterDietz> We all have our own usage statistics, perhaps being able to implement OAI on top, so a stats-engine, can looks at federated usage stats
[20:11] <richardrodgers> OK, it wasn't clear that it was a new API design wanted, not impl
[20:12] <PeterDietz> so this is an available project for an eager developer out there
[20:12] <kshepherd> solr-stats data is very easy to surface in any shape or form we like, so this shouldn't be *too* much work
[20:12] <tdonohue> So, should we just keep DS-626 open for now, and keep searching for a volunteer to implement? Unless anyone here is interested?
[20:13] <kshepherd> i don't know anything about the standard referred to though
[20:13] <mhwood> Yes, let's keep it open. I agree with the poster that this is worth looking into.
[20:14] <tdonohue> DS-626 -- keep open for now & unscheduled . we need a volunteer to investigate and/or implement
[20:14] <tdonohue> Documentation refers to install-configs script : http://jira.dspace.org/jira/browse/DS-627
[20:15] <PeterDietz> Sidenote: As of 1.6 we've considered /bin/ scripts to have been deprecated, so its just pulling the plug on them, then to update docs (and what we say in dspace-tech)
[20:15] <tdonohue> yuck -- that's definitely a mistake in the docs.
[20:15] <richardrodgers> +1 for 1.7 doc
[20:15] <mhwood> +1
[20:15] <kshepherd> +1
[20:15] <tdonohue> +1 for 1.7
[20:16] <gilbertsonk> +1
[20:16] <PeterDietz> Motion carries
[20:16] <tdonohue> Anyone want to draft up a better version of these docs section, or better yet, fix it in our new Wiki-based docs? Otherwise, I'll just assign to Jeff Trimble to see if he can find someone
[20:17] <tdonohue> DS-627 -- assign to Jeff Trimble for 1.7, he may or may not need some help replacing these areas of docs
[20:17] <tdonohue> Make the timeout for the extended resolver dnslookup configurable : http://jira.dspace.org/jira/browse/DS-628
[20:18] <gilbertsonk> +1
[20:19] <PeterDietz> +1, I've personally needed to do this (hard coded) during stats import
[20:19] <tdonohue> +1, this seems like a logical fix, and relatively small change.
[20:19] <mhwood> +1
[20:20] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[20:20] <tdonohue> anyone want to volunteer to do a quick test and commit it for 1.7?
[20:20] <kshepherd> do we want a "no lookup, addresses only" configuration option too?
[20:20] <kshepherd> oh, it's reverse
[20:20] <PeterDietz> The patch looks good, would claudia want it assigned to her?
[20:21] <tdonohue> sure, we can assign to Claudia and just ask her to commit it
[20:21] <tdonohue> DS-628 : assign to Claudia -- approved for committing to Trunk
[20:22] <tdonohue> Question for DS-628 actually -- do we want to change the default here? if 20ms is problematic on most systems, why not change it?
[20:23] <tdonohue> (noticed the patch has the config set to 20ms in dspace.cfg)
[20:24] <PeterDietz> Its been a few months since my SOLR days, I'm not sure I know best
[20:24] <mhwood> That makes sense. 200ms?
[20:25] <tdonohue> it looks like Claudia is suggesting it should normallly be set to 2000-5000ms (2-5 secs).
[20:26] <mdiggory> The Solr client uses apache HTTPClient and farms out async threads from a pool for each request. I suspect there will be a threshold where the pool will get exhausted on significant loads. So there will be a trade off, do not set this too high.
[20:26] <mhwood> What happens at high request rates if many are timing out?
[20:26] <mhwood> Wow, asnwered before asked!
[20:26] <tdonohue> mdiggory -- any suggestions as to what it should be set to then? does 20ms make the most sense, or 200ms (I'd just like to determine what is a reasonable default for "most people")
[20:27] <mhwood> We may have to just pick something and see how it works in the field, unless there are data already.
[20:28] <kshepherd> how it works during an intense crawl will be quite different to how it works in a quiet time, so it might not be immediately apparent, either
[20:28] <tdonohue> ok -- we'll leave at 20ms then for now, I guess. I wasn't sure if anyone here had more experience with this and already had to "bump it up" (similar to Claudia)
[20:28] <tdonohue> Let's do one last JIRA issue...
[20:28] <tdonohue> Wrong Parameter Name in web.xml comment : http://jira.dspace.org/jira/browse/DS-631
[20:28] <mdiggory> bump it up to 200, if we see continued cases, then bump it up further
[20:29] <tdonohue> mdiggory -- ok. For DS-628 assign to claudia and ask her to bump to 200ms for default. Commit to trunk
[20:30] <tdonohue> DS-631 seems like it should just be committed, if this parameter is indeed wrong
[20:30] <richardrodgers> agreed
[20:30] <kshepherd> +1
[20:30] <tdonohue> volunteer to double-check DS-631 & then commit it?
[20:31] <mhwood> +1, volunteering
[20:31] <tdonohue> ok -- assign DS-631 to mhwood to analyze & commit
[20:31] <tdonohue> we'll stop there for today! On to 1.7 discussions, starring PeterDietz :)
[20:32] <PeterDietz> Following JIRA review is a status update on 1.7
[20:33] <PeterDietz> I don't have any "behind the scenes" 1.7 updates to share, hence behind the scenes, but I would like to get a pulse of how far along things are and, that you all are on track to get things in by freeze dates.
[20:33] <PeterDietz> So, ... If you need help, ask around, someone might be able to spare a few dev cycles.
[20:33] * tdonohue notes the "freeze date" for features is Oct 22 -- 3 weeks from Friday
[20:34] <PeterDietz> Do we want to do a progress report check?
[20:34] <tdonohue> sure -- seems logical to open it up to updates from anyone working on big features
[20:34] <PeterDietz> ok, this should be open ended, no prodding from me
[20:34] <richardrodgers> Curation looks like it will be ready - I just posted a writeup https://wiki.duraspace.org/display/DSPACE/CurationSystem which I encourage all to read & critique
[20:35] <richardrodgers> WIthin a day, all the code should be in the branch, so people can check it out & give it a spin
[20:35] <tdonohue> richardrodgers -- cool! is there a link to the code that we can put on that page?
[20:36] <tdonohue> oh -- you answered before I even asked...thanks :)
[20:36] <richardrodgers> tdonohue: good point, I'll add that link
[20:37] <tdonohue> I noted in the agenda that my plan is to swap out our License headers for 1.7 (with the smaller new DuraSpace header). Not a feature, but I hope to have this done *before* Oct 22, if possible
[20:38] <mdiggory> tdonohue: we can add that into the maven pom and do it just prior to the first release candidate
[20:39] <tdonohue> mdiggory -- ok. that'd work to, if that's easiest
[20:39] <tdonohue> mdiggory -- speaking of which, how is the maven work going? is the plan to get your maven reorg work into 1.7? Is there help you need?
[20:40] <mdiggory> update the license header you want here http://scm.dspace.org/svn/repo/licenses/LICENSE_HEADER
[20:40] <mhwood> Header text needs year range updated.
[20:41] <tdonohue> I'll update the License Header in SVN -- the new one actually doesn't have a year range, if you recall (this was all discussed before OR10 -- see http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg03587.html )
[20:42] <mdiggory> Maven reorg work is probably in need of a few more eyes. Our largest challenge is in what the final goal is for 1.7 rather than thinking longer term
[20:43] <mdiggory> for 1.7 the current goal is to shift dspace-xxx resources to a release process separate from the "dspace" assembly/config directory
[20:43] <tdonohue> mdiggory -- do you want to point us to work/writeup that specifically "needs more eyes"?
[20:44] <mdiggory> It is still in need of more complete documentation, but when ready I will post a link
[20:44] <tdonohue> sounds good to me
[20:45] <tdonohue> Any other updates from anyone? Is our 1.7 possible features listing still "mostly accurate"? https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.7.0+Notes
[20:46] <tdonohue> (obviously feel free to update that list yourself, as needed)
[20:46] <richardrodgers> I'm behind on the 'CGI' stuff - it is a stretch goal for 1.7 ATM
[20:47] <sandsfish> i'm currently working on extending the implementation for google scholar to select a representative PDF for inclusion in the metadata, as it turns out Google Scholar is not interested in seeing their metadata schema unless they have an artifact to point to via URL. this is challenging considering the heterogeneous nature of DSpace items (compared to something like ePrints).
[20:47] <PeterDietz> I don't have any progress on user being able to login from any page (and stay on that page).
[20:47] <PeterDietz> sandsfish: is the pdf not living in the same "subfolder" a blocker for GScholar?
[20:48] <tdonohue> richardrodgers: OK -- good to know (If anyone else is very interested in the CGI work, feel free to volunteer to help out! https://wiki.duraspace.org/display/DSPACE/CGIProposal )
[20:49] <sandsfish> PeterDietz: there is a specific metadata tag in their meta-tag schema called "citation_pdf_url", which they expect to link directly to a representative PDF of the item, otherwise, even with the rest of the metadata present, their search results cannot send a user/searcher to an artifact (using the item URL here apparently falls short of their desires).
[20:50] <sandsfish> i'll update on the list with my progress.
[20:50] <tdonohue> sounds good
[20:51] <PeterDietz> sandsfish, pdf_url "must refer to a file in the same subdirectory as the HTML abstract"
[20:53] <tdonohue> We had one last agenda item -- it sounds like the 1.7 updates are done
[20:53] <sandsfish> PeterDietz: considering the obscured nature of "subdirectories" in webapp url translation, i'm not sure how much we need to conform to that. i will look into it.
[20:53] <mdiggory> PeterDietz: the s
[20:53] <mdiggory> PeterDietz: the same exact subdir?
[20:53] <tdonohue> Did we want to move on to any Maven Dependency discussions needed? This highly involves mdiggory and sandsfish, from this thread: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg04035.html
[20:53] <mdiggory> or any underneath it?
[20:54] <mdiggory> So it would need to be... /handle/1234.5/67890/foo.pdf
[20:55] <PeterDietz> I don't feel we need to bow to gScholar, hopefully, subdir.domain.com/handle AND subdir.domain.com/bitstream both having same domain / subdomain is what they meant
[20:55] <tdonohue> isn't MIT talking directly to the Google Scholar folks? Seems like this could be a question you could just ask them, if it is unclear
[20:55] <mdiggory> but subdirectory is not subdomain
[20:56] <richardrodgers> yep we (Sands) are tdonohue
[20:56] <sandsfish> tdonohue: yes, i will check with them directly.
[20:56] <tdonohue> excellent.
[20:57] <tdonohue> mdiggory & sandsfish, was there anything we need to discuss about the Maven Dependency thread going on on dspace-devel?
[20:57] <sandsfish> tdonohue: as far as the maven dependency discussion goes, i think my prevailing concern is that if institutions use maintenance branches, they will be building with transient snapshot releases. mdiggory, is this the case?
[20:58] <mdiggory> I do not think if you use 1.6.0-SNAPSHOT, that you will get 1.7.0-SNAPSHOT artifacts, if that is what you mean
[20:59] <sandsfish> if i check out the 1_6_x branch and built with it, i will be building with dependencies that are not "release", that is my understanding and concern.
[21:00] <mdiggory> but yes, a maintenance branch will have "SNAPSHOT" identified in it. If the intention is to be able to increment and restrict to a specific maintenance svn revision, then we would almost need to release every ssingle commit
[21:01] <tdonohue> that's correct. e.g. If you had checked out the 1_6_x branch between the 1.6.1 and 1.6.2, you would have been building based on '1.6.2-SNAPSHOT' (i.e. code that is between releases)
[21:01] <mdiggory> there should probably be a rule that a maintenance branches do not use SNAPSHOT dpendencies outside the core dspace-xxx projects
[21:02] * robint (5229fd08@gateway/web/freenode/ip.82.41.253.8) has joined #duraspace
[21:02] <sandsfish> i think the important thing here is to have a well-documented understanding of the dependency resolution process. i'll try to document what i know and perhaps it will be filled out as other eyes are on it.
[21:03] <mdiggory> And by what I state, I mean that the branch should be made from the 1.6.0 tag and not the trunk
[21:03] <mdiggory> because the tag will have all snapshot dependencies resolved
[21:03] <tdonohue> sandsfish: that sounds like a good route forward -- hopefully we can clarify & improve our maven and/or svn branch processes as needed
[21:04] <tdonohue> mdiggory: that process would be worth investigating and changing as necessary
[21:04] <sandsfish> mdiggory: that seems to be a good way to ensure more consistent builds from those branches.
[21:05] <mdiggory> tdonohue: that's correct. e.g. If you had checked out the 1_6_x branch between the 1.6.1 and 1.6.2, you would have been building based on '1.6.2-SNAPSHOT' (i.e. code that is between releases) <--- IMO that means your getting whatever the last 1.6.2-SNAPSHOT artifact deployed int he SNAPSHOT repo is.
[21:06] <sandsfish> i would still recommend that we don't declare repositories anywhere except for the parent POM. i don't know of any projects that don't explicitly reference the parent POM, so you'd still be able to build individual projects. it would make it easier to make adjustments and also for institutions to configure their own local repositories in one place.
[21:06] <tdonohue> mdiggory -- yea, that would be wrong, and we do need to resolve that
[21:06] <mdiggory> tdonohue: is it worng?
[21:07] <mdiggory> you would need to publish artifacts for each and every commit to do otherwise
[21:07] <tdonohue> mdiggory -- well, it is now, as we don't actually tend to deploy snapshots (we don't have something automated like bamboo)
[21:07] <mdiggory> I know I instituted a policy of using maintenance branches at MIT rather than tags, I have a tendency to suggest otherwise now days. It may actually be that practice that is not appropriate
[21:08] <mdiggory> and not "conventional" form a Maven standpoint
[21:08] * tdonohue notices we're over time here
[21:09] <mdiggory> sandsfish: the snapshot repo definition in all the poms is there to assure you can get to the artifacts if you want to build that project individually without checking out the entire branch
[21:09] <tdonohue> mdiggory -- not sure I understand that stmt (but, then again, I don't know MIT's policies)
[21:09] <richardrodgers> I have to run, but I can't escape the feeling that we are conflating different use cases here - that of a user downloading/deploying vs developers checking out of branches
[21:10] <sandsfish> tdonohue: i'll get some skeleton documentation up on the wiki and we can use that as a framework for the continuation of the discussion.
[21:10] <mdiggory> richardrodgers: tdonohue it has to do with having a clean dev, test, prod deployment setup
[21:10] <mdiggory> tags should be used for test and prod, branches for dev
[21:10] <sandsfish> mdiggory: if the project references the parent POM (almost all do) you don't need the repository declarations locally.
[21:11] <tdonohue> sandsfish -- there would be appreciated. I think we may all be misunderstanding one another in some way
[21:11] <mdiggory> not if the parent pom is not resolvable in the file system at that time
[21:11] <mdiggory> it needs to then be published somewhere, that is why the repo reference is in all the poms
[21:11] <richardrodgers> got to run, I'll read the transcripts - thanks all
[21:11] <tdonohue> All --feel free to head out if you need to. Consider the meeting closed. (though, I'll stick around if mdiggory & sandsfish still want to continue this discussion)
[21:11] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:12] <mhwood> I too must go, will catch up later. Thanks!
[21:12] <sandsfish> (this all screams for some best/recommended practices documents.) :)
[21:12] <tdonohue> +1 sandsfish -- we need more documented best practices
[21:12] <mdiggory> so that the parent can be resolved independently, which is actually a practice used...
[21:13] <mdiggory> if you look in the modules directory, this whole issue is aleviated because parents are versioned and released independently of the children they are used in
[21:13] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:13] <sandsfish> mdiggory: ...though, anyone that has done a build locally will have the dspace-parent POM in their local repo.
[21:13] * robint (5229fd08@gateway/web/freenode/ip.82.41.253.8) Quit (Quit: Page closed)
[21:13] * JohnDavison (83bb6605@gateway/web/freenode/ip.131.187.102.5) Quit (Quit: Page closed)
[21:13] <mdiggory> doesn't matter and shouldn't be relied on
[21:14] * jc_OL (83bb420f@gateway/web/freenode/ip.131.187.66.15) has left #duraspace
[21:15] <mdiggory> Maven builds should always be designed such that they would execute with a fresh checkout of all the artifacts
[21:15] <sandsfish> it's a question of if it is worth lots of duplication and difficulty if those settings are desired to be changed.
[21:15] <mdiggory> if there is a dependency on install artifacts in your local repo first, that creates some serious problems.
[21:15] * phnglui (~JamesRuss@131.187.102.6) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
[21:16] <mdiggory> anyhow this is a moot point because the work I'm trying to do now, breaks the parent off into its own release versioning and so that your not dependent on have those definitions there.
[21:17] <sandsfish> is this new versioned parent going to be one common parent used by the core, and the modules, and any other dspace project?
[21:17] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-pom/
[21:18] <sandsfish> so for instance, the main dspace project, the spring services framework, and the modules will all use this one parent, such that one change affects them all?
[21:18] <mdiggory> with separate tag releases
[21:18] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-pom/tags/
[21:20] <mdiggory> Think of it more like, the parent has a release cycle that is only ever "major" and is only ever released when a change needs to be made to it. It is much more static and unchanging over time
[21:20] <mdiggory> at this point, dpendencyManagment is excluded from said parent
[21:21] <mdiggory> because dependency management varies more often
[21:21] <sandsfish> Right, but my question is, is this one Parent POM to rule them (dspace projects) all? Or are there separate parent POMs for different sections (i.e. services framework, etc.)?
[21:22] <mdiggory> I'm still working out the details on dependencyManagment sections, and I can only say at this time "maybe"
[21:23] <sandsfish> ok. i'll be happy to review the documentation once you've had a chance to get it in front of more eyes. just want to understand all its implications.
[21:23] <sandsfish> mdiggory: one more question before i run out of here. is the code that Cocoon was patched with (currently used in the trunk) not managed / viewable anywhere?
[21:24] <mdiggory> dependencyManagement in the parent causes a topdown control and all the dspace-xxx parts to need to be checked out to work on something... spreading the dependencies back out into their corresponding projects where they are used is more "modular"
[21:26] <mdiggory> a source jar was never produced. But the patch to the 1.0.0 codebase is available...
[21:26] <mdiggory> This is version of the cocoon servlet service with patched as per the following tickets:
[21:26] <mdiggory> http://jira.dspace.org/jira/browse/DS-253
[21:26] <mdiggory> with patch...
[21:26] <mdiggory> https://issues.apache.org/jira/browse/COCOON-2217 This is deployed to fix issues with streams not closing we cannot use cocoon-servlet0service-impl 1.1.0 or 1.2.0 as they break block deployment.
[21:27] <mdiggory> oh, thats pleasant
[21:27] <mdiggory> JIRA is currently being reindexed. Depending on how large the database is, this may take a few minutes. Jira will automatically become available as soon as this task is complete.
[21:27] <mdiggory> This process is 42% Completed.
[21:28] <mdiggory> sandsfish: We have to be carefull suggesting that "one parent rules them all"
[21:28] <sandsfish> Ok, well I'll review that later. We want to patch the "white screen of death" locally because it happens 3 times a day for us but we wanted to make sure we knew what was changing so we could look for any adverse side effects. thanks for the info.
[21:29] <sandsfish> yeah, it sounds like it bears some benefit analysis.
[21:29] <sandsfish> i've gotta run unfortunately. cheers all!
[21:29] <mdiggory> if theres a dependency on dspace-foo --> has parent-a and dspace-bar --> has parent-b they are both used
[21:30] <sandsfish> mdiggory: sorry to run out. definitely interested in continuing the parent POM discussion.
[21:30] <mdiggory> sandsfish: post teh path you come up with, we can create a "project" that will create a better means to track the source
[21:30] <sandsfish> will do.
[21:31] * sandsfish (~sandsfish@dhcp-18-111-1-134.dyn.mit.edu) Quit (Quit: sandsfish)
[21:46] * gilbertsonk (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: gilbertsonk)
[21:46] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[21:47] * ksclarke1 (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[21:48] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) Quit (Disconnected by services)
[21:48] * ksclarke1 is now known as ksclarke
[22:02] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:21] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.