Timestamps are in GMT/BST.
[6:36] -hubbard.freenode.net- *** Looking up your hostname...
[6:36] -hubbard.freenode.net- *** Checking Ident
[6:36] -hubbard.freenode.net- *** Found your hostname
[6:36] -hubbard.freenode.net- *** No Ident response
[6:39] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:39] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:39] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:09] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[12:09] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has left #duraspace
[12:10] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[12:58] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[14:22] * survery (~thomas@dslb-178-007-120-202.pools.arcor-ip.net) has joined #duraspace
[14:22] * survery (~thomas@dslb-178-007-120-202.pools.arcor-ip.net) has left #duraspace
[18:27] * barmintor is now known as ba_mtg
[19:13] * KevinVdV (KevinVdV@d54C14FE4.access.telenet.be) has joined #duraspace
[19:19] * ba_mtg is now known as barmintor
[19:46] * BramDS (~anonymous@94-224-17-72.access.telenet.be) has joined #duraspace
[19:49] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[19:50] <tdonohue> Hi all, reminder our DSpace Devel Mtg is here in about 10mins: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-03
[19:50] <kompewter> [ DevMtg 2011-08-03 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-03
[19:53] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[20:00] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:00] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Ping timeout: 252 seconds)
[20:00] <tdonohue> Hi all, welcome. It's that time again...time for the weekly DSpace Devel meeting
[20:01] <tdonohue> We'll start as usual with JIRA Reviews. Here's the list of tickets to be reviewed: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-864+ORDER+BY+key+ASC
[20:01] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-864+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-864 ] - [#DS-864] Fix/cleanup code to ensure it is well documented - DuraSpace JIRA
[20:01] <tdonohue> starting with DS-864
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-864 ] - [#DS-864] Fix/cleanup code to ensure it is well documented - DuraSpace JIRA
[20:02] <tdonohue> hmm.. this ticket is a bit general. PeterDietz, were their specific examples here for Ds-864?
[20:02] <robint> Looks like a placeholder for us all to use
[20:02] <PeterDietz> yes, placeholder
[20:02] <tdonohue> Ok, well, we can skip it then, and move on
[20:03] <tdonohue> next up, DS-868
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-868 ] - [#DS-868] Collection trail with discovery module is not working - DuraSpace JIRA
[20:04] <tdonohue> interesting. this sounds like a bug, but needs verification it looks like
[20:04] <KevinVdV> This one has already been fixed
[20:05] <robint> Excellent! Could you update the Jira issue ?
[20:05] <KevinVdV> I cannot close it since I don't have the rights to do that but I can comment on it
[20:06] <robint> Doh! That would be appreciated.
[20:06] <KevinVdV> Will comment in a second, searching the JIRA where it was fixe
[20:06] <tdonohue> KevinVdV: adding a comment would be good. We can close it after that.
[20:06] <tdonohue> thanks KevinVdV!
[20:06] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:06] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[20:06] <tdonohue> Ok, we'll move on then, since Ds-868 is fixed
[20:07] <tdonohue> next up DS-870
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-870 ] - [#DS-870] pt_BR translation errors - DuraSpace JIRA
[20:07] <tdonohue> oh, Claudia has this one...we'll skip it then
[20:07] * richardrodgers (~richardro@18.111.77.194) has joined #duraspace
[20:07] <tdonohue> next up, DS-872
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-872 ] - [#DS-872] Community-based feedback - DuraSpace JIRA
[20:07] <KevinVdV> *Commented*
[20:08] <tdonohue> thanks again KevinVdV
[20:08] <robint> Looks like Claudia has grabbed 872
[20:08] <tdonohue> you mean 870, robint? 872 is unclaimed
[20:08] <robint> Doh! I do
[20:09] <mhwood> 872 sounds sensible.
[20:10] <tdonohue> I'd be ok with 872 -- though I had never run into this in the past, to be honest. What do others think?
[20:11] <PeterDietz> our feedback all goes to our repository-support-team's group list serv
[20:11] <PeterDietz> ...they fan out any requests from there
[20:11] <tdonohue> yea, that's how we used to manage it as well, when I was at U of Illinois -- it all went to a listserv
[20:11] <mdiggory> we've mostly focused on using the Community/Collection Admin group to manage such emailing logic
[20:12] <hpottinger> I could see a use case for a shared repository for a consortium, or a multi-campus university
[20:12] <mdiggory> I'd almost always suggest not adding yet another "collection/community" mapping to the space c.fg
[20:13] <mdiggory> I'd rather see a Role "Feedback Recipients" and a Groups/EPersons Attached to it in the DB somehow
[20:14] <mhwood> You mean: invent a "gets feedback" permission and grant that to some group on some container? Interesting.
[20:14] <mdiggory> for instance, if we were to approach this in the XMLUI, we'd create an aspect, model and db table to support the admin adding removing users from the listing.
[20:15] <mdiggory> well, I know a "permission" is a bit of a stretch....
[20:15] <mhwood> It's what ACLs have.
[20:15] <tdonohue> yea, I like that idea, mdiggory. Either that, or just have the option to send feedback to anyone who is in the Community Admin group or Collection Admin group
[20:16] <tdonohue> well, any volunteers to work with this patch a bit? or provide more detailed feedback in the comments on how to improve? It sounds like the *idea* is sound, just that there are some concerns about the exact patch
[20:16] <mhwood> ACL approach is kind of a backdoor way to make this into container metadata.
[20:17] <robint> I won't have time pre feature freeze
[20:17] <hpottinger> we may play with the patch here in Missouri, would need to see how the managers felt about it
[20:17] <robint> hpottinger: Please do. Any feedback very welcome
[20:18] <tdonohue> thanks hpottinger. Yea, just to be clear, I wasn't anticipating this would be in 1.8...I figured it'd be post-1.8 unless anyone has significant time in next few weeks (which is unlikely)
[20:18] <mdiggory> sorry, multitasking...
[20:19] <tdonohue> Ds-872 Summary: hpottinger will look at & investigate. likely post-1.8
[20:19] <tdonohue> next up, DS-873
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-873 ] - [#DS-873] Creative commons license bundle on embargoed item will cause internal system errors on item pages - DuraSpace JIRA
[20:19] <mdiggory> we can provide some design guidance if the authors are interested in rewriting it
[20:20] <mdiggory> Are we still storing CC the same after the MIT patch?
[20:20] <tdonohue> not sure, richardrodgers are you around?
[20:20] <richardrodgers> yes I am - what is the question?
[20:21] <tdonohue> Ds-873 looks like a definite bug, and the patch looks good to me (thanks KevinVdV), but we'd need to be sure it doesn't conflict with the MIT CC work coming in 1.8
[20:21] <richardrodgers> I'll take a quick look again, but I think the patch is fine, and does not conflct with new work..
[20:22] <tdonohue> sounds good. anyone want to volunteer to commit this immediately?
[20:22] <richardrodgers> there is still (at least on one configuration) a CC license bundle
[20:22] <robint> I was intending to pick up Wendy's CC patches so I'll grab this too
[20:22] <tdonohue> Ds-873 Summary: assign robint. he'll commit for 1.8
[20:22] <mdiggory> that sounds like a good idea robint
[20:23] <tdonohue> Ok, we'll stop JIRA review now. We can always do a bit more if we run out of things to discuss now :) Essentially, the rest of the meeting was just for open discussion on 1.8.0 features
[20:24] <KevinVdV> I have some small things that may be included in DSpace 1.8.0
[20:24] <tdonohue> so, anyone have any specific updates for us on 1.8 stuff?
[20:24] <KevinVdV> If I make take the "floor"
[20:24] <tdonohue> go ahead KevinVdV
[20:25] <KevinVdV> First one (already approved last week but not committed as far as I know)
[20:25] <KevinVdV> https://jira.duraspace.org/browse/DS-961
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-961 ] - [#DS-961] Oracle update sequence script can result in deleted sequences - DuraSpace JIRA
[20:25] <kompewter> [ [#DS-961] Oracle update sequence script can result in deleted sequences - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-961
[20:26] <tdonohue> did we get a volunteer on DS-961? I don't remember?
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-961 ] - [#DS-961] Oracle update sequence script can result in deleted sequences - DuraSpace JIRA
[20:26] <KevinVdV> I remember it getting a lot of +1's
[20:27] <KevinVdV> But not a real volunteer
[20:27] <mdiggory> Did we decide on its inclusion? I am ok with it because we run this in some production instances
[20:28] <tdonohue> Ok, looking back, we discussed on 7/20. http://irclogs.duraspace.org/index.php?date=2011-07-20
[20:28] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2011-07-20
[20:28] <tdonohue> we voted for inclusion, but no one volunteered to commit it. So, if someone would claim & commit it for 1.8.0, that'd be good
[20:29] <robint> Its that old problem of a lack of people with Oracle to test
[20:29] <tdonohue> mdiggory, you want to commit it, since you all are doing production oracle? I'd volunteer, but I don't have Oracle locally to test
[20:29] <mdiggory> yes
[20:29] <mdiggory> +1
[20:29] <mdiggory> Assign me
[20:29] <KevinVdV> So on to the next one
[20:29] <KevinVdV> https://jira.duraspace.org/browse/DS-980
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-980 ] - [#DS-980] Upgraded solr & lucene to version 3.3.0 - DuraSpace JIRA
[20:29] <tdonohue> ok, mdiggory will assign himself to Ds-961 ;)
[20:29] <kompewter> [ [#DS-980] Upgraded solr & lucene to version 3.3.0 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-980
[20:30] <aschweer> DS-951 also needs to be tested with Oracle -- really just to make sure the syntax doesn't break
[20:30] <kompewter> [ https://jira.duraspace.org/browse/DS-951 ] - [#DS-951] Monthly stats report ignores items archived on first and last day of the month - DuraSpace JIRA
[20:30] <aschweer> (sorry for butting in, KevinVdV)
[20:31] <tdonohue> thanks aschweer, good to know. could @mire try and confirm Ds-951 too? (Although to note, since we are talking about *bugs* these can be verified & committed *after* feature freeze as needed)
[20:31] * bojans (~Bojmen@62.68.103.162) has joined #duraspace
[20:32] <aschweer> (ah good to know, thanks for clarifying tdonohue)
[20:33] <mdiggory> TBH we are not running the reporting on oracle because we run our stats in most cases…
[20:33] <tdonohue> yes...just a general FYI, anything that is a *bug* can be committed after Feature Freeze. Anything that is a *New Feature* or *Improvement* should be committed before Feature Freeze (may be rare exceptions, but they need to be approved by Robin & Committers)
[20:33] <mdiggory> The patch looks simple though
[20:34] <aschweer> mdiggory: yeah it's embarrassingly simple, but I guessed with the oracle syntax
[20:34] <mdiggory> aschweer: you've tested this locally?
[20:34] <aschweer> we're running this on our 4 production servers, but they're all postgres
[20:35] <tdonohue> anyone else in this IRC room running Oracle DB, and be willing to do a quick verification of the small DS-951 patch for aschweer?
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-951 ] - [#DS-951] Monthly stats report ignores items archived on first and last day of the month - DuraSpace JIRA
[20:35] <hpottinger> We are, and I'm happy to give a patch a whirl
[20:35] <aschweer> thanks hpottinger!
[20:35] <tdonohue> thanks hpottinger!
[20:36] <mdiggory> not anything weird… http://download.oracle.com/docs/html/A95915_01/sqopr.htm#i1004774
[20:36] <kompewter> [ SQL Operators ] - http://download.oracle.com/docs/html/A95915_01/sqopr.htm#i1004774
[20:36] <tdonohue> Ok, jumping back now to DS-980, which KevinVdV mentioned earlier as ready for 1.8.0
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-980 ] - [#DS-980] Upgraded solr & lucene to version 3.3.0 - DuraSpace JIRA
[20:36] <KevinVdV> Thx tdonohue
[20:36] * PeterDietz does not like weird things, such as: availableCollection |= getAvailableCollection();
[20:37] <mdiggory> Changes: This release adds grouping/field collapsing. It has improved autocomplete/suggest capabilities. It has switched to a more efficient default merge policy. Improved stemming capabilities for English
[20:38] <mdiggory> This is the first release since the Lucene/Solr merge and hence Solr's version number was bumped up to match Lucene (Solr 3.1 contains Lucene 3.1). Highlights include Numeric range facets, Spatial search, Velocity driven search UI at http://localhost:8983/solr/browse, a new termvector-based highlighter, an extended dismax (edismax) query parser, a new Auto Suggest component, the ability to sort by functions, JSON document indexing,
[20:38] <mdiggory> response format, and Apache UIMA integration for metadata extraction
[20:39] <mdiggory> overall, going to 3.3.0 would seem a wise decision
[20:39] <tdonohue> so, I'm assuming all seems to be working well with 3.3.0 in place? I'm all for upgrading (as I know we are on rather old versions of Lucene & Solr)
[20:39] <mdiggory> I've reviewed the changes to DSIndexer and DSQuery and they are mostly administrative adjustments to changes in Lucene Constants,
[20:40] <robint> +1
[20:40] <KevinVdV> I have tested the patch locally ofc & here it does appear to work
[20:40] <richardrodgers> have we done regressions in non-SOLR contexts?
[20:40] * mhwood would love to see a Maven plugin to report: the following dependencies/plugins are such old versions they are beginning to smell, please consider upgrading.
[20:40] <tdonohue> richardrodgers: the patch looks to include fixes to all our DSQuery stuff which is straight Lucene too... so, it's not just Solr fixes
[20:41] <KevinVdV> Yeah solr & lucene received the same version number as of 3.x
[20:41] <KevinVdV> Solr solr went from 1.4.1 => 3.0.0 & lucene from 2.9.3 => 3.0.0
[20:41] <tdonohue> mhwood +1 (not sure how to do that though, but it'd be nice)
[20:41] <mhwood> Goody, my brand new Solr 1.4 book is already obsolete.
[20:42] <KevinVdV> Sorry mhwood
[20:42] <mdiggory> Just realizing…. do we not have "ANY" DSQuery or DSIndexer tests at all in dspace-api?
[20:42] <robint> mhwood: :)
[20:42] <tdonohue> mdiggory: ugh. :( we aren't doing so well at adding new Unit Tests (myself included)
[20:42] <mdiggory> mhwood: no worries, you can sell it on amazon for $0.25
[20:43] <mdiggory> mhwood: This is where you come in and say...
[20:43] <mdiggory> I've fixed all our problems with getting the JUnit testing environment synced with the space/config dir
[20:44] <mdiggory> ;-)
[20:44] <tdonohue> well, I'd be +1 getting DS-980 committed for 1.8.0, since it sounds stable. It seems like something we can "bang on" during Testathon and find if anything Search/Browse related isn't working 100% right.
[20:44] <kompewter> [ https://jira.duraspace.org/browse/DS-980 ] - [#DS-980] Upgraded solr & lucene to version 3.3.0 - DuraSpace JIRA
[20:44] <mdiggory> +1 on adding it now
[20:44] <KevinVdV> Feel free to "bang on it" ...... if you can find anything wrong with it
[20:44] <mhwood> Sorry, learning to write Maven plugins so I can write the plugin to hack the config so I can port the testing framework out of dspace-api so I can test in dspace-stats.
[20:45] <robint> mhwood: I would like to see a plugin that prevents me from buying soon to be outdated books
[20:45] <KevinVdV> There is one more rather small JIRA of mine remaining (for today)
[20:45] <mdiggory> robint: its maven-bittorrent-plugin
[20:45] <robint> :)
[20:46] <tdonohue> any other 1.8.0 things to discuss/approve/review today?
[20:46] <KevinVdV> https://jira.duraspace.org/browse/DS-981
[20:46] <kompewter> [ https://jira.duraspace.org/browse/DS-981 ] - [#DS-981] Created a DSpace API module to contain api changes - DuraSpace JIRA
[20:46] <kompewter> [ [#DS-981] Created a DSpace API module to contain api changes - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-981
[20:46] <KevinVdV> The last one of mine for today I promise
[20:46] <KevinVdV> This is something that I have to do time & time again
[20:46] <KevinVdV> Would be nice to have it in DSpace & save me the time
[20:47] <mdiggory> KevinVdV: richardrodgers, tdonohue and I were chatting about something analogous with a "cli" module as well… http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/dspace/modules/cli/
[20:47] <kompewter> [ repo - Revision 6523: /dspace/branches/dspace-async-release/dspace/modules/cli ] - http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/dspace/modules/cli/
[20:48] <mdiggory> adding both cli and api provides a conventional place to drop custom code for "just cli" or "for all modules"
[20:48] <KevinVdV> *Agrees with mdiggory*
[20:49] <robint> At first glance I like the idea, need to go away and look at the implementation
[20:49] <tdonohue> I'll admit, I personally had never really used a [dspace-src]/dspace/modules/api/ overlay. But, it seems like it could be useful (perhaps even to "install an addon" into all of DSpace, like dspace-replicate). What do others think of this idea?
[20:50] <mdiggory> tdonohue: minor clarification, its a jar dependency, not an overlay
[20:50] <robint> So how does it override classes ?
[20:50] <tdonohue> Oh, I totally missed that. I *assumed* it was in overlay, cause it was in the overlays directory
[20:50] <robint> or does it not ?
[20:51] <KevinVdV> If an existing DSpace-api is put into it it WILL have top prior
[20:51] <KevinVdV> & override them
[20:51] <mdiggory> robint: we do not condone or advocate overriding classes, but, yes, you could
[20:51] <KevinVdV> This makes it easy to keep all your changed DSpace classes in a single module
[20:51] <aschweer> it pretty much looks like what we do -- it's not an overlay, but since 'api' comes before 'dspace-api', classes in it override dspace-api classes
[20:52] <mdiggory> if dspace-api were dspace-impl, we'ed have a whole lot more letters in the alphabet to accomplish overrides in the "dspace-" jar prefix … ;-)
[20:53] <aschweer> didn't grahamtriggs say though that it's sufficient to put the dependency in modules/pom.xml (no need to put it in the individual modules' pom.xml files)?
[20:53] <tdonohue> So, let me get this straight...anything you put in /modules/api/ would be compiled into an 'api.jar'? And you can also use it to add in new JAR dependencies for all DSpace modules?
[20:53] <mdiggory> aschweer: there is a problem with doing that atm, because those dependencies leak into the sold web app as well
[20:53] <KevinVdV> Yes tdonohue
[20:53] <mdiggory> sold = solr (stink in Lion)
[20:53] <mdiggory> gah
[20:54] <aschweer> mdiggory: ah good to know, I was a little worried about that myself (we have the dependency just in those modules that need it)
[20:54] <tdonohue> mdiggory: stink in Lion? what are you trying to say (laughing....)
[20:54] <mdiggory> I look at the keyboard while typing, not the screen
[20:55] <mdiggory> OSX Lion keeps "correcting" me
[20:55] <mhwood> "stinkin'", a term of disapprobation, I guess.
[20:55] <tdonohue> ok. My only concern with this /modules/api/ is that we probably want some decent documentation explaining it, how to take advantage of it, and how it differs from the other Overlay directories (or is similar).
[20:55] <mdiggory> even corrected stinkin to "stink in"
[20:55] <tdonohue> So, essentially, I'd be +1...but, I'd like to see some sort of basic docs with it
[20:56] <tdonohue> (cause, honestly, I did assume it was an overlay, and that it would create a new 'dspace-api.jar'....and I wonder if others will wrongly assume the same thing)
[20:56] <mhwood> At least it didn't change it to "wonderful Lion, go buy your copy today!"
[20:56] <KevinVdV> Will do, feel free to comment in it & I will see to it
[20:56] <mdiggory> Yes, because it introduces a convention, docs would basically say "add customized code needing to go into all space webappa and cli in the api project.
[20:57] <robint> Can I throw one more Jira issue in the pot ?
[20:57] <robint> DS-881
[20:57] <kompewter> [ https://jira.duraspace.org/browse/DS-881 ] - [#DS-881] DSpace doesn't build properly with Maven 3 - DuraSpace JIRA
[20:57] <mdiggory> tdonohue: overlays don't "repackage" jars, only wars
[20:58] <mdiggory> robint: some of our async work correct this by cleaning out duplicate profiles in dspace-parent and dspace/pom.xml
[20:58] <mdiggory> this could be made into a smaller patch for 1.8
[20:58] <robint> mdiggory: I hoped that might be the case
[20:58] <tdonohue> mdiggory: yea, I forgot about that -- but, I still think it's worth clarifying in some sort of documentation. Especially cause Ds-981 is different from overlays and yet it sits alongside the overlays...
[20:59] <mdiggory> we all use the modules directory for more than just overalys
[20:59] <tdonohue> yes, please please please...we need a fix for Ds-881 in 1.8 :) (just my opinion)
[20:59] <mdiggory> but I agree. docs will be good...
[21:00] <tdonohue> mdiggory: no we don't? not out of the box as far as I know...it's all overlays of wars right now isn't it?
[21:00] <mdiggory> Ok… well, http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/ has the cli, a fix for maven 3 and some work on repackaging the space-release prices in it
[21:00] <kompewter> [ repo - Revision 6523: /dspace/branches/dspace-async-release ] - http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/
[21:00] <tdonohue> in any case, yes, it's all about needing better docs
[21:01] <mdiggory> tdonohue: I'm just saying we do
[21:01] <mdiggory> prices = process
[21:02] <mdiggory> I can separate out the cli / maven 3 fixes….
[21:02] <tdonohue> Ok. any last things to discuss? I notice we are over time now..
[21:02] <robint> mdiggory: that would be much appreciated
[21:02] <tdonohue> mdiggory: sounds good to me as well
[21:03] <mdiggory> Seems mhwood is working on some testing assemblies… I'd like to briefly discuss separating out the last feature thats in the branch
[21:03] <robint> Apologies but I have to go. Thanks all.
[21:03] <mdiggory> that is dspace-parent moves to its own project and dspace-release is created to support packaging the releases within, but exculted from the source
[21:03] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Quit: Page closed)
[21:04] <aschweer> I have to leave too. bye everyone
[21:04] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:04] <mdiggory> building all modules (including dspace-xxx then happens in the space dir as usual
[21:04] <mdiggory> space= dspace
[21:05] <tdonohue> mdiggory: sounds logical enough to me, based on that simple description. It'd be good if we did exclude all our Maven Release stuff in the Source Release (-src-release.zip), as users really don't need that.
[21:06] <mdiggory> Yes, the change in adding dspace-release means that the release assemblies are under space trunk and not off in a separate plugin no one "knew about"
[21:06] * gaurav_kl (75c6251d@gateway/web/freenode/ip.117.198.37.29) has joined #duraspace
[21:07] <tdonohue> So, obviously it sounds like users could no longer run 'mvn package' from [dspace-src] (as there would no longer be a pom.xml there).... but, they shouldn't have been doing that anyways (hopefully). Just wanted to make that clear if others aren't following completely
[21:07] <mdiggory> So, I will break these up and if we have some consensus on the api/cli addition task I'd take ownership
[21:07] <mhwood> So then what do *we* do?
[21:08] <mdiggory> you go into /dspace/ and run it there… the way described in the documents
[21:09] <tdonohue> mhwood : also, the difference for releases would be that a committer would perform the release from [dspace-src]/dspace-release/ *instead of* just [dspace-src]
[21:09] <mdiggory> yes
[21:10] <mdiggory> and theres no longer confusion if one should run mvn package at [dspace-src] or [dspace-src]/dspace
[21:10] <tdonohue> mdiggory: i'd say create a new Jira task for the dspace-parent & dspace-release changes. I think they sound like a good idea, and shouldn't affect anything else. But, that way others can comment, if they aren't here right now
[21:11] <mdiggory> yep...
[21:11] <mdiggory> I know we are over into GSoC time… I ask that folks please do continue to respond to the Domain Model email thread in devel….
[21:12] <mdiggory> I've proposed some alternatives there and want to see about getting this cleared up by the freeze
[21:12] <richardrodgers> gotta run, thanks all
[21:12] * richardrodgers (~richardro@18.111.77.194) has left #duraspace
[21:12] <mdiggory> https://jira.duraspace.org/browse/DS-845
[21:12] <kompewter> [ https://jira.duraspace.org/browse/DS-845 ] - [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA
[21:12] <kompewter> [ [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-845
[21:13] <tdonohue> ok, i'll try and revisit as well, mdiggory. would definitely be good to hear from others on it too
[21:13] <tdonohue> is that it for today? (noticing we've already lost many -- which is fine, as we are in 'overtime')
[21:14] <mhwood> Yeah, I have to run too. 'bye all.
[21:14] <mdiggory> Suggest opening for floor for GSoC
[21:14] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has left #duraspace
[21:14] <tdonohue> Sounds good. Devel Meeting is now closed. Moving on to GSoC
[21:14] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has left #duraspace
[21:15] <tdonohue> so, anyone with GSoC topics/comments/questions can feel free to take the "floor"
[21:15] <gaurav_kl> hi.just to give the status update..
[21:16] <snail> BTW guys, i've just hacked dspace2redif to couple with full unicode. i've fed the changes upstream, but sample code is in http://researcharchive.vuw.ac.nz/local/RePEc/ the capsule summary is that you need to output a BOM in the file because the infrastrcuture assumes windows charsets are in use
[21:16] <kompewter> [ Index of /local/RePEc ] - http://researcharchive.vuw.ac.nz/local/RePEc/
[21:16] <KevinVdV> Got to run
[21:16] * KevinVdV (KevinVdV@d54C14FE4.access.telenet.be) Quit ()
[21:17] <gaurav_kl> m working on finishing the porting of the DescribeStep..Will be finishing porting all the current steps by this week..
[21:18] <mdiggory> This is good to hear…. question…. are any of the classes you've borrowed from the Config Reviewer Workflow under their original package /class names?
[21:19] <gaurav_kl> no.i dont think so..i changed the classnames to match the "submission" naming
[21:20] <gaurav_kl> yeah
[21:20] <gaurav_kl> there are Role
[21:20] <gaurav_kl> related classes
[21:20] <gaurav_kl> but I haven't used them till now in my submission process
[21:20] <gaurav_kl> just made the UI to create/edit role
[21:21] <mdiggory> Ok, this is good to know… Pay attention to the following patch s well.. we are still adjusting a few things in it https://jira.duraspace.org/browse/DSRV-17
[21:21] <kompewter> [ https://jira.duraspace.org/browse/DSRV-17 ] - [#DSRV-17] Loading spring files from {dspace.dir}/config/spring could cause some modules to stop working - DuraSpace JIRA
[21:21] <kompewter> [ [#DSRV-17] Loading spring files from {dspace.dir}/config/spring could cause some modules to stop working - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DSRV-17
[21:22] <mdiggory> If the configurable submission is configured in the Service Manager and the xmlui classes are not available to the jspui the service manager will break...
[21:22] <gaurav_kl> oh
[21:22] <mdiggory> this is work to assure separate spring configuration is possible for xmlu, jspui, cli, etc
[21:22] <gaurav_kl> ok
[21:23] <gaurav_kl> should the spring file be in confog/spring folder..currenntly they are in config folder
[21:23] <mdiggory> I think the big question is more "how" are you loading them
[21:24] <mdiggory> you should try to keep your iml files out of the source tree....
[21:24] <mdiggory> https://github.com/gauravkl/DSpace
[21:24] <kompewter> [ gauravkl/DSpace - GitHub ] - https://github.com/gauravkl/DSpace
[21:25] <mdiggory> I bet your using the older "separate" Spring config for Submission
[21:25] <gaurav_kl> yeah..
[21:26] <mdiggory> The configurable reviewer workflow patch that should be attached by the end of this week actually utilizes the service manager spring context to register the workflow steps for the Workflow manager rather than a separate spring config
[21:27] <gaurav_kl> ok.so we will have one single spring file which will contain configs for everything
[21:28] <mdiggory> no, it would more than likely be a directory structure of spring configs config/spring/xmlui/... config/spring/jspui/... config/spring/lni/.…
[21:29] <gaurav_kl> ok
[21:29] <BramDS> gaurav_kl: should not be much work to change your current code
[21:30] <gaurav_kl> yeah.i think i'll just need to change at one point where i retrieve the bean
[21:31] <BramDS> indeed
[21:32] <mdiggory> BramDS: I was chatting with kevin about the patch for supporting this and I had some concerns… It was possible in the past to call into the workflow and advance items/change steps via writing code in cli...
[21:32] * barmintor (barmintor@specdl11.cul.columbia.edu) Quit ()
[21:32] <mdiggory> Would this still be possible with the new config?
[21:32] <BramDS> hmmm not sure
[21:33] <BramDS> haven't seen him today because I was not in the office
[21:33] <BramDS> but he told me he would explain the issue tomorow
[21:33] <mdiggory> do we have conventions for "common" spring files that should load for all "contexts"?
[21:33] <BramDS> will make sure we look into it before releasing the patch
[21:35] <BramDS> was that question for me mdiggory ?
[21:37] <mdiggory> yes
[21:37] <BramDS> oh :)
[21:38] <BramDS> I think it is best to ask kevin
[21:38] <BramDS> he did most of the spring-related development
[21:39] <mdiggory> yes, Kevin and I have been working together on dspace-services spring configuration loading off and on for the last few months.
[21:39] <BramDS> I assume that if there are any conventions, he will apply them
[21:40] <mdiggory> thats just it…. there arn't
[21:40] <BramDS> oh ok
[21:40] <BramDS> could be useful
[21:40] <BramDS> will discuss this with him
[21:41] <BramDS> and let you know the result of the discussion to allow you to feedback
[21:41] <mdiggory> ok
[21:41] <mdiggory> theres an email from me on the way soon anyhow
[21:41] <BramDS> ok perfect
[21:42] <BramDS> gaurav_kl, mdiggory, do you need me for any other comments/questions?
[21:42] <BramDS> otherwise, I'm off, it's been a long day
[21:42] <mdiggory> I wonder if we should discuss hooks for transitioning from workflow to submission
[21:43] <BramDS> might be interesting
[21:43] <mdiggory> theres two areas… (1) loading the Describe Step into Workflow cleanly
[21:44] <mdiggory> (2) if Item is rejected from workflow, how do we know which submission system to return it to?
[21:44] <gaurav_kl> by this u mean "old or new
[21:44] <mdiggory> correct
[21:45] <BramDS> (1) would this mean that the submission would become part of the wf?
[21:45] <BramDS> (2) I wouls say, use the one that is configured at that moment
[21:45] <BramDS> or do we support both the old and the new submission system at the same time?
[21:45] <mdiggory> No, I'm referring more to how the Reviewer editing the metadata utilizes the Describe Step to do it.
[21:46] <mdiggory> for (1) I mean
[21:46] <BramDS> oh I see
[21:46] <mdiggory> by (2) is that just using WorkspaceItem?
[21:46] <gaurav_kl> i think (10 can be done in a better manner once I finish the porting
[21:46] <gaurav_kl> (1)
[21:46] <BramDS> I would use the describestep as a workflow step as well
[21:47] <BramDS> I assume the fields displayed by the describestep will still come from input-forms.xml?
[21:47] <gaurav_kl> yeah.
[21:47] <BramDS> in that case I would just duplicate the describestep
[21:47] <mdiggory> Do we share Step/Action Spring configs across both Workflow and Submission
[21:47] <BramDS> maybe add some code to support wf-only metadata fields
[21:48] <BramDS> mdiggory: good question
[21:48] <BramDS> maybe not in a first version
[21:48] <BramDS> but in case we would tighten the integration in the future
[21:48] <gaurav_kl> for that we already have the "scope" parameter..will that not work?
[21:48] <gaurav_kl> i think it should ork
[21:49] <gaurav_kl> in the input-forms.xml we have a parameter "scope"
[21:51] <mdiggory> are you talking about "workflow-editable"?
[21:51] <gaurav_kl> oh..yeah..sorry
[21:51] <gaurav_kl> meant that only
[21:52] <BramDS> is workflow-editable currently supported?
[21:52] <BramDS> by the describestep?
[21:53] <gaurav_kl> yeah
[21:53] <gaurav_kl> i think so
[21:54] <mdiggory> Yes, but its very wonky… its one conditional statement that blocks adding form fields if the step is being rendered in workflow
[21:55] <mdiggory> gaurav_kl: what are are your thoughts on producing a version of Submission that is based on Spring but not be database driven? Sort of a "halfway point" where Submission and Workflow "merging" could be worked on?
[21:55] <BramDS> guys sorry but I have to leave, in case you have any questions, you can always send me an email
[21:56] <mdiggory> I understand, its late there
[21:56] <BramDS> indeed
[21:56] <mdiggory> gaurav_kl: its late for you as well right?
[21:56] <BramDS> cu all, have a nice day or night
[21:56] <gaurav_kl> hehe..yeah..changed my schedule a bit..
[21:56] * BramDS (~anonymous@94-224-17-72.access.telenet.be) Quit (Quit: BramDS)
[21:57] <gaurav_kl> i am not surea bout going no-DB driven
[21:57] <gaurav_kl> do u mean not storing Actions in the DB
[21:58] <mdiggory> Basically, it would be using the spring to continue to support the step, action definitions, but using the old item-submission.xml for mat to support enduser configuration
[21:59] <mdiggory> basically, what I'm determining is if there is a clean point where we could make a contribution to 1.8 with that does not destabilize it.
[22:01] <gaurav_kl> ok..i think to make it work with the current implemetaion we may need to make a way to port item-submissions.xml properties suitablty to DB
[22:01] <mdiggory> This is just risk analysis on making a contribution. Trying to verify your timeline against the space 1.8 code freeze timeline
[22:01] <gaurav_kl> direclty populating from the XMl would be diffuclt in my curent implemeation
[22:02] <gaurav_kl> we can have CMD to import from XML to DB
[22:04] <mdiggory> Ok, that'll suffice
[22:04] <mdiggory> another question…
[22:04] <gaurav_kl> ok.
[22:04] <mdiggory> are you dealing at all with the case that someone may try to alter the submission process while items are in it?
[22:05] <mdiggory> IE, there would be a step id for the item
[22:06] <gaurav_kl> no..haven't worked on that part..
[22:06] <gaurav_kl> what should we be doing in that case
[22:06] <mdiggory> basically the case where items exist in submission, have moved to a specific step, but then the collection admin changes the submission process… if that step were to be "removed", then the workspace item would be "out of sync" with the "submission process"
[22:06] <gaurav_kl> yeah
[22:07] <mdiggory> maybe just use foreign key constraints… block altering the submission process until all items are removed from it.
[22:07] <gaurav_kl> yeah.that wil be better..
[22:08] <mdiggory> or… another possibility is to "reset" any state in the workspace item to force it back to the beginning of the submission process
[22:09] <mdiggory> or… int he case there is ever an "error" in matching the workspace item to a workflow stage, just default to the first step and reset the items state
[22:09] <mdiggory> workflow stage = submission process step
[22:10] <gaurav_kl> yeah..this is a better approach i think..we can keep the earlier metadata of the item as it is though
[22:10] <mdiggory> yes
[22:12] <gaurav_kl> ok..will implement that part..
[22:12] <mdiggory> excellent
[22:12] <gaurav_kl> one query i have is regarding UserSelectionAction
[22:13] <gaurav_kl> do we have any in the Submission Process
[22:13] <gaurav_kl> like there was in Workflow
[22:13] <gaurav_kl> i dont think we need it
[22:13] <gaurav_kl> in submission
[22:14] <gaurav_kl> there is a thing called Supervised subimissions
[22:14] <gaurav_kl> which i think is listed along with unfinished submissions
[22:15] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has left #duraspace
[22:15] <gaurav_kl> that is where i think the Roles thing will be utilized
[22:16] <mdiggory> I'm struggling to remember what supervised "meant" in dspace
[22:16] <gaurav_kl> its tha same like u once suggested regarding multiple "users" submitting the same "item"
[22:16] <mdiggory> User selection in the workflow case is to assign the task to a user (I think)
[22:17] <gaurav_kl> like the thesis-guide
[22:17] <gaurav_kl> yeah..
[22:18] <mdiggory> There might be a use case for User Selection, but I would stick to the default steps for now, given the time crunch
[22:18] <mdiggory> I would remove any code that is not going to be used as well
[22:18] <gaurav_kl> ok.yeah will do
[22:18] <mdiggory> We can always work on "add ons" for space that provide new steps...
[22:18] <gaurav_kl> hmm
[22:19] <mdiggory> When do you move to TAMU? or have you already?
[22:19] <gaurav_kl> no..i will be leaving on 13th from India..
[22:20] <gaurav_kl> will be trying to finish the work before that..
[22:20] <mdiggory> Understandable...
[22:20] <mdiggory> are you very busy when you first arrive?
[22:21] <mdiggory> when do classes begin?
[22:21] <gaurav_kl> no.just few formal procedures
[22:21] <gaurav_kl> classes begin after 29th i think
[22:22] <gaurav_kl> checkin is on 16th
[22:22] <gaurav_kl> though i will be working on the project also
[22:23] <gaurav_kl> so that we can make it adaptable to 1.
[22:23] <gaurav_kl> 1.8
[22:24] <gaurav_kl> just mean to finish the major work before leaving
[22:25] <mdiggory> Yes… another thought if there are concerns about delivering it in the 1.8 feature freeze timeframe….
[22:26] <mdiggory> Can you identify only the changes that would be needed to "switch between" legacy submission and some other version that is available int he service manager?
[22:27] <gaurav_kl> yeah.
[22:29] <mdiggory> Lets look at your code for a moment
[22:29] <gaurav_kl> ok.
[22:29] <gaurav_kl> https://github.com/gauravkl/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/resources/aspects/Submission/submission.js
[22:29] <kompewter> [ dspace-xmlui/dspace-xmlui-api/src/main/resources/aspects/Submission/submission.js at master from gauravkl/DSpace - GitHub ] - https://github.com/gauravkl/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/resources/aspects/Submission/submission.js
[22:30] <gaurav_kl> i think the major change are in submissioncontrol method in the flowscript
[22:31] <mdiggory> So the Submission process in effect is chosen via the enable aspect?
[22:32] <gaurav_kl> yeah.it is retrieved from the DB from collection2process mapping..
[22:32] <mdiggory> What if you just copied the whole "submission" aspect into a new directory and modified it such that you switch off the legacy submission aspect and enable the new aspect to switch to the new submission process?
[22:33] <gaurav_kl> yeah i think that can be done...
[22:33] <gaurav_kl> is there a way to just switch off one of the "aspects"
[22:33] <gaurav_kl> ?
[22:33] <mdiggory> You've sear pated all the other code/tables in dspace-api and dspace-api-xmlui right?
[22:33] <mdiggory> xmlui.xconf
[22:33] <mdiggory> sear pated = separated
[22:34] <mdiggory> Seems the entire thing could be an add-on if that were the case
[22:35] <gaurav_kl> yeah.much of it is separated..can separate some part where I had earlier removed the old code....
[22:36] <mdiggory> step 1 : add dependencies on submission 2.0 add-on
[22:36] <mdiggory> step 2 : add "submission 2.0" aspect to xmlui.xconf
[22:36] <mdiggory> step 3 : apply database update
[22:37] <mdiggory> step 4 : import item-submission.xml
[22:38] <gaurav_kl> ok.for DB then we will need to support both old and new..i was using "workspaceitem" table only till now..should i create another table ..
[22:38] <gaurav_kl> in code i created a WorkspaceService class
[22:38] <mdiggory> but you made a new class "WorkspaceService" right?
[22:38] <gaurav_kl> but it's using the sme table
[22:38] <gaurav_kl> have to change it
[22:39] <mdiggory> do we have a listing of database changes?
[22:39] <gaurav_kl> yeah
[22:39] <mdiggory> Heres what I recommend you do for both the JIRA task and a wiki page.
[22:39] <gaurav_kl> in the wiki i had added the DB chaged ..will update it
[22:39] <mdiggory> 1.) Identify any legacy changes that are being done in dspace-api
[22:39] <gaurav_kl> to JIRA and wiki both
[22:40] <mdiggory> 2.) identify and list all database changes / additions.
[22:40] <gaurav_kl> ok.
[22:40] <mdiggory> 3.) If we separate this into an add-on, then identify those add-on sources separately
[22:41] <mdiggory> I would write the wiki page and reference it front he JIRA task
[22:41] <mdiggory> wiki page becomes documentation
[22:41] <mdiggory> jura task just identifies the commit and patches
[22:42] <gaurav_kl> hmm.what do u mean by "identifying add-on sources"
[22:42] <gaurav_kl> documenation
[22:44] <gaurav_kl> related.
[22:44] <mdiggory> so say that it can't get into 1.8 in time… then rather than creating a patch against space trunk, I would hen recommend instead to push the code into "modules" and write it and an xmlui aspect that can be used directly with DSpace.
[22:45] <mdiggory> sorry bad grammar caused by OSX Lion spelling corrections...
[22:46] <gaurav_kl> ok.understood..
[22:47] <mdiggory> the aspect would then be released in a binary form and could be installed into dspace 1.8 by adding it as a dependency in the XMLUI.
[22:47] <gaurav_kl> ok
[22:47] <mdiggory> To be able to do this though, you would want to make sure that it was "quite separate"....
[22:48] <mdiggory> and that there was an easy means to automate the database changes (something we really don't have yet in dspace)
[22:48] <mdiggory> when you reuse the workspaceitem table, do you modify it at all?
[22:49] <gaurav_kl> yeah..there are modifications in the table
[22:49] <mdiggory> elaborate?
[22:49] <gaurav_kl> i have removed the "stage_reache" "page_reaxched" columns
[22:50] <gaurav_kl> and added the "step_id" "action_id"
[22:50] <gaurav_kl> the "process_id" can be retrieved from "workspace_item"
[22:50] <gaurav_kl> thru "collection"
[22:51] <gaurav_kl> earlier "stage_reached" was just the stage number
[22:52] <mdiggory> are you documenting these here? https://github.com/gauravkl/DSpace/tree/master/dspace/etc
[22:52] <kompewter> [ dspace/etc at master from gauravkl/DSpace - GitHub ] - https://github.com/gauravkl/DSpace/tree/master/dspace/etc
[22:53] <mdiggory> Hmm....
[22:54] <gaurav_kl> yeah
[22:54] <mdiggory> I'm thinking... (1) use a completely separate table other than workspaceitem
[22:54] <gaurav_kl> ok
[22:54] <mdiggory> (2) your script ports workspaceitems to your new submission table
[22:55] <gaurav_kl> for the existing "workspaceutems"
[22:55] <gaurav_kl> ?
[22:55] <mdiggory> (3) adding submission 2.0 aspect to dspace involves only adding database tables
[22:55] <mdiggory> yes, for migrating existing workspace items.
[22:56] <gaurav_kl> ok..
[22:56] <gaurav_kl> that can be done
[22:57] <mdiggory> If we did that, would all your changes then be possible completely outside dspace-api?
[22:58] <mdiggory> to take this even further....
[22:58] <gaurav_kl> yeah..i think the changes can be moved to modules..
[22:59] <mdiggory> Ok, I'm liking this a lot
[22:59] <mdiggory> If you do this correctly, we can anticipate the changes to support suing the service amanger and begin work ont hem as well
[23:00] <mdiggory> suing = using
[23:00] <mdiggory> meaning
[23:01] <mdiggory> if you create a an addon project like dspace-discovery
[23:01] <mdiggory> https://github.com/gauravkl/DSpace/tree/master/dspace-discovery
[23:01] <kompewter> [ dspace-discovery at master from gauravkl/DSpace - GitHub ] - https://github.com/gauravkl/DSpace/tree/master/dspace-discovery
[23:02] <mdiggory> you can then place your SubmissionService and other dspace-api classes under a sub module dspace-submission-api
[23:02] <mdiggory> you can place your xmlui aspects under a separate project dspace-submission-xmlui-api
[23:03] <mdiggory> and any webapplication resources under dspace-submission-xmlui-webapp
[23:04] <mdiggory> inside dspace-submission-api and dspace-submission-xmlui-api you would add "default" spring configuration that registers all default steps and actions....
[23:04] <gaurav_kl> ok..
[23:05] <mdiggory> where you would put your aspect.... https://github.com/gauravkl/DSpace/tree/master/dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery
[23:05] <kompewter> [ dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery at master from gauravkl/DSpace - GitHub ] - https://github.com/gauravkl/DSpace/tree/master/dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery
[23:05] <mdiggory> or I mean the analogous location in discovery
[23:06] <gaurav_kl> ok..so is there benefit of going through this method instead of in the dspace/modules
[23:06] <mdiggory> here is an example of where you would register the actions/steps that are available by default
[23:06] <mdiggory> https://github.com/gauravkl/DSpace/blob/master/dspace-discovery/dspace-discovery-solr/src/main/resources/spring/spring-dspace-addon-discovery-services.xml
[23:06] <kompewter> [ dspace-discovery/dspace-discovery-solr/src/main/resources/spring/spring-dspace-addon-discovery-services.xml at master from gauravkl/DSpace - GitHub ] - https://github.com/gauravkl/DSpace/blob/master/dspace-discovery/dspace-discovery-solr/src/main/resources/spring/spring-dspace-addon-discovery-services.xml
[23:06] <mdiggory> Only, instead of what you see here, instead you would have what is currently in your spring config.
[23:07] <mdiggory> You would then switch to a different approach to initialize your SubmisionService...
[23:07] <mdiggory> making be a real "service" in the "service manager"
[23:07] <mdiggory> rather than a static manager class
[23:08] <mdiggory> to see how to do this properly, look at the classes identified in discovery...
[23:08] <mdiggory> org.dspace.discovery.SolrServiceImpl
[23:08] <mdiggory> But, even this is not the best example... What I want to teach you how to do is the following
[23:10] <mdiggory> When using Spring in the service manager, you can "auto-wire" the beans into the services that use them in the following manner....
[23:10] <mdiggory> for instance, in this project here: https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/identifier-services/src/main/resources/spring/spring-dspace-core-services.xml
[23:11] <mdiggory> <bean class="org.dspace.identifier.IdentifierServiceImpl" id="org.dspace.identifier.IdentifierServiceImpl" autowire="byType"/>
[23:11] <mdiggory> will pickup and wire any bean that matches its criteria into its setters
[23:11] <mdiggory> <bean class="org.dspace.identifier.HandleIdentifierService" />
[23:11] <gaurav_kl> ok.
[23:11] <mdiggory> implements that interface...
[23:12] <mdiggory> so, configuration is entirely left upto spring... you do not do anything like servicemanager.getService(....;.) blaa blaa blaa
[23:13] <mdiggory> All that you need inside your SubmissionService is a setter to set Steps
[23:13] <mdiggory> basically an array of steps
[23:13] <mdiggory> see here...
[23:13] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/identifier-services/src/main/java/org/dspace/identifier/IdentifierServiceImpl.java
[23:14] <mdiggory> public void setProviders(List<DSpaceIdentifierService> providers)
[23:14] <gaurav_kl> ok
[23:15] <mdiggory> So, to give an example of how this achieves great power for dspace addons... any addon can now define a bean that implements DSpaceIdentifierService and if it registeres it in the spring config... it is available for autowiring
[23:16] <mdiggory> we wrote a new Identifier Service just for DOIs
[23:16] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/api/src/main/resources/spring/spring-dspace-core-services.xml
[23:16] <mdiggory> <bean class="org.dspace.identifier.DOIIdentifierService" autowire="byType" scope="singleton"/>
[23:17] <mdiggory> implmented here
[23:17] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/api/src/main/java/org/dspace/identifier/DOIIdentifierService.java
[23:17] <mdiggory> when the service manager starts, it adds it to the list of providers above.... seamless... no alteration of any configuration
[23:19] <mdiggory> If you take this approach, you can write "Submission 2.0" as an addon that doesn't need any configuration in the dspace/config directory accept an alteration to xmlui.xconf
[23:19] <mdiggory> and a modification to the database....
[23:19] <gaurav_kl> ok.
[23:19] <mdiggory> note... we even automated that last step here
[23:20] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/versioning/versioning-api/src/main/java/org/dspace/versioning/InitializeDatabase.java
[23:20] <mdiggory> this is another addon for dspace that provides Item Versioning support...
[23:20] <mdiggory> it needs tables added to support tracking versions of dspace items...
[23:21] <mdiggory> this code could be automated such that at startup of dspace, if the tables did not exist, they would be created.
[23:22] <gaurav_kl> yeah.
[23:22] <mdiggory> This is the approach that scottatm and others took on "Vireo" as an addon... it creates its own tables via code...
[23:22] <gaurav_kl> ok
[23:23] <gaurav_kl> apart from Discovery is there any area which is using Service currently
[23:23] <mdiggory> UsagesStatistics
[23:23] <gaurav_kl> ok.
[23:24] <mdiggory> albiet, it needs to be made a little more current
[23:24] <mdiggory> ok, its late and I'm now behind
[23:26] <gaurav_kl> ok..thanks..will go thru the implemation of Service and mail in case of doubt..
[23:27] <mdiggory> definitely send any questions or look me up on skype, google talk or here
[23:27] <gaurav_kl> yeah.
[23:30] * gaurav_kl (75c6251d@gateway/web/freenode/ip.117.198.37.29) Quit (Quit: Page closed)
[23:43] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.