Timestamps are in GMT/BST.
[6:48] -wolfe.freenode.net- *** Looking up your hostname...
[6:48] -wolfe.freenode.net- *** Checking Ident
[6:48] -wolfe.freenode.net- *** Found your hostname
[6:48] -wolfe.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:48] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:48] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:14] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[8:26] * peterdietz (uid52203@gateway/web/irccloud.com/x-ztybfjmkmnqplwuk) Quit (Quit: Connection closed for inactivity)
[12:52] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:14] * peterdietz (uid52203@gateway/web/irccloud.com/x-egejxgycqnjviogq) has joined #duraspace
[13:59] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[14:11] * helix84 (~ctenar@195.178.95.132) has left #duraspace
[14:11] * helix84 (~ctenar@195.178.95.132) has joined #duraspace
[14:21] * kdweeks (~Adium@2001:468:c80:a103:1dd9:370:1b73:81e6) has joined #duraspace
[15:12] * kdweeks1 (~Adium@2001:468:c80:a103:e94c:959d:c1ec:c693) has joined #duraspace
[15:13] * kdweeks (~Adium@2001:468:c80:a103:1dd9:370:1b73:81e6) Quit (Ping timeout: 246 seconds)
[15:22] * terry-b (~terry-b@71-212-24-25.tukw.qwest.net) has joined #duraspace
[16:25] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:51] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[19:40] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[19:49] <peterdietz> DSpace Developer Meeting Starts in #duraspace in 10 minutes. We are currently in #dspace doing a jira review
[19:55] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[19:58] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) has joined #duraspace
[20:04] <peterdietz> Hi All, hopefully you are all refreshed and caffienated. Its time for the developer meeting
[20:05] <hpottinger> hello!
[20:05] <peterdietz> So. The first topic, is what to call DSpace 6.
[20:06] <mhwood> ?
[20:06] <hpottinger> (crickets)
[20:06] <peterdietz> Just kidding. Its going to be called best release ever. I'm filling in for Tim today
[20:06] <hpottinger> https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-09-02
[20:06] * cknowles (uid98028@gateway/web/irccloud.com/x-mrnehqynahdzguma) has joined #duraspace
[20:06] <mhwood> Ambling Aardvark? Best Thing Since Sliced Bread?
[20:07] <hpottinger> I propose: "The next release of DSpace"
[20:07] <mhwood> Works for me.
[20:07] <peterdietz> File Factory (since services has so many factory methods)
[20:07] <peterdietz> Services. I think we should look at Kevin's PR's and merge those, and then anything that needs discussing
[20:08] <hpottinger> aha, "The next release of DSPace: code name "Services" "
[20:08] <KevinVdV> Well please don’t merge all of em…. some still need work… liek the BundleBitstream one
[20:08] <peterdietz> here are kevin's pulls: https://github.com/DSpace/DSpace/pulls/KevinVdV
[20:08] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls/KevinVdV
[20:08] <hpottinger> so, anybody about to press a green button, like, stop
[20:09] <KevinVdV> https://github.com/DSpace/DSpace/pull/1037 & https://github.com/DSpace/DSpace/pull/1029 should be safe
[20:09] <kompewter> [ [DS-2729] Ensure SiteService extends DSpaceObjectService by KevinVdV · Pull Request #1037 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1037
[20:09] <kompewter> [ [DS-2714] Oracle migration script for the service based api by KevinVdV · Pull Request #1029 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1029
[20:09] <KevinVdV> But I would like another test user on the oracle
[20:09] <peterdietz> There was discussion somewhere on wanting to have proper SiteService
[20:09] <hpottinger> right about now, tdononhue is scrolling through the chat log a bit faster
[20:10] <peterdietz> And what are our limitations / goals with SITE. Its part of DSpaceObject
[20:10] <peterdietz> Is SITE a singularity. Or, could you theoretically have multiple sites.
[20:10] <peterdietz> Site[0] = UniversityA, Site[1] = UniversityB
[20:10] <KevinVdV> Well at the moment SITE is singular
[20:11] <mhwood> Let's make it a fully functional singular object first, please.
[20:11] <KevinVdV> For information Site is now already a DSpaceObject: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Site.java
[20:11] <kompewter> [ DSpace/Site.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Site.java
[20:11] <peterdietz> I think it would be cool is this feature could evolve. But yes, make it fully functional as a single. And then we could expand upon it, and eventually support the idea of adding multiple sites
[20:12] <KevinVdV> https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/SiteServiceImpl.java#L40
[20:12] <kompewter> [ DSpace/SiteServiceImpl.java at DS-2701-service-api · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/SiteServiceImpl.java#L40
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:12] <KevinVdV> Proof that at the moment you can only have one site object
[20:13] <peterdietz> singular is fine for now. One can get/set metadata for site, with siteservice though?
[20:13] <mhwood> Yes, I remember that. Any reason not to pull this one?
[20:14] <KevinVdV> There is NO reason that site shouldn’t have the ability to receive metadata (although untested)
[20:14] <KevinVdV> Since the metadataValue table just links to any DSpaceObject UUID
[20:14] <peterdietz> okay DSPR#1037 is +1 from me
[20:14] <kompewter> [ https://github.com/DSpace/DSpace/pull/1037 ] - [DS-2729] Ensure SiteService extends DSpaceObjectService by KevinVdV
[20:14] <mhwood> That's +2, tested.
[20:15] <peterdietz> okay. I'll press merge
[20:16] <peterdietz> Kevin said don't merge bundlebitstream #1035
[20:16] <peterdietz> should we discuss that one, or go to #1029
[20:17] <KevinVdV> I would just like to state that the BundleBitstream work is awaiting the JSPUI as to not inturrupt that work
[20:17] <KevinVdV> I will rebase mine when done & then it can be merged
[20:17] <peterdietz> I don't like booting up the oracle dev environment. Hopefully hpottinger can run an oracle test
[20:18] <mhwood> My Oracle test environment is still broken. alas.
[20:19] <peterdietz> I'm guessing merge the oracle (and postgres) fix, and people can eventually provide feedback?
[20:19] <mhwood> That sounds right.
[20:19] <KevinVdV> Sounds good for me ….. just don’t blame me if things break ;)
[20:20] <peterdietz> okay. Thats what I recommend then. Proceed with #1029 (Oracle). I'll click
[20:21] <peterdietz> 1029 = merged
[20:21] <hpottinger> if you all need my help testing, you'll have to hit me with a big hammer, I'm swamped with issues resulting from our recent upgrade to 5.x
[20:21] <peterdietz> 1035 is waiting for all the refactors to get merged, so that you can just rebase and run a refactor
[20:22] <hpottinger> I haven't spun up an oracle test instance in a long time
[20:22] <mhwood> I think we're just waiting on JSPUI now? (Not surprising -- it's big.)
[20:23] <peterdietz> Are all UI's merged? I haven't merged REST
[20:23] <hpottinger> I'll note that abolinni asked for help in finishing up JSPUI + Services on the _dev mail list
[20:23] <peterdietz> ( i clicked the checkmark button though...)
[20:23] <KevinVdV> Bitstream hasn’t been merged yet
[20:24] <KevinVdV> Rest hasn’t been merged yet I mean
[20:24] <hpottinger> quoting from abollini's e-mail dated 8/30/2015: I still need to refactor all the scriptlet in the jsp files, it is
[20:24] <hpottinger> really a lot of work so if other are available to help just let me know
[20:24] <hpottinger> so to split the jsp between us.
[20:25] <peterdietz> I haven't gotten feedback / review on REST. Should I just merge it?
[20:26] <KevinVdV> Where is the pull request located ?
[20:26] <peterdietz> https://github.com/DSpace/DSpace/pull/1026
[20:26] <kompewter> [ [DS-2701] REST API by peterdietz · Pull Request #1026 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1026
[20:27] <KevinVdV> Taking a quick look
[20:30] <mhwood> I think I may have added ItemService.countItems too.
[20:31] <KevinVdV> Perhaps a rebase will solve that issue ?
[20:31] <mhwood> Oh, not that signature, though.
[20:31] <peterdietz> umm.. likely to cause merge/rebase conflict if we all/both touch the same file
[20:32] <mhwood> I'd have to go look at what I did, but I don't think these collide, now that I look at his.
[20:33] <KevinVdV> I do see a lot of integer based identifiers that are used for “deleteCommunityCommunity()” for example. This will not work with communities created post DSpace 6
[20:33] <KevinVdV> Perhaps pass it along as a String & then use “findByIdOrLegacyId()” method
[20:34] <KevinVdV> Which will attempt UUID & if it fails integer based lookup
[20:34] <peterdietz> ..or make a method with int as param, and method with string as param... hmm. I'd like to have a way to not have to keep findByIdOrLegacyId forever
[20:35] <peterdietz> A question we had the other day. What do you call the UUID?
[20:35] <peterdietz> if collection_ID used to int.. Whats the DSO's UUID field... ID or UUID
[20:36] <mhwood> I'd say UUID. It's what it is, and it should be understood as an identifier.
[20:36] <KevinVdV> https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/DSpaceObject.java#L31
[20:36] <kompewter> [ DSpace/DSpaceObject.java at DS-2701-service-api · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/DSpaceObject.java#L31
[20:36] <KevinVdV> https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/DSpaceObject.java#L107
[20:36] <kompewter> [ DSpace/DSpaceObject.java at DS-2701-service-api · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/DSpaceObject.java#L107
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:36] <KevinVdV> The new getID() will return a UUID which is now the primary identifier. The old integer based identifier will not be updated any longer.
[20:36] <KevinVdV> Although not removed for backwards compatibility
[20:36] <peterdietz> I don't have integration tests on REST, to ensure that strange bugs don't creep in
[20:38] <KevinVdV> Well we don’t have any integration tests on the API either …. who knows what I broke……
[20:38] <mhwood> *sigh* I need to get busy and contribute at least the bits that enable use of Failsafe.
[20:38] <mhwood> Actually we have a lot of integration tests in dspace-api, disguised as unit tests.
[20:38] <peterdietz> To minimize disruption to rest. I had previously called something an ID, and it was of type int. I now have another identifier, and it is of type UUID. I'm going to call the new identifier uuid in rest, and leave the old id (int) alone.. Though, I'm not sure what the value should be of ID once an object comes through that has no ID value
[20:39] <mhwood> Don't provide the ID field at all, if it has no value?
[20:39] <peterdietz> ...or just make a big change that says DSpace 5 and below were a different version of REST. 6+ is a new version
[20:39] <peterdietz> anyways..
[20:40] <peterdietz> I was hoping to ensure compatibility
[20:40] <KevinVdV> Well you could pass along identifier as a string
[20:40] <KevinVdV> & then use the “https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/service/DSpaceObjectLegacySupportService.java#L23” method
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:40] <mhwood> Users of REST will be expecting that ID is parseable as integer.
[20:41] <KevinVdV> & leave it like that for ONE DSpace servervice
[20:41] <peterdietz> Thinking for a moment longer. Don't merge REST yet. I want to revisit some of that. Yes. some clients are expecting an identifier to be of a certain format.
[20:44] <peterdietz> okay. anything next to review.
[20:45] <peterdietz> I missed the UI prototype meeting this week. But there have been meetings and discussions, and documents going around as the UI project shapes up
[20:46] <peterdietz> schedule suggests that between August and October that people will develop 2-3 prototypes that will be analyzed by a committee
[20:47] <peterdietz> Its too bad the way that timelines work.. I'd much rather work on a jvm-based UI that uses services refactor, than a UI that has to talk to traditional dspace-api
[20:47] <peterdietz> REST is there, it provides an interface. But services / dspace-api provides ALL functionality
[20:48] <cknowles> Documents links for judging criteria and prototype guidelines are on the wiki if anyone wants to look and comment
[20:48] <mhwood> Well, two more projects and then we should be ready to pull the branch in.
[20:49] <peterdietz> In other news. mhwood and I have been looking into finishing up external handle integration. Mark has a pom approach. And I've built a gradle application that makes it easy to compile that jar that you need to plop into the stock handle daemon.
[20:49] <hpottinger> cknowles: link?
[20:50] <peterdietz> https://wiki.duraspace.org/display/DSPACE/2015-08-31+UI+Working+Group+Meeting+notes
[20:50] <kompewter> [ 2015-08-31 UI Working Group Meeting notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/2015-08-31+UI+Working+Group+Meeting+notes
[20:50] <mhwood> I think there have been such links in followup messages about the meetings.
[20:51] <mhwood> (I've been trying to at least lurk, but things keep taking me away.)
[20:52] <peterdietz> The basic gist of what we're expecting is something that uses REST or dspace-api, to create a webapp, that mimics what an anonymous user sees when visiting dspace (so community/collection/item/bitstream, and browse experience).
[20:52] <hpottinger> likewise, I wanted to attend these meetings, but, you know, life
[20:52] <peterdietz> ...and then to do something advanced, such as log in, and allow the user to perform an action or two.
[20:53] <mhwood> To be specific, "external handle integration" is the one that pbecker and abollini created to make the existing approach (DSpace provides storage of Handle records itself) work across a network.
[20:54] <peterdietz> yes, abolini and Pascal already built it all, and its in DSpace 4+.. https://trydspace.longsight.com/handleresolver/listprefixes
[20:54] <mhwood> It just needs some packaging work.
[20:54] <mhwood> And integration of the documentation, I think?
[20:54] <peterdietz> We're just realizing that nobody knows how to actually connect a handle server to use this. docs + integration steps
[20:55] <mhwood> Oh, that's easy. It works the way the original plugin worked.
[20:55] <mhwood> Get the plugin onto the Handle server's classpath, configure the server to call it rather than the built-in database backend.
[20:56] <peterdietz> it should make it so that its easier to host a dspace. And don't need to open 2641 and 8000 on EVERY SINGLE HOST.. But just once for your external handle gateway. And then it can handle multiple DSpaces
[20:56] <cknowles> peterdietz: thanks for adding links.
[20:57] <mhwood> I should perhaps not say so confidently, "that's easy!" until I've tested it.
[20:57] <peterdietz> Atleast my route I tested it with a stock handle implementation.. Its more work than no work. But if we made it documented very well. I'd say its easy
[20:57] <cknowles> There will be another UI meeting next week
[20:58] <peterdietz> Its very neat. You add a config with all of your dspace urls. i.e.
[20:58] <peterdietz> dspace.handle.endpoint1 = http://demo.dspace.org/xmlui/handleresolver
[20:58] <peterdietz> dspace.handle.endpoint2 = https://trydspace.longsight.com/handleresolver
[20:58] <peterdietz> dspace.handle.endpoint3 = http://dc.statelibrary.sc.gov/handleresolver
[20:59] <mhwood> It should be noted that this still doesn't allow one to have a *heterogeneous* Handle service of DSpace and other clients. It's all DSpaces with this plugin.
[20:59] <peterdietz> ...it then queries each of those resolver endpoints, finds out which handle prefixes it can handle. And then, when incoming handle resolution requests come in. It queries an endpoint to forward the user on
[20:59] <KevinVdV> Need to run, until next week.
[20:59] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) Quit (Quit: KevinVdV)
[20:59] <peterdietz> I think that REST should add an endpoint for such things
[21:00] <mhwood> "such things?"
[21:00] <peterdietz> /rest/handleresolver
[21:00] <mhwood> Which would do what?
[21:00] <peterdietz> /rest/handleresolver/listprefixes
[21:01] <peterdietz> respond with the same exact JSON that we make XMLUI / JSPUI respond with.. So that we don't have to rely on UI to do this weird thing ??
[21:01] <hpottinger> so... is this a "documentation improvement" for 6, a bug fix, or both?
[21:02] <mhwood> Well, it's also packaging.
[21:02] <peterdietz> You have code, but you'll stumble and trip trying to make it all compile. Such that nobody other than those in this room would be capable of accomplishing it
[21:03] <mhwood> But it's not difficult once you pull the code out into a separate project and configure the build process properly.
[21:03] <peterdietz> If you gave what currently exists to someone, they'd think you hate them.. Like instead of serving them cake, you gave then a shovel, and told them where to find the grain
[21:04] <peterdietz> (but we don't actually give them a shovel, but make an illusion to the concept of a shovel)
[21:04] <hpottinger> oh, there's this cool way to distribute already compiled packages in binary format
[21:04] <mhwood> The shovel is a lie, eh?
[21:05] <mhwood> I think it's called a JAR?
[21:05] <peterdietz> heh.. I guess so. My goal is to become the first software developer turn poet laureate
[21:05] <peterdietz> yeah. so either just have a ready-made zip or jar file, that people can grab. Or, have a process or tool to do such a thing
[21:06] <hpottinger> So... do we package up the jar and put it on Maven Central?
[21:06] <mhwood> Anyway there's a PR for the Maven approach, and a DSpace-Labs project for the Gradle approach. Take a look.
[21:06] <hpottinger> links for the log?
[21:06] <mhwood> This wouldn't be appropriate for Maven.
[21:06] <peterdietz> I've got a client on the other side of the globe that would like to use handle externally. So, easy instructions
[21:07] <peterdietz> pom route: https://github.com/DSpace/DSpace/pull/1044
[21:07] <kompewter> [ [DS-1837] Create a separate Maven artifact for the MultiRemoteDSpaceRepositoryHandlePlugin by mwoodiupui · Pull Request #1044 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1044
[21:07] <peterdietz> gradle application: https://github.com/DSpace-Labs/HandleExternalAdapterDSpace
[21:07] <kompewter> [ DSpace-Labs/HandleExternalAdapterDSpace · GitHub ] - https://github.com/DSpace-Labs/HandleExternalAdapterDSpace
[21:08] <mhwood> We need to examine the licenses for the dependencies and make certain that we have the rights to redistribute them in an uber-JAR.
[21:08] <peterdietz> HandleExternalAdapterDSpace is called what it is, so that I can nickname if DSpace Handle HEAD
[21:08] <peterdietz> licenses... rights... Makes me feel the urge to run
[21:08] <mhwood> But it's simple to build either way now.
[21:08] <peterdietz> yup.
[21:09] <mhwood> Distributing a JAR would be nicer, but not *way* nicer.
[21:09] <mhwood> If you have DSpace, you had to do some building anyway.
[21:09] <peterdietz> I'll keep poking along with my route. Since DSpace6 won't be released, or rather, adopted for 6 more months.
[21:09] <hpottinger> Gradle is probably OK for mashups
[21:10] <peterdietz> whachu'talkin'bout'Willis?
[21:12] <mhwood> Just noting that we are past the hour.
[21:12] <peterdietz> anyways. I think this meeting is fleeting / adjourning. Any further thoughts? Can also continue / float way over to #dspace
[21:13] <mhwood> Keep plugging away at the projects on the Services branch. JSP volunteers wanted to help out.
[21:13] <peterdietz> Tim should be back next week, to take my dictator role away
[21:14] <mhwood> Perhaps in a week we'll have merged the branch.
[21:15] <mhwood> I've got to leave. 'bye, all!
[21:15] <hpottinger> Yes, please, if you use JSPUI, you will want to be sure it works in 6, I think? Contact Andrea Bollini
[21:16] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:16] <peterdietz> :- Meeting Adjourned -:
[21:19] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:47] * kdweeks1 (~Adium@2001:468:c80:a103:e94c:959d:c1ec:c693) Quit (Quit: Leaving.)
[23:23] * cknowles (uid98028@gateway/web/irccloud.com/x-mrnehqynahdzguma) Quit (Quit: Connection closed for inactivity)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.