Timestamps are in GMT/BST.
[4:44] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[4:50] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[4:50] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[4:50] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[5:53] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[6:41] -lindbohm.freenode.net- *** Looking up your hostname...
[6:41] -lindbohm.freenode.net- *** Checking Ident
[6:41] -lindbohm.freenode.net- *** Found your hostname
[6:41] -lindbohm.freenode.net- *** No Ident response
[6:41] [frigg VERSION]
[6:41] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:41] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:41] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:59] * eddies (~eddies@bb219-74-150-51.singnet.com.sg) has joined #duraspace
[6:59] * eddies (~eddies@bb219-74-150-51.singnet.com.sg) Quit (Changing host)
[6:59] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[10:11] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[10:58] * Asger (~abr@nat.statsbiblioteket.dk) has joined #duraspace
[11:17] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[11:17] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[11:17] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:23] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:17] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:21] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) Quit (Quit: Please, sir, I want some more.)
[15:29] * ruebot (~ruebot@LB-SC-S1B4DB.library.yorku.ca) has joined #duraspace
[15:29] * ruebot (~ruebot@LB-SC-S1B4DB.library.yorku.ca) Quit (Changing host)
[15:29] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[18:06] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[18:32] * Asger (~abr@nat.statsbiblioteket.dk) Quit (Ping timeout: 256 seconds)
[18:47] * lyncode (~lyncode@188.250.39.156) has joined #duraspace
[19:47] * kstamatis (5b8c1fd8@gateway/web/freenode/ip.91.140.31.216) has joined #duraspace
[19:51] <tdonohue> Hi All, reminder that the DSpace Developer Mtg started in ~10mins : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-09-26
[19:51] <kompewter> [ DevMtg 2012-09-26 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-09-26
[19:53] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:00] <tdonohue> Hi all, it's time for the DSpace Developers Mtg. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-09-26
[20:00] <kompewter> [ DevMtg 2012-09-26 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-09-26
[20:01] <tdonohue> Before we kick into 3.0 status items, etc., I wanted to mention again briefly that the Wiki upgrade is happening on Fri: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg09967.html If there are any questions/concerns anyone has right now, we can spend a few minutes on it if needed
[20:01] <kompewter> [ [Dspace-devel] NOTICE: DuraSpace Wiki Upgrade/Downtime on Fri @ 2-3pm ED ] - http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg09967.html
[20:02] <robint> No concerns here
[20:03] <tdonohue> essentially though, it's a major upgrade. There will be lots of cool new features coming. The only feature we are "losing" is the ability to edit via "Wiki Markup". So, initially it may be slightly "jarring" to those used to Wiki Markup, but to be honest, the new "Rich Text" Editor is pretty nice (I've been playing with it a lot this week)
[20:03] <mhwood> Does this mean hundreds of articles will once again be mangled by the conversion, as seems to happen every time there's a format change? (Not complaining at anyone here; it's the wiki software makers I'm looking at.)
[20:04] <tdonohue> mhwood : I've performed a test upgrade this week and it went relatively smoothly. I did not notice articles getting mangled (I cannot promise there won't be a few, but really, through all my tests, I was pleasantly surprised)
[20:04] <mhwood> Good to hear -- thanks!
[20:04] <tdonohue> So, I'm hoping that things will go smoothly on Fri as well
[20:05] <hpottinger> that's great news, my worst experience with a WYSIWYG editor was with Confluence...
[20:05] <hpottinger> exciting exploding wiki page :-)
[20:05] * mdiggory (~mdiggory@rrcs-74-87-47-118.west.biz.rr.com) has joined #duraspace
[20:05] <mhwood> Yeah, I think I'd rather write XHTML by hand than use any of the language-sensitive editors I've tried on it so far.
[20:06] <tdonohue> Yea, the new editor is quite a bit better. It still may take some getting used to, and as I mentioned, if you get really frustrated, you can still edit the source code (it's just that the source is now in XHTML rather than Wiki Markup)
[20:06] <tdonohue> Ok, we'll leave it at that for now. If anyone has any other concerns or runs into something odd after the upgrade, let me know or email sysadmin@duraspace.org
[20:07] <mdiggory> a Rich text editor that supported XHTML would be a nice addition to DSpace as well...
[20:07] <tdonohue> You can get right on that then, mdiggory! :) (agreed though)
[20:07] <robint> ePrints has such a thing
[20:07] <mdiggory> I'm sure that Atlassian laid down some pretty strict licensing
[20:08] <PeterDietz> OSU has upgraded to the newer confluence. And we did miss the wiki markup editor mode.. But only the super power users still miss it.. The gui mode is pretty full featured
[20:08] <tdonohue> Good to hear, PeterDietz.
[20:09] <tdonohue> Ok, shall we move on to 3.0 Status topics now? I noticed Sands & Release Team got out the new release schedule earlier today....so, I guess we just need to talk through outstanding To-Do's
[20:10] <robint> I think all the outstanding major features have been committed since last week
[20:10] <tdonohue> How are we looking on our Pull Requests? (Admittedly, I've been concentrated this week on this wiki upgrade, so I'm not fully caught up today)
[20:11] <tdonohue> good to hear, robint. So, do we have any pulls outstanding besides Maven Consolidation work?
[20:11] <robint> Just bug fixes, I think
[20:11] <mdiggory> The pull requests I said we would get done last week are all in now. What remains on my plate is the MAven Consolidation
[20:11] <hpottinger> https://wiki.duraspace.org/display/DSPACE/DSpace+3.0+Tasks
[20:11] <kompewter> [ DSpace 3.0 Tasks - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+3.0+Tasks
[20:12] <mdiggory> but just to get a feel for it, we were considering submitting the changes that would enable Discovery by default
[20:12] <robint> I think we want to leave the coast clear for Mark to do the Maven work before committing bug fixes
[20:12] <tdonohue> +1 robint. I'd be in favor of holding off on bug fixes till the Maven Consolidation work is done/committed
[20:12] <robint> mdiggory : whats your plan for the Maven work ?
[20:13] <mdiggory> isn't there anyway to automate that listing?
[20:13] <mdiggory> rm -Rf dspace*; git commit; git push;
[20:14] * mdiggory sorry
[20:14] <hpottinger> mdiggory: I think helix was working on an automation script for the task list
[20:14] <robint> :)
[20:14] <mhwood> Very compact!
[20:14] <tdonohue> wow..I'm sure folks will love that new addition with 3.0 :) DSpace 3.0 -- now with 100% less code!
[20:14] <mdiggory> feeling a bit punchy dur to lack of sleep
[20:14] <hpottinger> very agile
[20:15] <mdiggory> Why use DSpace, because you don't have to ;-)
[20:15] <tdonohue> seriously though... how is the Maven work going? Need help/support from any of us, mdiggory? Any rough timeline?
[20:15] <mdiggory> ok... ok...
[20:16] * hpottinger is pretty sure mdiggory's "patch" could be automatically applied
[20:16] <mdiggory> I think I'm mostly at the point where I just need to rerun the consolidation tasks and then push to a branch and create a pull request.
[20:16] <mdiggory> Maybe its good to discuss what would happen so everyone knows.
[20:18] <mdiggory> This is the older branch from the original pull request
[20:18] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation
[20:18] <kompewter> [ mdiggory/DSpace at maven-project-consolidation · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation
[20:19] <mdiggory> PRojects such as XMLUI are consolidated into one maven project rather than 3-4 separate projects
[20:19] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-xmlui
[20:19] <kompewter> [ DSpace/dspace-xmlui at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-xmlui
[20:20] <tdonohue> Right, essentially *all* Maven subprojects end up going away...so, there's just the top-level Maven projects (dspace-api, dspace-xmlui, dspace-jspui, etc)
[20:20] <mdiggory> Each top level dspace-xxxx project is now a war project.
[20:20] <mdiggory> https://github.com/mdiggory/DSpace/blob/maven-project-consolidation/dspace-xmlui/pom.xml#L25
[20:20] <kompewter> [ DSpace/dspace-xmlui/pom.xml at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/blob/maven-project-consolidation/dspace-xmlui/pom.xml#L25
[20:21] <mdiggory> the project generates and attaches a "skinny war", a "jar" of classes, a jar of "tests" for reuse downstream in the overlay projects
[20:22] <PeterDietz> hmm.. I know you need to re-do this.. But I think I've found a bug.. https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-xmlui/src/main/java/org/dspace/sword/client
[20:22] <kompewter> [ DSpace/dspace-xmlui/src/main/java/org/dspace/sword/client at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-xmlui/src/main/java/org/dspace/sword/client
[20:22] <mdiggory> thus dependencies change from dspace-xxxx-api to dspace-xxxx-[version]-[classes]
[20:22] <mdiggory> https://github.com/mdiggory/DSpace/blob/maven-project-consolidation/dspace/modules/xmlui/pom.xml#L139
[20:22] <kompewter> [ DSpace/dspace/modules/xmlui/pom.xml at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/blob/maven-project-consolidation/dspace/modules/xmlui/pom.xml#L139
[20:22] <PeterDietz> i don't think xmlui should contain the sword client...
[20:23] <tdonohue> actually, PeterDietz, it should. The SWORD Client is a part of the XMLUI: https://wiki.duraspace.org/display/DSDOC18/SWORDv1+Client
[20:23] <kompewter> [ SWORDv1 Client - DSpace 1.8 Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC18/SWORDv1+Client
[20:23] <mdiggory> PeterDietz: some final decisions need to be made on where to put the sword client stuff... theres a circular dependency that needs to get broken
[20:23] <robint> mdiggory : Happen to help, I feel a bit responsible
[20:24] <mdiggory> IE I can't have sword client dependent on dspace-sword-api and be consolidated into dspace-api
[20:24] <mdiggory> it needs to be inside one of the webapps or maintained separately.
[20:24] <tdonohue> that "SWORD Client" is actually a "SWORD Client XMLUI Aspect", so I think it seems ok to have in the XMLUI for now (just my opinion)
[20:25] <robint> Seems a pragmatic solution to me too
[20:26] <mdiggory> robint: any CLI requirements for the sword client?
[20:26] <robint> Nope, just xmlui
[20:27] <robint> If its a nuisance just hack it to allow yourself to move on and I'll investigate
[20:27] <mdiggory> so, the other special considerations are dspace-stats and dspace-discovery
[20:28] <mdiggory> At this point I kept the Discovery Solr provider in a separate project, but this may / may not really be neccessary
[20:28] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-discovery-solr
[20:28] <kompewter> [ DSpace/dspace-discovery-solr at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-discovery-solr
[20:29] <tdonohue> Where else would Discovery Solr go? dspace-api?
[20:31] <mdiggory> it could get consolidated into dspace-api with the other discovery stuff...
[20:31] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-api/src/main/java/org/dspace/discovery
[20:31] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/discovery at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-api/src/main/java/org/dspace/discovery
[20:31] <tdonohue> gotcha. thanks
[20:32] <mdiggory> the idea in keeping it separate was to allow for the other approaches such as elastic search, etc... but again, I don't think keeping the code separate solves this... the spring configuration is where this is dealt witj
[20:32] <mdiggory> so, theres not really a need to keep the code separate from dspace-api, its just additional omplexity
[20:32] <tdonohue> It seems reasonable to just put it with the other "org.dspace.discovery" stuff (in dspace-api) unless there's a reason it needs to be separate. The only other alternative would be to pull all the Discovery stuff out into a 'dspace-discovery' project, but I'm not sure that gives us anything either.
[20:33] <tdonohue> makes sense mdiggory. I'd be fine with putting all the discovery code together in one place
[20:33] <mdiggory> the other stuff is statistcs...
[20:33] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-stats/src/main/java/org/dspace/statistics
[20:33] <kompewter> [ DSpace/dspace-stats/src/main/java/org/dspace/statistics at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-stats/src/main/java/org/dspace/statistics
[20:34] <mdiggory> as elastic search was also dumped into here...
[20:34] <mdiggory> https://github.com/DSpace/DSpace/tree/master/dspace-stats/src/main/java/org/dspace/statistics
[20:34] <kompewter> [ DSpace/dspace-stats/src/main/java/org/dspace/statistics at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/tree/master/dspace-stats/src/main/java/org/dspace/statistics
[20:34] <mdiggory> it might again just be consolidated into dspace-api
[20:35] <PeterDietz> So although the ES code is there in dspace-stats.. If you don't use it.. It never instantiates that service..
[20:36] <mdiggory> the benefit of keeping separate addon projects is that we can isolate the implementations and manage their dependencies separately. for instance, if one wanted to drop solr and use elastic search across the board for search and statistics, then its feasible to not carry around those unneeded dependencies in ones build
[20:36] <mdiggory> so, yes PeterDietz while its not turned on, your still getting all its parts and packaing it.
[20:37] <mdiggory> so, thats a trade off / dialog...
[20:37] <tdonohue> I guess the only observation I'd make is that it sounds like we're heading in the direction of "put it in the dspace-api if it's not webapp specific". I vaguely recall a past conversation about the dspace-api having too much stuff in it?
[20:37] <mdiggory> which is preferable in the community.
[20:37] <tdonohue> (note: I'm not saying this stuff shouldn't go into dspace-api...just wanting to bring up that observation)
[20:37] <mdiggory> that was a question, not a statement
[20:38] <mdiggory> tdonohue: I'm cautious too
[20:38] <PeterDietz> I'm gonna go look at where MDS (Richard's DSpace Kernel) ended up...
[20:38] <mdiggory> thats why they were still separate in the Consolidation Project
[20:38] * nhoussos (5548c37a@gateway/web/freenode/ip.85.72.195.122) has joined #duraspace
[20:39] <tdonohue> A part of me is slightly worried about putting more stuff into dspace-api, as I worry about our ability to "pull it back out" again (into something like a "common business logic layer" if we ever decide to build on). But, I can also understand the need for simplicity (less folders / maven projects)
[20:39] <mdiggory> It would be nice to be able to say something like mvn package -Pelasticsearch|xmlui|sword
[20:40] <mdiggory> or mvn package -Psolr|xmlui|sword
[20:40] <PeterDietz> or nicer to go to http://dspace/admin/modules and click buttons...
[20:40] <hpottinger> +1 clicking buttons
[20:41] <mdiggory> :-(
[20:41] <tdonohue> others thoughts here? Should we put this all into dspace-api? Do we keep some things separate (Discovery and/or Stats, for example)? Or do we just not care all that much ;)
[20:41] <mdiggory> MAX!
[20:41] <PeterDietz> lol
[20:42] <mhwood> Alternatives maybe should be separate projects so the un-chosen ones can be excluded.
[20:42] <mdiggory> mhwood: but exclusion suggests that theres good API / Provider support...
[20:42] <mhwood> If you want to pull stuff in through the UI, that suggests to me an even greater separation: it should be separately packaged, and you point the UI to the add-ons you want.
[20:43] <tdonohue> A part of me wonders (and this is a total brainstorm) if larger "modules" should be more standalone -- i'm thinking of a "dspace-stats" project, "dspace-discovery" project (with both Elastic Search / Solr), etc.
[20:43] <mhwood> As in: there's a Zip at this path -- install it.
[20:43] * mdiggory looks down the rabbit hole...
[20:44] <mdiggory> mhwood: I understand wanting that... do you want to know how thats generally facilitated in JAVA webapps today?...
[20:45] <mhwood> Yeah, that's too much for right now.
[20:45] <mdiggory> OSGI
[20:45] <tdonohue> For 3.0, I'm fine with just putting it all into dspace-api (if that's easiest). I'd just like to eventually get to a place where the 'dspace-api' is not so large (someday off in the future).
[20:45] <mdiggory> https://developer.atlassian.com/display/PLUGINFRAMEWORK/Plugin+Framework
[20:45] <kompewter> [ Plugin Framework - Plugin Framework ] - https://developer.atlassian.com/display/PLUGINFRAMEWORK/Plugin+Framework
[20:47] <mdiggory> tdonohue: I actually think that pushing everything we can into dspace-api would/could precipitate the eventual reorganization of dspace-api
[20:47] <mhwood> If we make it bad enough, someone will fix it? :-/
[20:47] <mdiggory> mhwood: I understand, but no...
[20:48] * mhwood thinks we need to keep a clear distinction between consolidation (happening now) and reorganization (plan to do that in 4.0?)
[20:48] <mdiggory> If we undo the previous assumption that addons are strictly maven modules, new opportunities for modularization can emerge
[20:49] <mdiggory> including some of the possibilities you just pointed out being considered
[20:49] <hpottinger> I think Richard's MDS code experiments with zipped module code
[20:49] <mhwood> I was thinking of how add-ons go into PKP products such as OJS. Haven't studied how they do it.
[20:50] * tdonohue notes this is another rabbit hole :) We should keep discussion to 3.0 as best we can, so that we can keep the release moving along
[20:50] <mhwood> Anyway that's PHP, not Java, so we might naturally go a different route.
[20:51] <tdonohue> (but I fully welcome more of these brainstorms/ideas post-3.0, or at least once we have 3.0 mostly ready)
[20:51] <mhwood> Oh, my ears and whiskers, we'll be late! Yes, concentrate on consolidation today....
[20:51] <hpottinger> mhwood +1 good quote
[20:51] <mdiggory> so... the question was to stick elasticsearch and solr dependent code into dspace-api
[20:52] <mdiggory> or keep it in separate maven projects
[20:52] <mhwood> Leave separate is less work, and less we might be undoing later.
[20:53] <tdonohue> I'm 50/50 here...so, I guess that means I vote 0. Either way is fine :)
[20:53] <tdonohue> (I.e. whatever is really easiest)
[20:54] <mdiggory> Ok... I'll advise once I setup the new branch.
[20:54] <mhwood> If it was just me doing it, I think I'd say leave separate for now and maybe consolidate more later when things are clearer.
[20:55] <mhwood> Fewer modules is fewer modules, whether or not we get to minimal module count.
[20:55] <mdiggory> I have one other request... we have some UI theming improvements for discovery.... https://github.com/DSpace/DSpace/pull/87/files
[20:55] <kompewter> [ [DS-1271] Tweaking of the new discovery user interface interface by KevinVdV · Pull Request #87 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/87/files
[20:56] <mdiggory> I think this is only Mirage...
[20:56] <tdonohue> That pull #87 looks minor (in terms of the changes, mostly just minor CSS/images).
[20:57] <PeterDietz> I see some Reference fixes too.
[20:58] <PeterDietz> looks fine / safe
[20:59] <mdiggory> Ok... the other PR that can be automatically merged is https://github.com/DSpace/DSpace/pull/85
[20:59] <kompewter> [ [DS-1268] Fixed wrong URL for OpenSearch description.xml document by nesovi · Pull Request #85 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/85
[21:00] <mdiggory> I'm ok with this one...
[21:00] * hpottinger thinks someone else needs some fun this week... any volunteers for Max duty?
[21:01] <mdiggory> did it...
[21:01] <tdonohue> On Pull #85, the only thing that looks odd is the first file change -- it's removing a "ConfigurationManager.getProperty()" call and replacing it with a hardcoded value. But, that being said, maybe there's a reason for it?
[21:01] <PeterDietz> I don't like looking at PR's, and seeing "Mark Flew Over the Cuckoo's Nest"
[21:01] <tdonohue> (whoops -- mdiggory already merged...I took too long to type)
[21:01] <robint> Can I drag us back to the Maven work. We plan to cut RC1 middle of next week, is that realistic ?
[21:01] <mdiggory> sorry, maybe I jumped the gun
[21:02] <tdonohue> mdiggory -- it may actually be OK. Just worth looking at briefly to be certain.
[21:02] <tdonohue> robint is right...back to Maven work & 3.0 schedule.
[21:02] <hpottinger> Blast and rise, don't apologize :-)
[21:02] <mdiggory> PeterDietz: Its the Shining.
[21:03] <tdonohue> mdiggory -- is cutting RC1 mid-next week still reasonable? Will Consolidation be done by end of this week or very early next?
[21:04] <mdiggory> I think thats sensible
[21:04] <tdonohue> note -- even after the Maven Consolidation gets done, it'd be nice to get a few more of the bug fixes in before RC1. There's some that are mostly ready but have "fallen out of date"
[21:05] <mdiggory> It would be good to identify any of those.
[21:06] <tdonohue> Well, one bug fix is the one I did for Windows Unit Tests (https://github.com/DSpace/DSpace/pull/30). Unfortunately every time I update it, it falls out of date again cause of more major changes. At this point, I'm waiting till post-Maven consolidation
[21:07] <tdonohue> Plus, EOL Normalization still should be done (https://github.com/DSpace/DSpace/pull/65). Another that is post-Maven consolidation, but hopefully pre-RC1.
[21:07] * tdonohue notes kompewter fell asleep
[21:08] <robint> Got to head off unfortunately. Cheers all
[21:08] <mdiggory> agnostic.build.dir ???
[21:08] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:08] <tdonohue> So, in other words, it'd be nice to get the Maven Consolidation done soon, so we have time to cleanup other things before RC1 ;)
[21:09] <tdonohue> mdiggory -- that maven variable (agnostic.build.dir) is necessary to allow Windows to run Unit Tests. Currently on Windows, if you run Unit Tests everything errors out (cause the paths all use forward slashes instead of the backwards slashes windows expects)
[21:09] <mdiggory> Transcendental Maven Build Dependency ;-)
[21:10] <hpottinger> you'd think maven would have a workaround for that...
[21:11] <mdiggory> Is this a BUG in edu.iu.maven.plugin:fileweaver?
[21:12] <tdonohue> It does have to do with recent Unit Testing Framework changes....the DSpace Unit Tests *used to work* on Windows, but now they do not.
[21:12] <mdiggory> mhwood: nudge nudge, wink, wink...
[21:12] <mhwood> Well, then, I must've broken them somehow. Will take a look.
[21:12] <hpottinger> google takes me to this: http://stackoverflow.com/questions/3872355/how-to-convert-file-separator-in-maven
[21:13] * nhoussos (5548c37a@gateway/web/freenode/ip.85.72.195.122) has left #duraspace
[21:14] <mhwood> Meanwhile, I have to go. I put a note on my keyboard to dig into this tomorrow.
[21:14] <mdiggory> great...
[21:14] <tdonohue> Oh, I remember why this is... It's cause mhwood changed the Unit Tests to use the "project.build.directory" property from Maven. That is problematic on Windows, as the "project.build.directory" ends up being something like "C:\DSpace" and the Unit Tests need the backward slash to be a forward slash (C:/DSpace)
[21:14] <tdonohue> Or, I think that's why it is...
[21:15] <tdonohue> hpottinger -- that stackoverflow.com URL describes the exact fix I used in Pull #30
[21:15] <mhwood> Thanks, will take a look.
[21:16] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:16] <hpottinger> wonder if we could sneak some programatic script into the build.xml file, too...
[21:16] <mdiggory> that seems like they were short sighted. seems like all paths in java should be treated as file URL....
[21:17] <mdiggory> ok... Well, for now I'll operate as if this will happen after consolidation...
[21:18] <tdonohue> yes, I think this will just happen post-consolidation. #1 priority right now is the Maven consolidation. Hopefully we can get that done soon enough that we'll have a few days to do some final cleanup / bug fixes before RC1
[21:20] <hpottinger> gotta bolt soon, little league game to get to
[21:21] <tdonohue> I think we're done for today. Sounds like we have a plan to get Maven Consolidation done this week (or early next) (mdiggory let us know if you need help, or you think it will end up being "late"), then RC1 hopefully mid-week next week so we can do Testathon starting Mon, Oct 8
[21:22] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:24] * tdonohue is heading into "lurking" mode now. Talk to you all later!
[21:24] <mdiggory> Thanks tdonohue I'll let you know
[21:26] * kstamatis (5b8c1fd8@gateway/web/freenode/ip.91.140.31.216) Quit (Quit: Page closed)
[21:53] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:46] * mdiggory (~mdiggory@rrcs-74-87-47-118.west.biz.rr.com) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.