#duraspace IRC Log

Index

IRC Log for 2011-07-13

Timestamps are in GMT/BST.

Conversation with #duraspace at 7/13/2011 8:28:35 AM on irc.freenode.net (irc)

NOTE: All times below are CDT. DuraLogBot had issues logging today, and these logs were captured instead by tdonohue's IRC client.

(9:52:53 AM) eddies [~eddies@2.130.114.78.rev.sfr.net] entered the room.
(9:52:53 AM) eddies left the room (quit: Changing host).
(9:52:54 AM) eddies [~eddies@unaffiliated/eddies] entered the room.
(10:10:57 AM) mhwood left the room (quit: Ping timeout: 264 seconds).
(10:24:10 AM) mhwood [~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425] entered the room.
(11:35:41 AM) grahamtriggs1 left the room.
(1:36:58 PM) eddies left the room (quit: Quit: Leaving.).
(2:05:36 PM) sandsfish [~sandsfish@18.111.75.31] entered the room.
(2:50:01 PM) KevinVdV [KevinVdV@d54C14A24.access.telenet.be] entered the room.
(2:56:14 PM) tdonohue: Hi all, reminder we have our weekly DSpace Devel meeting in about 5 mins : https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-07-13
(2:56:15 PM) kompewter: [ DevMtg 2011-07-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-07-13
(2:59:32 PM) aschweer [~schweer@schweer.its.waikato.ac.nz] entered the room.
(2:59:43 PM) hpottinger [80cea2c6@gateway/web/freenode/ip.128.206.162.198] entered the room.
(3:00:58 PM) robint [522921b0@gateway/web/freenode/ip.82.41.33.176] entered the room.
(3:01:00 PM) tdonohue: Hi all. Time for the DSpace Devel Meeting. Here's the agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-07-13
(3:01:01 PM) kompewter: [ DevMtg 2011-07-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-07-13
(3:01:35 PM) tdonohue: As always, starting off with JIRA Quick Review. Here's the JIRA issues we have left to review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-842+ORDER+BY+key+ASC
(3:01:35 PM) kompewter: [ https://jira.duraspace.org/browse/DS-842 ] - [#DS-842] Language switch for xmlui and some basic i18n stuff - DuraSpace JIRA
(3:01:38 PM) 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-842+ORDER+BY+key+ASC
(3:01:41 PM) tdonohue: First up, DS-842
(3:01:42 PM) kompewter: [ https://jira.duraspace.org/browse/DS-842 ] - [#DS-842] Language switch for xmlui and some basic i18n stuff - DuraSpace JIRA
(3:03:44 PM) mhwood: Killing off duplicated configuration is good...if it is duplicated.
(3:03:55 PM) tdonohue: thoughts on Claudia's work here. It looks like a good idea to me, at a glance. +1
(3:04:18 PM) aschweer: yes, it definitely sounds like it'd be useful for multilingual sites
(3:04:21 PM) tdonohue: yes, plus I do like the idea of a dropdown selection to change language on the fly (which is the other part of this patch)
(3:05:04 PM) tdonohue: Any volunteers to give it a quick test run, and report back to Claudia (so we can get it into 1.8)?
(3:05:27 PM) aschweer: I'll give it a go
(3:05:30 PM) robint: I'll have a look
(3:05:39 PM) robint: Doh!
(3:05:42 PM) aschweer: :) happy to leave it to you, Robin
(3:05:51 PM) tdonohue: sounds good. decide between yourselves aschweer & robint, or you can both give it a go :)
(3:06:00 PM) aschweer: ok will do
(3:06:03 PM) vibhajrajan [~Unnikanna@59.161.58.100] entered the room.
(3:06:11 PM) mhwood: Do we have any guidelines on when to duplicate a setting across UIs and when to consolidate? I seem to recall going the other way on something recently.
(3:06:39 PM) tdonohue: DS-842 summary: Seems to have approval. aschweer and/or robint will give it a test & report back. Tentatively scheduled for 1.8.
(3:06:40 PM) kompewter: [ https://jira.duraspace.org/browse/DS-842 ] - [#DS-842] Language switch for xmlui and some basic i18n stuff - DuraSpace JIRA
(3:07:06 PM) robint: Yes there was talk of allowing duplication in order to separate the xmlui and jspui configs
(3:07:48 PM) scottatm: There is one reason to keep those configs seperate.
(3:07:49 PM) tdonohue: yea..there was talk of duplication, but in those cases the duplicate was *across* different config files...e.g. the same setting in a xmlui.cfg and jspui.cfg may be duplicated
(3:08:04 PM) scottatm: You might have a translation for one language in the XMLUI while not having the translation in the JSPUI.
(3:08:25 PM) mdiggory [~mdiggory@rrcs-74-87-47-114.west.biz.rr.com] entered the room.
(3:08:43 PM) scottatm: But I think that is a very small use-case.
(3:09:26 PM) tdonohue: well, if we are still looking into creating a separate "xmlui.cfg" and a "jspui.cfg", then it seems like both configs could just have their own "supported.locales" setting. So, it would allow for different settings for XMLUI vs JSPUI
(3:09:41 PM) mdiggory: Hi all, is there an issue with the logbot still?
(3:10:02 PM) scottatm: Logbot is not in the channel.
(3:10:25 PM) mdiggory: looks like it was
(3:10:27 PM) mdiggory: http://irclogs.duraspace.org/index.php?date=2011-07-13
(3:10:27 PM) kompewter: [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2011-07-13
(3:10:29 PM) tdonohue: ugh, yes, looks like something is up with the Logbot again today. Sorry about that. I'll look into it after the meeting, and get my local logs posted
(3:11:14 PM) mdiggory: ok
(3:12:02 PM) tdonohue: I just reported it to our tech team. It's possible (if someone can get to it soon) the logbot will show up sometime during our meeting. In any case, I'll make sure full meeting logs get posted
(3:12:44 PM) tdonohue: Ok, moving on in JIRA. Next up DS-844
(3:12:44 PM) kompewter: [ https://jira.duraspace.org/browse/DS-844 ] - [#DS-844] Simplify, internationalize org.dspace.statistics.util.LocationUtils - DuraSpace JIRA
(3:13:47 PM) mdiggory: +1
(3:14:04 PM) aschweer: +1
(3:14:06 PM) tdonohue: +1 to DS-844 as well. All good ideas, just needs a volunteer to implement
(3:14:06 PM) kompewter: [ https://jira.duraspace.org/browse/DS-844 ] - [#DS-844] Simplify, internationalize org.dspace.statistics.util.LocationUtils - DuraSpace JIRA
(3:14:18 PM) mhwood: I'll add it to my list.
(3:14:38 PM) mdiggory: makes sense to use i18n, I only imagine that it gets more complicated in XMLUI
(3:15:08 PM) tdonohue: sounds good, Ds-844 summary: +3 votes, assign to mhwood
(3:15:10 PM) mdiggory: I wonder if theres a i18n catalog that already exists and uses Locale and/or properties files
(3:15:22 PM) mdiggory: rather than XML files
(3:15:44 PM) aschweer: well mhwood says in the issue that Locale already does half the work
(3:15:54 PM) aschweer: I agree with mhwood that the continent names can just go into messages.xml / Messages.properties
(3:16:19 PM) aschweer: and splitting out the country->continent mapping is just a bonus. the real problem are the hardcoded English strings
(3:16:31 PM) mdiggory: aschweer: the challenge is that Cacoon doesn't always take the easy or sensible path
(3:16:48 PM) mdiggory: Cacoon = Cocoon
(3:16:54 PM) vibhajrajan left the room.
(3:17:04 PM) aschweer: mdiggory: true
(3:17:48 PM) tdonohue: I suggest we just let mhwood look into implementation details around Cocoon/XMLUI. If it starts getting more complex, we can revisit this later
(3:18:09 PM) tdonohue: Next up, DS-845
(3:18:10 PM) kompewter: [ https://jira.duraspace.org/browse/DS-845 ] - [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA
(3:18:37 PM) mhwood: Assigned
(3:18:38 PM) tdonohue: mdiggory -- is this actually something you are wanting to do for 1.8.0 (i.e. by Aug 19 Feature Freeze)?
(3:20:10 PM) mdiggory: Yes, I would like to get the interfaces in place
(3:20:49 PM) mdiggory: it doesn't require commitment on a specific implementation, just agreement that its ok to add implements to the current DSpaceObject classes
(3:21:01 PM) mdiggory: and have them extend the interfaces
(3:21:13 PM) mdiggory: sorry "implement" the interfaces
(3:21:50 PM) mdiggory: I actually have a cleaner patch then this now
(3:22:17 PM) tdonohue: Ok, sounds reasonable enough to me. If you want to post the new patch, we can get some more eyes on it before 1.8
(3:22:19 PM) mdiggory: Its also important to note that it includes work to improve the DCValue / MetadataValue problem
(3:22:31 PM) mdiggory: by adding getters/setters to DCValue
(3:23:03 PM) mdiggory: both then implement IMetadataValue
(3:23:04 PM) mdiggory: public class DCValue implements IMetadataValue<MetadataField>
(3:23:16 PM) mdiggory: public class MetadataValue implements IMetadataValue<MetadataField>
(3:23:35 PM) robint: I'm still a bit ignorant about it all but generally have no problems with the idea
(3:23:48 PM) mhwood: Sounds good to me too.
(3:24:11 PM) mdiggory: we would release a dspace-core-api module that has the API in it.
(3:24:16 PM) scottatm: This sounds like it is going to break a lot of local customizations to DSpace. This will make the 1.8 release a hard to update release. But in the long run is sorely needed.
(3:24:17 PM) tdonohue: sounds good to me too, as long as it doesn't accidentally break anything else (doesn't sound like it should) :)
(3:25:02 PM) mdiggory: scottatm: its mostly a change of the class signature in DSpaceObject classes
(3:25:15 PM) mdiggory: no additional methods
(3:25:28 PM) mdiggory: (outside of the changes in DCValue)
(3:26:00 PM) mdiggory: as I said, I have a cleaner patch that does even fewer alterations to org.dspace.content
(3:26:03 PM) mhwood: Best to get word out early that this is coming, though.
(3:26:26 PM) robint: mdiggory: Just looking at SVN. It will include the various Legacy Services ?
(3:26:27 PM) mdiggory: thus the jira task and wiki documentation that has been prepared/proposed over the last year
(3:26:42 PM) aschweer: yes this feels like quite a substantial change for anyone who does code customisations. maybe this would be better in the release after 1.8?
(3:27:06 PM) mdiggory: robint: the impl is an "alternative" not required unless wanted
(3:27:13 PM) scottatm: Waiting until after 1.8 won't make it any easier.
(3:27:22 PM) tdonohue: +1 to getting word out early on this
(3:27:30 PM) scottatm: I don't believe there's any reason to wait.
(3:27:57 PM) aschweer: true I forgot that it's "just" the feature freeze coming up so soon, not the actual release
(3:28:06 PM) tdonohue: I think we probably need to get the new version of the patch posted ASAP, so we can review and get this done soon (this is not a patch that should wait till the 'last minute' of 1.8)
(3:28:07 PM) robint: mdiggory: How quickly do you think you could get it committed ?
(3:28:37 PM) mdiggory: robint: this week, its just been sitting waiting for feedback
(3:29:27 PM) sandsfish: +1 to new patch for review
(3:30:20 PM) tdonohue: mdiggory: so, maybe post the new patch this week, and then a few of us can review it and get it committed sometime very soon (hopefully by next week).
(3:30:25 PM) mdiggory: then patch is just the same method signature and DCValue changes
(3:30:56 PM) mdiggory: without imports/@overrides additions
(3:31:21 PM) mdiggory: the goal being just to limit the changes to the classes to be the bare minimum.
(3:32:11 PM) mdiggory: I don't think your getting me... the new patch is just a dropping lines like "+ @Override"
(3:32:15 PM) tdonohue: yep. sounds good. let's get the new patch posted, and then we can try and push this forward ASAP (I'll even volunteer to help review this one...others who are willing should also feel free to take a look)
(3:32:21 PM) JRhoads [~jrhoads@160.10.15.22] entered the room.
(3:32:48 PM) mdiggory: you can see everything that would change still in the current patch
(3:33:16 PM) tdonohue: mdiggory -- sounds good. just would rather review the new, cleaner patch (if that's what is actually to be committed), as its readability will also be improved.
(3:33:22 PM) kshepherd: is jira review over?
(3:33:40 PM) tdonohue: jira review is essentially over...this was the last JIRA issue, and it's gone on for a while
(3:34:11 PM) kshepherd: just want to give a quick plug for DS-768, if anyone can help test it :)
(3:34:12 PM) 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
(3:34:31 PM) aschweer: I should have some time for that one later today
(3:34:35 PM) kshepherd: very easy to test, i have a .jar built attached to the job that you can just drop into XMLUI libs
(3:34:39 PM) mdiggory: There are a few other details about the patch that could be discussed (Ds-845)
(3:35:02 PM) tdonohue: +1 to that. great job, kshepherd on that one! I can also try and take a look at Ds-768 in coming days)
(3:35:27 PM) hpottinger: kshepherd: Ds-768 is on my list to test this week or next
(3:35:33 PM) mdiggory: kshepherd: I still need to get you code for the old release of the cocoon stuff
(3:36:12 PM) tdonohue: mdiggory: what other details in Ds-845? I thought you said it's relatively simple ;)
(3:36:34 PM) mdiggory: Well, it is, but there are some "options"
(3:37:35 PM) kshepherd: mdiggory: yeah that'd be cool, thanks. i *think* the new patch should cover the previous cocoon fixes we'd made, but pays to be sure :)
(3:37:41 PM) mdiggory: You'll note in looking over the current patch, that the following are moved to dspace-core-api as entire classes
(3:37:42 PM) sandsfish: :) elaborate. this is the module that caused/fixed the white screen of death.
(3:37:42 PM) mdiggory: org.dspace.authorize.AuthorizeException
(3:38:06 PM) mdiggory: org.dspace.event.Consumer
(3:38:29 PM) mdiggory: org.dspace.authenitcate.AuthenticationMethod
(3:38:52 PM) mdiggory: org.dspace.core.Constants
(3:39:46 PM) mdiggory: The reasoning being that these are either (a) interfaces or (b) static constants referenced everywhere
(3:40:13 PM) mdiggory: sorry, I've mixed the topics here...
(3:40:48 PM) kshepherd: gotta go to work now, later all
(3:41:12 PM) mdiggory: kshepherd: I'll get you the code so you can make sure
(3:42:19 PM) tdonohue: ok. we've taken up a large portion of this meeting on Ds-845. I'm not sure I agree with creating a new 'dspace-core-api' at this time either (until we really figure out what we are doing around Async Releases). Should we move more discussion of this concept to dspace-devel?
(3:42:22 PM) mdiggory: per Ds-768 note that none of these interfaces or classes have package name changes, they are simply moved into the dspace-core-api jar from the dspace-api.jar
(3:42:38 PM) mdiggory: and dspace-api becomes dependent on dspace-core-api
(3:42:54 PM) tdonohue: I think you mean "per Ds-845", mdiggory?
(3:43:01 PM) mdiggory: probibly
(3:43:15 PM) mdiggory: yes I mean Ds-845
(3:44:20 PM) mdiggory: tdonohue: the goal of having a separate dspace-core-api is to be able to release addons dependent on it without having to be dependent on a specific dspace release. It pretty much is async release
(3:44:32 PM) tdonohue: so, I still think we may want to describe this 'dspace-core-api' idea on dspace-devel, so we can vote on it. Besides the 'dspace-core-api' idea, I think the rest of Ds-845 looks good.
(3:45:00 PM) mdiggory: I did previously
(3:45:05 PM) mhwood: So dspace-core-api is the interfaces and then dspace-api implements them? The names are giving me trouble.
(3:45:24 PM) mdiggory: because the legacy name of dspace-api was a mistake
(3:45:40 PM) mdiggory: (on my part, when I created it)
(3:45:55 PM) tdonohue: I worry that in Ds-845 it sounds like you are lumping "async release" (dspace-core-api idea) in with "Refactoring the domain model" (the rest of the Ds-845 patch). I don't necessarily think those are the same things.
(3:46:21 PM) mdiggory: tdonohue: they are complimentary
(3:46:39 PM) mdiggory: the domain model enables the async release process
(3:46:52 PM) mdiggory: because it is separated from the implementation of the model
(3:47:03 PM) tdonohue: right, and complimentary implies they should be two separate JIRA issues & two separate patches that are linked. So, it should be possible to put *one* into 1.8, and wait on the other until after 1.8 (if we felt necessary)
(3:47:25 PM) mdiggory: thats just making it more complex than it need be
(3:47:38 PM) mdiggory: the code in dspace-core-api is already there
(3:48:06 PM) mdiggory: it shouldn't be under trunk because that defeats the async release capability and negates the advantage of doing it
(3:48:36 PM) tdonohue: ok. we've gone way off topic here. we're snowballing a bit
(3:48:46 PM) robint: So dspace-core-api would not live in trunk ?
(3:48:53 PM) mdiggory: why have an api you can depend on separate from the implementation if they are released in the same jar?
(3:49:16 PM) mdiggory: it already does... as presented in the JIRA ticket
(3:49:23 PM) gaurav_kl [75c6254e@gateway/web/freenode/ip.117.198.37.78] entered the room.
(3:49:40 PM) aschweer: I do think there's a value in making small changes. so maybe mdiggory do the separation of implementation and interfaces first, and then we can think about distribution infrastructure
(3:49:42 PM) robint: Ah, I just hadn't realised that
(3:49:55 PM) mdiggory: tdonohue: I beleive we are just taking advantage of the presence of the team and discussing a couple aspects of the topic
(3:49:57 PM) mhwood: Because it's too big a change all at once? The same thing happend to "DSpace 2.0": it was really more like DSpace 5.0.
(3:50:16 PM) aschweer: mhwood +1
(3:50:19 PM) tdonohue: mdiggory: I think the problem here is that it's a sudden surprise that we should have a brand new "dspace-core-api" when this idea hasn't been voted on, and dspace-core-api isn't even mentioned in the description of Ds-845
(3:50:33 PM) mdiggory: ?
(3:50:48 PM) mdiggory: Its linked to in the description
(3:50:57 PM) tdonohue: am I confused then, mdiggory? where is dspace-core-api mentioned?
(3:51:06 PM) mdiggory: http://scm.dspace.org/svn/repo/modules/dspace-core/trunk/impl/src/main/java/org/dspace/
(3:51:07 PM) kompewter: [ repo - Revision 6462: /modules/dspace-core/trunk/impl/src/main/java/org/dspace ] - http://scm.dspace.org/svn/repo/modules/dspace-core/trunk/impl/src/main/java/org/dspace/
(3:51:18 PM) tdonohue: oh, whoops, my bad :)
(3:51:38 PM) mdiggory: thats the impl... but the link to api can be inferred
(3:51:50 PM) mdiggory: http://scm.dspace.org/svn/repo/modules/dspace-core/trunk/api/src/main/java/org/dspace/
(3:51:51 PM) kompewter: [ repo - Revision 6462: /modules/dspace-core/trunk/api/src/main/java/org/dspace ] - http://scm.dspace.org/svn/repo/modules/dspace-core/trunk/api/src/main/java/org/dspace/
(3:52:11 PM) tdonohue: so, we might as well make a decision on this then...what do others think about this DS-845 stuff. Do we want to create this dspace-core-api, or do we want to wait till after 1.8? or is everyone just +0 (don't care really)
(3:52:11 PM) kompewter: [ https://jira.duraspace.org/browse/DS-845 ] - [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA
(3:52:25 PM) robint: I hadn't realised that the fact it is currently in modules meant that it would not be moved to trunk
(3:52:56 PM) sandsfish: i'm sorry, i'm not quite clear on why it can't move to the trunk.
(3:53:11 PM) aschweer: sandsfish: same here
(3:53:21 PM) sandsfish: seems like if it's core, it shouldn't be a module
(3:53:27 PM) sandsfish: maybe i'm off on this...
(3:53:27 PM) mdiggory: (an aside, there is an ongoing discussion about modules strucutre and getting the modules that are "core" into a "supported" section)
(3:53:39 PM) tdonohue: it could be moved to trunk. I think mdiggory just would rather it sit in SVN modules, as it allows for Async Releases
(3:53:53 PM) mdiggory: its not in trunk because its released separately
(3:54:04 PM) mdiggory: so that DSpace "can be modular"
(3:54:14 PM) robint: Which brings us back to async releases
(3:54:21 PM) mdiggory: because as long as everying is crammed into trunk, you don't "have modular"
(3:54:22 PM) sandsfish: right, but we're still going to cut "DSpace" releases
(3:54:38 PM) aschweer: yes I think Ds-845 mixes two issues without needing to
(3:54:39 PM) mdiggory: yes we are, and they would still be offical
(3:54:58 PM) sandsfish: but doesn't this represent the hooks into a particular dspace ver?
(3:55:10 PM) sandsfish: and as such shouldn't shift? again, just trying to understand here.
(3:55:33 PM) mdiggory: Ok... I proposed this whole think... and is been under evolution over the last two years now... of course thay are mixed. I'vve explained why
(3:55:43 PM) tdonohue: mdiggory: you do have a form of modular if everything is in Trunk -- it's still modules, but they are just all released together. It depends on your definition of "modular"
(3:56:07 PM) mdiggory: no, I do not work that way
(3:56:17 PM) mhwood: Step 1 and step 2 keep getting tangled because what's being pursued is step 2.
(3:56:39 PM) robint: mhwood: well put
(3:56:45 PM) tdonohue: correct, mhwood
(3:57:28 PM) ***mdiggory scratching head? How can I make my goal any clearer...
(3:58:12 PM) sandsfish: mdiggory: what constitutes an official DSpace release for you? just so we can see what you imagine the separation to look like?
(3:58:47 PM) mhwood: The objective is clear: async. release of various subsystems. The tension here is that some want to organize the drive to the objective as a sequence of subgoals.
(3:58:59 PM) mdiggory: An official release of DSpace is the set of core modules defined as "supported" plus the dspace-api and associated webapps that we decide are core
(3:59:06 PM) tdonohue: well put again, mhwood.
(3:59:21 PM) sandsfish: i can see the value in releasing individual modules async, but still think we need a core group of projects that are stable that modules are tied to.
(3:59:43 PM) mdiggory: the goal is to allow portions of dspace-api that do not change at all and are contracts to have a longer lived release cycle than the dspace-api itself
(4:00:07 PM) mdiggory: dspace-core-api, once formally establieshed would change less than dspace-api does
(4:00:38 PM) mdiggory: and thus addons could depend on it independent of the dspace-api and offical release of dspace
(4:00:40 PM) tdonohue: mdiggory, to bring mhwood's comments back to Ds-845. This ticket could be split into two "subgoals"-- the first is just a refactoring of the DSpaceObject classes (which we all seemed to agree on), the second subgoal would be moving some classes to a dspace-core-api (which is the part where we were all disagreeing)
(4:00:46 PM) robint: One of the things that puts people off is when they discover that to allow for async releases of modules the source for thos modules cant be distributed in a full release
(4:00:57 PM) mdiggory: thus addons could be used across DSpace versions easily
(4:01:29 PM) mhwood: But that's just defining interfaces. Building an async release structure doesn't have to be done at the same time. Tearing off the interfaces enables that after we've digested the changes that create dspace-core-api.
(4:01:38 PM) mdiggory: Ok, maybe I
(4:02:18 PM) mdiggory: I'm missing if this is about the move of a few classes, or if its about the dependency and existence of dspace-core-api outside of trunk
(4:02:52 PM) sandsfish: if dspace-core-api is going to change less than dspace-api, why not just release it each time a DSpace release is cut. isn't it just tie-ins that _may_ change if dspace-api does, which will be a synchronous release? what would be the use case for releasing a new dspace-core-api outside of a dspace + dspace-api release?
(4:03:22 PM) sandsfish: (i see we're at 5:02 here, so we're running over as of now.)
(4:03:59 PM) mdiggory: sandsfish: because theres a cyclical dependency that we (er um "I") and trying to break by not releasing it with the rest of DSpace.
(4:04:42 PM) mdiggory: If you've read / reviewed any of the async release and domain model proposals in the wiki, this is stated within it
(4:04:44 PM) tdonohue: mdiggory -- the issue right now is just around dspace-core-api, I believe. I think we had questions about whether that was necessary in 1.8, or if we could just do the refactoring of DSpaceObject classes in 1.8, and leave the dspace-core-api work to just after 1.8
(4:05:02 PM) ***tdonohue we are running over here
(4:05:07 PM) mdiggory: god no.... please
(4:05:55 PM) mhwood: What I think I'm reading between the lines is that there are two models competing. One wants to define which pieces go in the center of DSpace, and the other says there is no center. ???
(4:06:32 PM) mdiggory: mhwood: no, there is a center... its just not defined as "trunk"
(4:06:54 PM) mdiggory: its just not bound to an SCM, its instead a Maven assembly
(4:07:22 PM) mdiggory: an assembly of several clearly defined subprojects
(4:07:46 PM) aschweer: sorry, I need to leave. bye all.
(4:07:47 PM) ***tdonohue all, we are well over time here -- if you have to head out, feel free. I'm going to stick around more though (obviously)
(4:07:48 PM) aschweer left the room (quit: Quit: leaving).
(4:08:11 PM) mdiggory: (the aside concerning grouping modules under "supported" is also important to meeting the need of "central"
(4:08:12 PM) mhwood: Time to go back to the ML, with more time to explain stuff?
(4:08:29 PM) robint: But the Maven assembly would assemble the source code into one deliverable release ?
(4:08:50 PM) mhwood: The center of DSpace is a POM. Just a POM. Yes?
(4:08:58 PM) mdiggory: the maven assembly would group released subprojects of dspace into one distribution
(4:08:59 PM) robint: Or assemble what is effectively a binary release ?
(4:09:11 PM) JRhoads left the room.
(4:09:26 PM) mdiggory: mhwood: no
(4:09:30 PM) robint: mdiggory: but source code or artifacts ?
(4:09:42 PM) mdiggory: robint: artifacts
(4:09:45 PM) tdonohue: mdiggory -- but, in that 'grouped' distribution, can you still get release both a "source release" and a "binary release" (just as we currently do)
(4:10:05 PM) robint: That is where I have problem
(4:10:12 PM) mdiggory: if you want the sourceode for an artifact, you can check it out of SVN or we can, yes, create a source release that groups them all into one build
(4:10:25 PM) robint: In order to have async releases you cant distribute the source code
(4:10:26 PM) mdiggory: robint: why, we already do it
(4:10:42 PM) robint: We only do it for peripheral modules at present
(4:10:42 PM) mdiggory: we have a "release" and src-release"
(4:10:53 PM) mdiggory: no, we do it for dspace-api et al
(4:11:08 PM) robint: Dont understand
(4:11:09 PM) mdiggory: dspace-release-x.x.x.zip
(4:11:21 PM) robint: Ah sorry
(4:11:33 PM) robint: As an existing binary release
(4:11:54 PM) mdiggory: only has /dspace in it and is used to build a dspace install without compiling sourcecode
(4:12:17 PM) robint: But we also do source code releases and they have the majority of the source code therein
(4:12:21 PM) mdiggory: it downloads all artifacts as jars/wars freom maven
(4:12:32 PM) mhwood: Sorry, gonna have to check the log later. Must dash. Thanks!
(4:12:53 PM) sandsfish: sorry all, have to run. interested to hear the outcome of this, whenever that occurs. sounds like this needs a little clearer sketching out. perhaps as an image. cheers.
(4:12:56 PM) tdonohue: mdiggory -- so, the problem comes in when people want to do things like Overlays. When it comes to overlays, people often need access to Source Code, and we won't want to force them to search it out somewhere in SVN (which may not be very straightforward)
(4:13:03 PM) sandsfish left the room (quit: Quit: sandsfish).
(4:13:07 PM) mdiggory: robint: yes, but almost always we (@mire) do not use that distro when deploying/customizing a dspace
(4:13:47 PM) mhwood left the room.
(4:13:48 PM) mdiggory: tdonohue We get the sourcecode from the svn or the released source jar in Maven.... it works great
(4:14:25 PM) robint: But you guys work withDSpace full time
(4:14:44 PM) tdonohue: Right. I wasn't exactly clear that you were saying we could still do the *exact same* 'dspace-src.release.zip' from SourceForge.
(4:14:57 PM) mdiggory: we also do not recommend altering the source "in place" and rereleasing the jars with the same version number because then you havn't a clue whats int he jar
(4:15:20 PM) stuartlewis [~stuartlew@s-lewis.itss.auckland.ac.nz] entered the room.
(4:15:20 PM) mdiggory: or I mean "which variant of the jar your really working with"
(4:15:32 PM) tdonohue: essentially, I'm saying something similar to robint. I'm worried that splitting out all our modules away from Trunk would make it *more difficult* for novice developers to understand how DSpace functions and where the code all is.
(4:16:36 PM) tdonohue: I understand though why it could benefit *expert developers* in some ways (with async and all that). But, we need to be thinking both about *novice* DSpace users/developers as well.
(4:16:44 PM) mdiggory: well, TBH, I feel the oposite.
(4:17:07 PM) ***PeterDietz sorry all. Had All-Staff meeting
(4:17:11 PM) mdiggory: Its harder and harder to work with DSpace the more and more stuff is shuvled under trunk and called "dspace"
(4:18:02 PM) mdiggory: more and more "experimental" code and changes that get under one monolithic project, the more and more difficult it is to track the important parts
(4:18:34 PM) tdonohue: mdiggory: not sure how it is the opposite. If you are a novice developer, and you are looking for something in the "org.dspace.core.Constants", how would you know to look in the /modules/dspace-core/ area (instead of Trunk or one of the other many things under /modules).
(4:19:04 PM) mdiggory: search
(4:19:59 PM) mdiggory: TBH, no one outside of the Core team should be altering a class like "Constants"
(4:20:13 PM) robint: But people do
(4:20:25 PM) mdiggory: or I mean, only "contributions" to the core should alter Constants
(4:20:43 PM) tdonohue: mdiggory: But what if they are just fixing a small bug, or wanting to give us a patch? then they may need to alter core classes to do that
(4:20:52 PM) mdiggory: robint: its a bad practice and the community should make it clear that it is so, not promote doing it
(4:21:21 PM) mdiggory: tdonohue: I corrected my statement right be fore your last post
(4:22:23 PM) robint: Could we not still do a binary and source release
(4:22:38 PM) mdiggory: Yes, we can make maven assemblies for both
(4:22:46 PM) robint: Just the source release would be an aaggregate of trunk and modules ?
(4:22:46 PM) tdonohue: we could, robint. I think we could still do a dspace-src-release and a dspace-release
(4:23:06 PM) robint: mdiggory: you answered my question :)
(4:23:13 PM) mdiggory: correct, though I'd still not use it
(4:23:32 PM) mdiggory: why would I want to rebuild something that was already released.
(4:23:34 PM) tdonohue: but, novice developers would use it, cause it's an easy way to get all source code together
(4:24:17 PM) mdiggory: thats why they call JAVA ... write once, run everywhere
(4:24:32 PM) robint: And not everyone would be interested in taking advantage of async releases
(4:25:31 PM) robint: In an ideal world just doing a binary release would olve lots of problems, but I am worried about the reaction from the community
(4:25:34 PM) robint: olve/solve
(4:26:01 PM) mdiggory: tdonohue: I suppose if your into torture, you could recompile the JVM as well, so what if you have the source, does that really bring you a greater ability to use a JVM?
(4:26:07 PM) tdonohue: yea, I think the community would not like that. They need easy access to Source Code for even some small changes or to provide patches back to us, etc
(4:26:35 PM) tdonohue: mdiggory: DSpace is not a JVM. People don't need to customize the JVM to better fit their local institutions needs
(4:27:12 PM) mdiggory: Depends on the institution ;-)
(4:27:53 PM) mdiggory: I've seen cases where javax classes were overriden in source before
(4:28:00 PM) mdiggory: very very scarry
(4:28:11 PM) robint: Whose side are you on now ? :)
(4:28:34 PM) mdiggory: the side of stability... ;-)
(4:28:36 PM) tdonohue: mdiggory: yea, but still..JVM does not advertise itself as being something you can easily theme/change for your local institution. DSpace does.
(4:30:10 PM) mdiggory: tdonohue: I'm just trying to clarify where the misinterpretation of the best practices of Maven and Java are emergent in the DSpace community.
(4:30:40 PM) hpottinger: speaking as a member of the community, I'd happily change back to a binary release if src release weren't the "lingua franca" on the mail lists
(4:31:28 PM) tdonohue: I'm just worried that it could scare away novice developers or cause people to think DSpace is "hard to customize" or "too complex to really customize/work with". I understand many of the benefits, but I worry about whether it makes it harder to get community-contributed patches/changes/features.
(4:31:33 PM) mdiggory: I repeatedly find myself swimming against the current because those "not so great" practices have become extremely prevalent
(4:31:54 PM) tdonohue: (but, if we find a way to make this as easy or easier for novice developers, then I'd be all in)
(4:32:08 PM) robint: me too
(4:32:29 PM) mdiggory: can you identify the experience level of these novice developers you refer to?
(4:33:03 PM) tdonohue: A Java developer (or someone potentially even a little new to Java) who has just been hired to help Customize DSpace for a local IR
(4:33:20 PM) robint: Real world example...
(4:33:21 PM) tdonohue: (so, this developer may not have *any* previous Maven experiences, etc)
(4:33:23 PM) mdiggory: because customizing any software applications source requires a certain level of proficiency
(4:33:33 PM) robint: The Jorum project I orked on recently
(4:33:53 PM) robint: The guys were good developers
(4:34:12 PM) robint: But inexperienced in Maven so didn't use overlays
(4:34:27 PM) robint: and heavily customised the dspace-api classes
(4:34:36 PM) robint: including Constants
(4:35:10 PM) mdiggory: was that they were unable or unwilling to learn
(4:35:23 PM) robint: Does it matter ?
(4:35:59 PM) mdiggory: because I think we have provided sufficient tutorials and documentation on how to customize dspace that a true novice could pick it up.
(4:36:11 PM) tdonohue: I think we need to realize that at many institutions, the developer (if there even is one) working on their local DSpace is usually semi-proficient at Java. But, in most scenarios they may have no (or little) proficiency with Maven or Cocoon or similar
(4:36:39 PM) mdiggory: Ideally, by the time we get done here, such a developer wouldn't need to write java
(4:36:52 PM) mdiggory: or possibly even be a developer at all
(4:37:01 PM) tdonohue: mdiggory: that's assuming this developer also has *time* to read all those docs & tutorials. Not all institutions even have a developer who is dedicated to the IR. Many have to share a developer with other projects
(4:37:46 PM) mdiggory: Sounds like you want your cake and eat it to.
(4:37:53 PM) tdonohue: right, mdiggory: I agree with that end goal (no needing Java or being a developer). But, we cannot make it 100% more difficult before we make it 75% easier (i.e. we don't want to move in the wrong direction in the short term)
(4:38:17 PM) tdonohue: mdiggory: ? No, I'm just being realistic. Most institutions do not have a dedicated developer for DSpace
(4:38:33 PM) tdonohue: We need to realize that is the truth of the situation.
(4:39:58 PM) mdiggory: Still not getting it, so what then, they don't do java customization then
(4:40:08 PM) tdonohue: All I'm saying is we need to keep DSpace development *reasonable* and relatively easy to learn/pick up.
(4:40:44 PM) mdiggory: I think it is. We teach it regularly and everyone "gets it" when we do our tutorials
(4:41:02 PM) mdiggory: and TBH @mire tutorials don't use the src release
(4:41:18 PM) tdonohue: Currently, I think those development processes are reasonable. Someone (in little time) can go to SVN Trunk, get all the source code and start learning how things work. Once we start moving around where the "source" is, then we need to just be careful about whether we are making things too complex or not.
(4:42:07 PM) tdonohue: I'm just saying: everything in moderation
(4:42:20 PM) mdiggory: There are two reasons for not doing that
(4:42:34 PM) mdiggory: 1.) Because you do not want them to change that "contract"
(4:43:03 PM) mdiggory: 2.) Because they should know what they are doing if they did want to change that contract
(4:43:08 PM) robint: Sorry guys I have to head off. I'll stay online so I can read this later. Cheers.
(4:43:46 PM) mdiggory: The whole point of keeping the contract separate is to keep them from hanging themselves by changing it
(4:44:26 PM) tdonohue: mdiggory: I was just talking about Source Code as a *learning tool* (it's amazing what you can learn from it). Not necessarily about these developers going in and changing core code (unless they found a bug they wanted to patch for us, of course)
(4:44:28 PM) ***hpottinger has to head out, too, will check the logs later, very interesting conversation
(4:44:53 PM) hpottinger left the room (quit: Quit: Page closed).
(4:45:19 PM) mdiggory: tdonohue: as robint just showed us, even seasoned java developers will not use the best approaches
(4:46:33 PM) tdonohue: right, but that's no reason to "wall off" any source code (or obscure it). We should be making it as easy as possible for developers to develop with DSpace (because that encourages more development & more contribution). I'm just wanting to make sure we aren't building "unnecessary" walls/boundaries to development
(4:47:10 PM) mdiggory: tdonohue: thats where I get really confused... If I want to look at the source I go to one of two places... (a) the internet (b) an IDE like Intellij where I can navigate the class hierarchy and explore the entire codebase
(4:47:34 PM) mdiggory: the source code isn't walled off from view...
(4:48:49 PM) mdiggory: the separation is an assertion that the api is a contract separate from any implementation of that API
(4:49:16 PM) tdonohue: mdiggory: I agree with that approach to finding source code (searching, etc). I'm just pointing out that it becomes a little more complex to develop with Dspace if you have to do 5-10 SVN checkouts in order to see all the source. (and to figure out what SVN checkouts you needed to do, you may have needed to do 5-10 searches to find that source location)
(4:50:08 PM) tdonohue: So, as an example: Suppose you are a new Developer, and you want to Develop with DSpace 10.0 (imaginary version number used on purpose)...
(4:51:12 PM) tdonohue: Ok..step one: you'll go get your IDE. Step Two: let's checkout the DSpace 10.0 "Trunk"...whoops, no real source code here. Step 3: Ok, I really want the XMLUI, so let's go see if I can find the XMLUI Source for DSpace 10.0
(4:51:17 PM) mdiggory: 1.) You download Eclipse or IDEA or Netbeans so you can learn how to develop a Java application
(4:52:06 PM) tdonohue: Step 4: Found the XMLUI source. Step 5: Oh wait, but I also needed the source for Discovery...now where is that? Step 6: oh, finally found it...I guess Dspace 10.0 must use Discovery version 4.4.3
(4:52:18 PM) tdonohue: Step 7: Oh but wait, I also need the Stats engine...where is that?
(4:52:20 PM) tdonohue: etc
(4:52:23 PM) mdiggory: 2.) You make sure you have MAven integration (Eclipse will need it)
(4:52:32 PM) mdiggory: 3.) YOu checkout trunk and build dspace
(4:53:16 PM) mdiggory: 4.) If you want to Override a Class you run the search in the IDE, in IDEA< that returns that source code from the maven repo you are seeking
(4:54:17 PM) mdiggory: 5.) You copy the file into your modules and alter it
(4:54:26 PM) mdiggory: copy = copy/paste
(4:54:40 PM) mdiggory: 6.) you recompile
(4:55:44 PM) tdonohue: ( I think your Step 4 includes an IDEA specific feature in the returning Source Code from Maven repo -- I don't think NetBeans or Eclipse does that? But, it does sound like a nice feature.)
(4:56:25 PM) mdiggory: I believe that both IDEA and m2eclipse support searching through source jars for code
(4:57:19 PM) mdiggory: I don't use netbeans because IDEA always seems to be more advanced, but I understand your point.
(4:58:29 PM) tdonohue: yea, the point is, we need to make sure there are also paths for the lowest common denominator in terms of IDEs. unfortunately, the absolute lowest common denominator is the text editor -- but hopefully no one is using that (and we can recommend some sort of IDE usage) :)
(4:59:19 PM) mdiggory: that said, you can take the argument in the opposite direction and take us altheway back to dspace 1.4 having to look for anything outside the src/java directory is just too much work for the developer, it should all be under one source tree to make it easy to see all the code.
(5:00:38 PM) robint left the room (quit: Ping timeout: 252 seconds).
(5:00:40 PM) tdonohue: mdiggory: i'm not a fan of looking at past decisions as an argument for future decisions :)
(5:00:44 PM) mdiggory: Sorry, I can keep arguing around this tree right now
(5:01:01 PM) kshepherd: to be honest, i'm less worried about the extra projects i'll need open, checkouts i'll need to do (and the lack of IDE support in general for hopping around code that isn't in the project workspace you're looking at), and more worried about the whole stable vs unstable vs untested vs sandbox modules
(5:03:08 PM) mdiggory: So, it would seem that we have a very huge difference of opinion in the community. I'm not convinced I can resolve this.
(5:03:13 PM) tdonohue: kshepherd: you mean how well "tested" these modules are when they are released asynchronously?
(5:03:18 PM) kshepherd: yeah
(5:03:23 PM) kshepherd: or even how many people know they exist
(5:03:44 PM) kshepherd: and realise they could be downloading and building unreviewed code
(5:04:48 PM) tdonohue: yea, I'd agree with that concern as well. There still needs to be testathons to ensure that the "core modules" (whatever those modules may be) are all stable and work together well.
(5:04:51 PM) kshepherd: not saying that's an unsolvable problem, just something that needs care.. a separate svn area (and maybe different naming scheme?) for modules that trunk depends on
(5:05:27 PM) mdiggory: I think thats a false sense of security, reviewed by who? How many commits of code to trunk come through with only one set of eyes ever having seen them...
(5:05:31 PM) kshepherd: and awareness amongst devs and reviewers that they need to test all sorts of other stuff other than trunk
(5:05:54 PM) kshepherd: ok well, fair enough, but most of the bad stuff i've seen lately has been hiding in modules
(5:05:58 PM) mdiggory: I suggest prior to the introduction of a lead developer, a large majority
(5:06:20 PM) tdonohue: mdiggory: the "testathon" gives people security though...they have the ability to help us test the next version of DSpace to ensure it seems stable to them, etc.
(5:06:50 PM) mdiggory: I'm sorry, I have work to get done.
(5:07:18 PM) kshepherd: if we have no faith in trunk then i guess my concerns aren't relevant, but i think a lot of people do see and check commits as they happen to trunk
(5:07:28 PM) kshepherd: they wouldn't if the commit was to "kims-funny-sandbox-module"
(5:07:41 PM) kshepherd: and then one day, when that module sneaks its way into a dspace release...
(5:07:43 PM) tdonohue: I gotta go to. I think there is a difference of opinion here, but I don't think it's insurmountable. I just think we really need better examples of how our processes would change in this "new model of development"
(5:08:07 PM) gaurav_kl left the room (quit: Quit: Page closed).
(5:08:20 PM) mdiggory: the problem is that I don't have time to invest creating more examples than I already have
(5:08:42 PM) mdiggory left the room.

These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.