Timestamps are in GMT/BST.
[1:49] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[1:54] * eddies (~eddies@205.178.24.120) has joined #duraspace
[1:54] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[1:54] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[2:04] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[2:11] * eddies (~eddies@205.178.24.120) has joined #duraspace
[2:11] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[2:11] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[2:44] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[2:45] * eddies (~eddies@205.178.24.120) has joined #duraspace
[2:45] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[2:45] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[2:56] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[3:19] * eddies (~eddies@205.178.24.120) has joined #duraspace
[3:19] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[3:19] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[3:39] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[3:43] * eddies (~eddies@205.178.24.120) has joined #duraspace
[3:43] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[3:43] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[3:53] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[4:28] * eddies (~eddies@205.178.24.120) has joined #duraspace
[4:28] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[4:28] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:23] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[6:42] -moorcock.freenode.net- *** Looking up your hostname...
[6:42] -moorcock.freenode.net- *** Checking Ident
[6:42] -moorcock.freenode.net- *** Found your hostname
[6:42] -moorcock.freenode.net- *** No Ident response
[6:43] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:43] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:43] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:53] * eddies (~eddies@205.178.24.120) has joined #duraspace
[6:53] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[6:53] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[7:02] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 245 seconds)
[7:58] * eddies (~eddies@205.178.24.120) has joined #duraspace
[7:58] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[7:58] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[8:06] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 252 seconds)
[9:03] * eddies (~eddies@205.178.24.120) has joined #duraspace
[9:03] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[9:03] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[9:08] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 256 seconds)
[9:23] * bigbrovar (~quassel@83.229.6.19) has joined #duraspace
[9:36] * bigbrovar_ (~quassel@41.206.11.8.vgccl.net) has joined #duraspace
[9:37] * bigbrovar (~quassel@83.229.6.19) Quit (Ping timeout: 272 seconds)
[9:40] * bigbrovar (~quassel@83.229.6.19) has joined #duraspace
[9:40] * bigbrovar_ (~quassel@41.206.11.8.vgccl.net) Quit (Ping timeout: 255 seconds)
[10:04] * eddies (~eddies@205.178.24.120) has joined #duraspace
[10:04] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[10:04] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[10:08] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 252 seconds)
[11:04] * eddies (~eddies@205.178.24.120) has joined #duraspace
[11:04] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[11:04] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[11:09] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 252 seconds)
[12:04] * eddies (~eddies@205.178.24.120) has joined #duraspace
[12:04] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[12:04] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:09] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 255 seconds)
[13:05] * eddies (~eddies@205.178.24.120) has joined #duraspace
[13:05] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[13:05] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[13:10] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 276 seconds)
[13:25] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:05] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[14:52] * eddies (~eddies@205.178.24.120) has joined #duraspace
[14:52] * eddies (~eddies@205.178.24.120) Quit (Changing host)
[14:52] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[14:54] * eddies (~eddies@unaffiliated/eddies) Quit (Client Quit)
[15:23] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:31] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[15:32] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Client Quit)
[15:33] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[15:41] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[16:23] * bigbrovar (~quassel@83.229.6.19) Quit (Quit: No Ping reply in 180 seconds.)
[16:27] * bigbrovar (~quassel@83.229.6.19) has joined #duraspace
[16:32] * bigbrovar (~quassel@83.229.6.19) Quit (Quit: No Ping reply in 180 seconds.)
[16:33] * bigbrovar (~quassel@83.229.6.19) has joined #duraspace
[16:44] * bigbrovar (~quassel@83.229.6.19) Quit (Ping timeout: 272 seconds)
[16:55] * bigbrovar (~quassel@83.229.6.19) has joined #duraspace
[16:59] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[17:09] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[19:23] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:56] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) has joined #duraspace
[20:02] <tdonohue> Hi All, it's now time for our weekly DSpace Devel Mtg
[20:02] <tdonohue> Today's agenda is here (it's been freshly updated with a few last minute things as of a moment ago): https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-02-13
[20:02] <kompewter> [ DevMtg 2013-02-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-02-13
[20:03] <tdonohue> starting things off with a few announcements / reminders
[20:03] <tdonohue> 1) I'll be on vacation next week. So, I won't be at the meeting next Weds (Feb 20). You all are encouraged to meet, but you can decide what you want to talk about
[20:04] <tdonohue> 2) The following week (two weeks from today), we'll be having some followup mtgs to those "DSpace Futures" discussions we had in the Fall. The first followup meeting will concentrate on getting a REST API in place. It will be on Weds, Feb 27 @ 19:00 UTC. Because of that mtg, we will NOT have a Dev mtg that day
[20:05] <tdonohue> 3) I also wanted to remind everyone that Open Repositories deadlines are coming soon (Fri, Feb 22). So, try and get in your talk proposals soon
[20:05] <tdonohue> any questions on any of those (some additional info in the agenda itself)?
[20:07] <tdonohue> regarding #2 - the REST API mtg. There will be an email going to all lists either today or tomorrow announcing the DSpace Futures followup mtgs
[20:07] <helix84> well, as I've already said I'd wait with actually picking a REST API until after we at least hear from the developers of both
[20:08] <tdonohue> The REST API mtg (on Feb 27) is more a discussion around how we can get things moving forward....it won't necessarily *decide* the REST API. It's more a discussion to get volunteers & even a "team" (if needed) in place to try and make things move more quickly
[20:08] <helix84> no, I'm talking about today's agenda point: REST Implementations - Choose one as our "base" and schedule for release.
[20:08] <tdonohue> So, I wouldn't advertise it as the "day we decide".
[20:09] <tdonohue> oh, that's coming later..helix84...you've jumped ahead.
[20:09] <helix84> sorry, you asked about comments on agenda :)
[20:09] <tdonohue> oh, no...I meant comments on those *announcements* :)
[20:10] <tdonohue> I also don't anticipate we are going to decide anything REST API related today -- but it still needs to be a "hot discussion" topic that we need to keep poking at
[20:10] <tdonohue> because we really need to decide on it soon, if we want to get it ready for 4.0
[20:11] <helix84> yes, it would surely be great if as many commiters as possible at least tried both
[20:12] <mhwood> So, on to the agenda?
[20:12] <tdonohue> yep..we'll head back to agenda. Set aside REST for a moment
[20:13] <tdonohue> Next up, as you all heard Google Summer of Code 2013
[20:13] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:13] <tdonohue> I really just wanted to get this on everyone's radar. Assuming we have enough interested possible mentors, DuraSpace plans to put in an application this year.
[20:14] <tdonohue> I'm not sure who all is familiar with Google Summer of Code...I think most of us are, but please feel free to ask questions if you are not
[20:15] <tdonohue> In general the next steps are... (1) Start to brainstorm some interesting student projects (that can be done in a summer), (2) Start to determine if we have interested mentors amongst the committers group, (3) put in an application and hope we get accepted
[20:15] <helix84> I'd take a stab at mentoring. I already cast some preliminary net out at students (I know we're not acceptet yet). Last yewar I've been a mentor at GCI and it was great, better than I expected.
[20:16] <tdonohue> sounds great, helix84.
[20:16] <tdonohue> Yea, and to be clear...anyone who says they are "interested in mentoring" can always back out later, if the students & projects just don't match up well for you. In general though, we want to try and find some possible mentors for any project ideas we come up with
[20:17] <aschweer> in case anyone else is wondering, the timeline is here: http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline
[20:17] <kompewter> [ Google Summer of Code 2013 Frequently Asked Questions ] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline
[20:18] <tdonohue> So, in the past, we've put our project brainstorms up on the wiki...in a separate "GSOC" space. https://wiki.duraspace.org/pages/viewpage.action?pageId=18546886 We'll do the same this year...we just need to get that wiki area updated as needed for GSoC 2013 and remove any old project ideas that we are no longer really interested in
[20:18] <kompewter> [ Google Summer of Code (GSOC) - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=18546886
[20:19] <tdonohue> So, here's our "Ideas" page from 2012. We should review ideas here, and remove any we thing are no longer interesting & add new ideas. https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:19] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:20] <helix84> i was just wondering why we didn't do a separate page titled 2012 like the years before, to keep track of the old ideas
[20:20] <hpottinger> looking at the list of projects accepted last lear, it looks like Google really tried to focus on projects that would be of interest to younger students
[20:20] <hpottinger> s/lear/year/
[20:20] <kompewter> hpottinger meant to say: looking at the list of projects accepted last year, it looks like Google really tried to focus on projects that would be of interest to younger students
[20:21] <tdonohue> helix84 -- I plan to "archive" our old GSoC 2012 ideas off to a "DSpace Summer of Code Ideas 2012" page.
[20:23] <tdonohue> hpottinger -- could be. The only feedback we got from Google (we did ask them for feedback) was that "our application was good" and that they unfortunately had to make tough decisions, and decided to let in some new organizations that had never been a part of GSoC
[20:23] <tdonohue> that was feedback from last year's application (where we were rejected) obviously
[20:25] <tdonohue> So, any other questions around GSoC stuff? Any "early ideas" that folks want to throw out there for possible projects?
[20:25] <tdonohue> (I'll work on getting our ideas page cleaned up after this meeting, so we can start adding 2013 ideas there)
[20:27] <hpottinger> I've already blurted this out on the devel list, but I'm not averse to repeating myself: I think incorporating the Maven::Jetty plugin would make a nice small project, and could dovetail nicely with any REST-API work.
[20:27] <helix84> +1
[20:27] <tdonohue> hpottinger : yea, I didn't respond yet on -devel, but I'd say +1 too. Sounds interesting
[20:28] <helix84> (although I think the project might be on the smallish side for GSoC)
[20:29] <hpottinger> I'd even sign up to mentor for that project, though I will confess when I "just tried it out" I did not end up in a good place. :-)
[20:29] <tdonohue> could be. though we could think of ways to "expand it" if the student got done earlier than expected
[20:29] <helix84> anything else we need improved in ant/maven?
[20:30] <helix84> (intentionally provocative question)
[20:30] * tdonohue is always a fan of "smaller" more contained projects (they tend to end better, with something potentially even *usable*), than larger "pie-in-the-sky" projects (which sometimes end with the code in an unstable or incomplete state)
[20:31] <mhwood> Large projects often contain smaller projects....
[20:31] <helix84> tdonohue: I agree with setting a few milestones, some of them optional
[20:31] <tdonohue> re: maven + ant..there's also the option of using the maven-ant-plugin :) I.e. "mvn deploy" = current "ant update"
[20:31] <tdonohue> so, that could be a possible "extension" to Maven::Jetty
[20:32] <hpottinger> honestly, I started down the road of looking at Maven::Jetty because I was looking at the Jorum build stuff to see how it worked...
[20:33] <helix84> there has been a person or two who needed to use only maven, not ant for their production deployment, so that might help, I'm not sure
[20:33] <helix84> I think the point was their deployment system could run maven commands for them, not ant
[20:33] <tdonohue> Oh, I meant the"maven-antrun-plugin"...http://maven.apache.org/plugins/maven-antrun-plugin/ It let's you kick off Ant commands via Maven. I.e., it'd be a way of doing away with "ant" as a required prerequisite...you'd only need Maven
[20:33] <kompewter> [ Introduction ] - http://maven.apache.org/plugins/maven-antrun-plugin/
[20:34] <hpottinger> all of these are steps towards a better "out of the box" experience
[20:34] <tdonohue> yep, exactly
[20:34] <mhwood> Ugh, I have often thought that it ought to go the other direction: if you don't customize the code, you shouldn't need Maven at all. Ant could use Ivy to pick the artifacts up and stuff them in place.
[20:35] <tdonohue> mhwood -- yea, there's two directions there....the problem tends to be (at least in my mind) that we are too "tied into Maven" currently, as it is our "installer"
[20:35] <hpottinger> it's our "installer builder"
[20:36] <mhwood> And Maven isn't designed to be an installer, and it's emphatic about how it thinks things ought to be done.
[20:36] <helix84> I thought it's there mainly to resolve dependencies
[20:36] <tdonohue> it is there mainly for dependencies...and for "custom code overlays"
[20:36] <helix84> I might backtrack the guys and ask them about their environment and what they would need
[20:37] <tdonohue> I'm just pointing out that we'd need a new way to "install DSpace" (and overlay custom code/dependencies) if we did away with Maven.
[20:37] * misilot (~mdevilz@p-body.lib.fit.edu) has joined #duraspace
[20:38] <tdonohue> to be clear though...I'd be 100% happy if we found a way to not require Maven for installation (I agree it's mostly a developers tool)...it's just a project in itself
[20:39] <tdonohue> i.e. we might be talking about two separate projects now.... (1) Make the DSpace + Maven build experience easier (Jetty plugin, Antrun plugin). (2) Investigate an "easy installer" option that doesn't require Maven
[20:39] <hpottinger> I have to admit I'm kind of fond of Maven, it makes some things so much easier, and when I come across other projects that don't use it, and see what they have to do for dependencies…. yuck.
[20:40] <tdonohue> I'm fond of Maven too. I don't want to do away with Maven.... I just want to admit that it's not the best tool for Installation.
[20:40] <mhwood> }rant{ The product of Maven should be artifacts in some repository. That collection of artifacts is *not installed anywhere* yet and shouldn't appear to be. The installation phase should grab artifacts, whether from Central, your MRM, or your local cache, perhaps filter some configuration stuff, and place them.
[20:41] <tdonohue> I.e. in some future...it'd be nice if Maven was just for "advanced installation". If you want, you can build from source (using Maven) and install from there. But if you just want the default DSpace, here's a pre-compiled installer that will set it up in no time.
[20:43] <aschweer> sorry, gotta run (I do agree with mhwood's rant though)
[20:43] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:43] <helix84> i think joao wanted to do something like that (installer)
[20:43] <helix84> I'll ask him and maybe it can be done in GSoC
[20:45] <hpottinger> I mentioned a few lines back the Jorum build framework, and figured I'd best link it and happen to have the link handy, so here it is http://developer.edina.ac.uk/projects/jorumdspace/wiki/Build_Framework
[20:45] <kompewter> [ Build Framework - Jorum DSpace - EDINA Developer Corner ] - http://developer.edina.ac.uk/projects/jorumdspace/wiki/Build_Framework
[20:46] <tdonohue> yea, I stumbled across that Jorum framework at some point...it looks interesting, just never got a chance to get back to it
[20:46] <hpottinger> that was submitted as DS-921 as well
[20:46] <kompewter> [ https://jira.duraspace.org/browse/DS-921 ] - [#DS-921] Build script supporting multi-developer config, automatic container launching and code coverage - DuraSpace JIRA
[20:47] <hpottinger> we've gotten past the multi-developer config with the -Denv=something.properties flag you added, tdonohue
[20:47] <tdonohue> huh...so for Jorum they do install/deploy from Ant (to Jetty)...not from Maven
[20:48] <hpottinger> I'm not sure if this is current practice
[20:49] <tdonohue> in any case...I think we've gotten some decent ideas here for GSoC.. It seems like discussion is slowing on this topic
[20:49] <hpottinger> but it does seem we could do most of what they are doing using Maven instead
[20:49] <tdonohue> next steps for GSoC - I'll clean up the wiki space, and send an email to dspace-devel once we are ready to add in project ideas.
[20:50] <mhwood> hpottinger: dunno, I think we should be moving stuff *out* of Maven, not in.
[20:50] <tdonohue> hpottinger - yea, I think most / all of that could happen via Maven, as we talked about above (using Jetty plugin & Antrun plugin)
[20:50] <tdonohue> mhwood -- what would you move out of Maven? just curious
[20:50] <helix84> I'm also wondering whether the Jorum practice was influence by the change to Git
[20:51] <hpottinger> mhwood: code stuff should stay in Maven, I think, deploy stuff definitely doesn't have to be in Maven, and I think there's a good argument to be made for a custom installer.
[20:51] <mhwood> Customizing for installation, for one thing. Maven shouldn't know anything about installation-time, because it isn't designed to support installation
[20:53] <helix84> I'm also not quite clear on the direction we want to move here - once we want to get rid of ant, then we don't want to use maven for installation
[20:53] <mhwood> To support that, DSpace needs to be able to be told from outside where to look for stuff that's not in the WAR, in a way that's simple for a build environment (Maven, an IDE) to provide. DSpace also should be less dependent on configuration in some areas -- you should be able to at least start it and get sensible advice even in the complete absence of a [DSpace]/config directory.
[20:55] * hpottinger googles for something like capistrano for java… oops, betraying some Ruby research...
[20:56] <mhwood> Do we want to get rid of Ant? Why?
[20:57] <helix84> no idea why, just something I picked up
[20:57] <helix84> another generally relevant idea: http://dspace.2283337.n4.nabble.com/Interested-in-a-simplified-build-td4659831.html
[20:57] <kompewter> [ DSpace - Tech - Interested in a simplified build? ] - http://dspace.2283337.n4.nabble.com/Interested-in-a-simplified-build-td4659831.html
[20:57] <tdonohue> mhwood : I'd argue that Ant and Maven are both developer tools (and rather dense to folks these days). I agree with most of what you've said, but in my mind, we currently have two tools that are neither "installer friendly" in Maven & Ant.
[20:58] <mhwood> Well, the most installer-friendly tool would be "unzip".
[20:58] <tdonohue> So, to bring that further...I'd propose we try and make *neither* of them our main "installer"
[20:58] <tdonohue> However, I still think we NEED Maven for it's dependency management...but, it should be our *compiler* / builder
[20:58] <mhwood> Yes, I don't see us giving up Maven at this point without a lot of pain and delay.
[20:59] <tdonohue> So...in my mind, "Ant" is the thing that doesn't fit into the picture...so, that's why I keep wondering why we need Ant
[20:59] <mhwood> But it should be used for what it's made for.
[20:59] <helix84> mhwood: there you go :)
[20:59] <hpottinger> unzip works for fedora, though they do have a custom installer, too
[20:59] <helix84> tdonohue: so how doesn't and fit in?
[20:59] <mhwood> The code has to be *designed* to be unzipped and run, though.
[20:59] <helix84> s/and/ant/
[20:59] <kompewter> helix84 meant to say: tdonohue: so how doesn't ant fit in?
[21:00] <tdonohue> Fedora uses OneJAR for it's installer: http://one-jar.sourceforge.net/
[21:00] <kompewter> [ Deliver Your Java Application in One-JAR™ ! ] - http://one-jar.sourceforge.net/
[21:00] <mhwood> If we need complex cross-platform scripting, Ant is not an unreasonable choice. There may be others that are better.
[21:00] <hpottinger> woah, look what I found: https://code.google.com/p/bungeni-dspace/wiki/InstallingDspaceUsingCapistrano
[21:00] <kompewter> [ InstallingDspaceUsingCapistrano - bungeni-dspace - How to install DSpace using capistrano - Bungeni customizations for DSpace - Google Project Hosting ] - https://code.google.com/p/bungeni-dspace/wiki/InstallingDspaceUsingCapistrano
[21:01] <mhwood> It may be a matter of having let the tools we know dictate the process, instead of the other way 'round.
[21:02] <tdonohue> helix84 : The logic in my mind is going like this. (1) Maven and Ant are not really installers (2) we really need something that's easier than Ant/Maven for Installation, (3) We need Maven for its dependency management, (4) What do we need Ant for? I'm not sure...it's just an installer right now, but it's not really a good "installer" (see #1 and #2)
[21:02] <mhwood> Ant is a lot like "make", in some ways, so it's natural to think of it when dealing with installation issues ("make install" is so simple).
[21:03] <tdonohue> hpottinger: cool!
[21:03] <KevinVdV> Needs to run, until next week
[21:03] <mhwood> The build.xml is the installer; Ant is just infrastructure. That's why Maven won't work for installation: it isn't scriptable (except by calling out to Ant :-)
[21:03] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) Quit (Quit: KevinVdV)
[21:03] <hpottinger> Looks like a few people are using Capistrano, but also mentioning ControlTier (http://doc36.controltier.org/wiki/Main_Page) which is Java-based
[21:04] <mhwood> Ant is procedural; Maven is declarative.
[21:04] <tdonohue> mhwood - yea, I get everything you are saying & I agree. I don't think *either* Maven or Ant should be the "installer".
[21:04] <helix84> so we still need/want to keep both?
[21:06] <helix84> then about onejar - I don't understand how it would work with DSpace, which is by its nature composed of multiple webapps, some of them optional. how does one jar fit in?
[21:06] <tdonohue> In my mind...the "future" DSpace "binary" (pre-compiled) install would not require users to download Maven or Ant (it'd be something else). But, if you wanted to build Dspace from Source, you'd still need Maven.
[21:06] <mhwood> We should ponder what all we do in build.xml right now. We fetch location data, fill and clean out databases, copy groups of JARs, create directory hierarchies, filter configuration data.
[21:07] <helix84> we also create backups, sorta
[21:07] <mhwood> Perhaps we need to break that stuff up into developer tools, installer tools, etc.
[21:08] <mhwood> Some of those tools might wind up in several kits.
[21:08] <tdonohue> helix84: you can think of OneJAR as a JAR that "auto-unzips" itself and can be scripted (via embedded Ant) to copy things around, etc. I played around with it for DSpace... never got it working fully though. But, it likely *could* work for DSpace. If you wanted to used OneJAR for Dspace, then essentially Maven would *build* the OneJAR. Then the OneJAR would be the installer.
[21:09] <tdonohue> (My work with OneJAR is all documented here: https://wiki.duraspace.org/display/DSPACE/Installer+Prototype)
[21:09] <mhwood> So the idea isn't to eliminate the *use* of Ant, but the site's *installation* of Ant?
[21:09] <tdonohue> mhwood ++
[21:10] <tdonohue> YES
[21:10] <tdonohue> I don't care what is being used *underneath* :) It's a matter of limiting the number of things you have to install before you can install DSpace
[21:11] <helix84> i see. i always thought the "output" we want to get to make deployment easy is several .war files. I see your point about a single executable (jar in this case), which would be like desktop application installer. but then we have those users I mentioned who can't just run any command on their production machines and need to deploy via maven - we'd still support that as an option, I gather
[21:11] <mhwood> Most good installation kits include an "unpack" operation.
[21:11] <tdonohue> helix84: yea, in my mind, you could still compile from source using Maven...that'd be an "advanced installation" option
[21:12] <mhwood> Again, the product has to be designed so that you *can* reasonably unpack and set it up yourself.
[21:12] <tdonohue> yep
[21:12] <helix84> it would be great if we could sum up some conclusions from today's discussion for future reference
[21:14] <tdonohue> yea...I'm just wondering what the conclusions are. :) it's a lot of brainstorms...and some of this is actually describing what was in my head when I did my "Installer prototype" work (linked above), which is now something I no longer have time to work on
[21:14] <tdonohue> but, I think we could start to describe this as an "Installer" project for GSoC...
[21:15] <mhwood> 1. People who don't need to customize code shouldn't need Maven.
[21:15] <helix84> so is there some subset of work to be done we can all agree on?
[21:15] <tdonohue> and I still think that hpottinger's Maven ideas for GSoC are also valid (but they may be more for Developers)
[21:15] <mhwood> 2. People who don't need to customize code shouldn't need Ant.
[21:15] <mhwood> 3. We may want to use Ant anyway, but it should be embedded in the packaging.
[21:16] <tdonohue> mhwood ++
[21:16] <mhwood> 4. It should be possible to unpack a stock DSpace with small, simple tools that everyone has, and get something that can be made to run with reasonable effort.
[21:17] <mhwood> 5. It should be a lot simpler to do automated installation.
[21:17] <helix84> sounds all good
[21:17] <mhwood> 6. We may need to break out some tools for optional tasks, like cleaning out the database.
[21:17] <mhwood> 7. We're still committed to Maven for build-time.
[21:17] <hpottinger> Maven::jetty would potentially help anyone needing to debug an issue, but who may not have an IDE set up. We could ask people reporting something "strange" on the mail list to try running maven::jetty and a remote debugger
[21:18] <mhwood> 8. We may have to adjust some boundary lines between Maven, Ant, etc.
[21:18] <tdonohue> hpottinger -- yea, I still think that Maven::Jetty idea is valid, if only for debugging & developers. It may not really be "recommended" for production installs, but it'd be nice for development
[21:19] <mhwood> 9. An embedded container that Just Runs would aid development and troubleshooting.
[21:19] <hpottinger> optional DB tool could also be repurposed as a reporting tool.
[21:19] <mhwood> Did I capture everything essential?
[21:20] <tdonohue> mhwood ++ - I think so...and I agree with all of it. Just not entirely sure where to "document" this...it's starting to sound like a "manifesto" :)
[21:20] <mhwood> One thing I keep thinking is that DSpace should just create any missing DB tables when it finds them. There shouldn't be a schema-load installation step.
[21:20] <hpottinger> +1 manifestos
[21:21] <mhwood> Or rather, when it doesn't find them. :-)
[21:21] <tdonohue> or, maybe we should just create an "InstallationManifesto" or "InstallerBrainstorms" page on the wiki under our "Proposals" and capture this there as well
[21:21] <hpottinger> mhwood: Fedora does that, it really threw me for a loop before I figured that out…. wait, how does the DB get set up?
[21:21] <tdonohue> +1 to auto-db creation
[21:22] <mhwood> "installer brainstorms" page: yes.
[21:22] <tdonohue> ok, will copy mhwood's ideas above (and link back to IRC logs) into an Installer Brainstorms page
[21:23] <mhwood> Well, I collected up ideas from several people.
[21:24] <tdonohue> yep yep. Just saying that your bullets listed above were well stated summaries
[21:24] <mhwood> Thank you, that's what they were meant to be.
[21:25] <tdonohue> Ok, in any case, we're well over time here...I gotta head into "lurking" mode to get some stuff done. So, we won't get to REST API stuff today (others are welcome to chat about it here now though)
[21:26] <tdonohue> again, a reminder that I'll be out next week (Feb 20)... And in two weeks (Feb 27) we'll be having a phone call about REST API at 19:00 UTC (email will go out soon)
[21:28] <tdonohue> I also should warn that my travel schedule is picking up now....so, I'm also going to be out Weds, March 6 (at DuraSpace all-staff mtg) and Weds, March 7 (at DuraSpace Sponsor Summit). So, I'm not going to be around for many of the next few weekly meetings (yikes)
[21:28] <mhwood> hpottinger: humph, if Fedora is going to build its own schema at runtime, it should say that it is doing that. It's kind of important.
[21:28] <tdonohue> that second date is Weds, March *13* (not 7)
[21:28] <mhwood> tdonohue, one of those can't be a Wednesday.
[21:28] <tdonohue> i.e...I'm out for 3 of the next 4 weeks...I'll only be around for the special mtg on Feb 27
[21:29] <mhwood> We'll need volunteer moderators. I could perhaps take one week.
[21:29] <tdonohue> (yea..it's a lot of travel at once..things slow down after that though)
[21:29] <tdonohue> yea..you are correct. I can also email -commit about this (meant to anyway)
[21:30] <mhwood> Please.
[21:30] <tdonohue> it would be best to get some volunteer moderators lined up soon...will email you all in a bit
[21:30] <mhwood> Thanks!
[21:30] <hpottinger> mhwood: I agree about documenting DB setup issues, it *is* sorta important.
[21:31] <hpottinger> tdonohue: when is the latest you need to hear from me re: OR13?
[21:31] <hpottinger> or should I plan on submitting the proposal on my own?
[21:34] <tdonohue> hpottinger -- if you can do the OR13 talk, then you should just plan to submit the proposal yourself. I'm gonna be offline from Feb 20 (next Weds) through Feb 25...and proposals are due Feb 22.
[21:34] <hpottinger> will do
[21:35] <tdonohue> if it's looking like you won't be able to do it, try to let me know by Fri / Mon. I could then sneak in a last minute proposal with a "TBD" speaker for the topic
[21:35] <hpottinger> If it turns out I can't go, I will send a note to -release to see if anyone else wants to take it
[21:36] <tdonohue> sounds good (I should also mention that there are "rumors" that the OR proposal deadline will be pushed back a week...but, we probably shouldn't depend on it)
[21:36] <hpottinger> if anyone here has done a similar talk and has a copy of their proposal, the theme of OR13 is "re-use" :-)
[21:36] <tdonohue> robint did a similar talk for 1.8...you might want to ping him
[21:37] <hpottinger> robint, I know you're reading this log, consider yourself pinged. :-) I'll send you a note offline, too, just in case.
[21:43] <hpottinger> idly reading through the docs for ControlTier, looks like there's quite a bit built up around WebDAV… idle silly thought: deployment by way of self-archiving code and pushing out through dspace-lni… that would be weird...
[21:46] <mhwood> Wow, a DSpace virus.
[21:49] <hpottinger> mhwood: this is a logged channel. :-)
[21:50] <mhwood> It's nonviable in the wild: keeps crashing until you spend an hour configuring it. :-)
[21:51] <hpottinger> Excellent!
[22:04] <hpottinger> You know, those are the best kinds of toys: takes forever to get going, and once you do, it eats your brain.
[22:18] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:18] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:38] * eddies (eddies@conference/code4lib/x-lzgtzhnnwpwpzfbu) has joined #duraspace
[22:38] * eddies (eddies@conference/code4lib/x-lzgtzhnnwpwpzfbu) Quit (Changing host)
[22:38] * eddies (eddies@unaffiliated/eddies) has joined #duraspace
[22:38] * eddies (eddies@unaffiliated/eddies) Quit (Changing host)
[22:38] * eddies (eddies@conference/code4lib/x-lzgtzhnnwpwpzfbu) has joined #duraspace
[22:52] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:14] * eddies (eddies@conference/code4lib/x-lzgtzhnnwpwpzfbu) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.