Timestamps are in GMT/BST.
[0:14] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) has joined #duraspace
[0:14] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) Quit (Changing host)
[0:14] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[0:26] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[3:27] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) has joined #duraspace
[3:27] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) Quit (Changing host)
[3:27] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[3:30] * eddies (~eddies@unaffiliated/eddies) Quit (Client Quit)
[6:48] -verne.freenode.net- *** Looking up your hostname...
[6:48] -verne.freenode.net- *** Checking Ident
[6:48] -verne.freenode.net- *** Found your hostname
[6:48] -verne.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@atlas.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
[11:29] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) has joined #duraspace
[11:29] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) Quit (Changing host)
[11:29] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:11] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:12] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) has joined #duraspace
[12:12] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) Quit (Changing host)
[12:12] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:23] * eddies (~eddies@unaffiliated/eddies) Quit (Read error: Connection reset by peer)
[12:32] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[12:53] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:27] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Quit: Leaving)
[13:28] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:38] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
[13:43] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) has joined #duraspace
[13:43] * eddies (~eddies@c-107-3-66-87.hsd1.ma.comcast.net) Quit (Changing host)
[13:43] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[14:10] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:15] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[14:41] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[15:04] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[15:42] * linux4u (~james@employed.library.emory.edu) has joined #duraspace
[15:57] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[15:59] * tdonohue1 (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[15:59] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Disconnected by services)
[17:06] <linux4u> I have a question about fcsu, what the best way to convert a live 7tb system to akubra? can i just make it read only and start the conversion? or will I have to shut down the system.
[17:08] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[17:31] * tdonohue1 is now known as tdonohue
[18:23] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:02] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:36] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[19:41] * l_a_p (~chatzilla@176.206.48.184) has joined #duraspace
[20:00] * robint (522a6b02@gateway/web/freenode/ip.82.42.107.2) has joined #duraspace
[20:00] <robint> hi all
[20:00] <tdonohue> Hi All, welcome. It's time for our DSpace Developers Mtg. Agenda (cobbled together at last minute): https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-04-24
[20:00] <kompewter> [ DevMtg 2013-04-24 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-04-24
[20:01] <tdonohue> As we've decided, we're going to start by doing some Pull Request reviews (to stay on top of those): https://github.com/DSpace/DSpace/pulls
[20:01] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls
[20:02] <tdonohue> wrong link. We want *oldest* first: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:02] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:02] <tdonohue> and we last reviewed Pull 51
[20:02] <tdonohue> so, we'll start with Pull # 61
[20:03] <tdonohue> https://github.com/DSpace/DSpace/pull/61
[20:03] <kompewter> [ Enabling Dynamic DSpace Configuration Manager by lyncodev · Pull Request #61 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/61
[20:03] <tdonohue> looks like this one has had a lot of discussion (ending 8 mos back)
[20:03] <helix84> that was a "conversation starter"
[20:04] <tdonohue> mdiggory looks to be arguing for a "Configs in the DB" solution (so that they can be configured by non-developers / non-sysadmins)
[20:05] <tdonohue> joao (if I'm skimming right) was recommending starting with a file-based config approach (since configs are currently in files)
[20:05] * bollini (~chatzilla@host106-110-dynamic.16-87-r.retail.telecomitalia.it) has joined #duraspace
[20:05] <helix84> and joao argues that storage doesn't matter that much, but file-based approach has some benefits
[20:06] <helix84> the point is dynamic configuration (as opposed to restart to change), not XY-based
[20:07] <tdonohue> One "compromise" option is to go an "EPrints-route" (from what I've seen of EPrints). Many of their configs are also in files...but they allow ways to configure from Admin UI (which just writes to those config files for you)...this is similar to many other tools out there -- IDEs, web browsers, etc. many have config files which are auto-managed by the App
[20:08] <helix84> that was joao's original idea, before the conversation
[20:08] <tdonohue> Ok, well, I think I'd support that idea, personally. I don't really care where the configs are stored (files are fine), as long as they are manageable from the UI (eventually)
[20:09] <tdonohue> but, that doesn't really answer what we do with this Pull #61. Is joao still looking for feedback here / still working on this?
[20:09] <helix84> about the pull request, i think it wasn't meant to be pulled, just discussed. and i'm fairly sure lyncode has been working on this idea since then.
[20:10] <mhwood> I need to see how this fits with my little project to turn ConfigurationManager into a wrapper around ConfigurationService.
[20:11] <tdonohue> Ok. So do we leave this Pull open for now? try to continue the discussion until Joao/Lyncode has more to show us?
[20:11] <hpottinger> +1 leave open, continue discussion
[20:11] <mhwood> I think so.
[20:11] <helix84> it probably doesn't matter what we do with it, but keeping it open may keep it "on the radar"
[20:12] <tdonohue> ok.. we'll keep open & on radar.
[20:12] <tdonohue> one more for today: https://github.com/DSpace/DSpace/pull/78
[20:12] <kompewter> [ DS-1226 Initial contribution: (JSP)UI Import from bibliographics database/formats by abollini · Pull Request #78 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/78
[20:12] <robint> PS could we add a comment that we discussed it and decided to leave it opn?
[20:13] <robint> Just to remind us that we reviewed it?
[20:13] <tdonohue> robint: was going to momentarily
[20:13] <tdonohue> (sorry I didn't make that clear, obviously)
[20:13] <robint> One step ahead of me :)
[20:14] <robint> With regards to pull/78, did the contribution from the Athens crowd sneak in ahead of this one?
[20:15] <bollini> I'm not able to work on pull/78 now... I can resume/update later (some months, we are now working on a new version of dspace-cris)
[20:15] <robint> Hi Andrea
[20:15] <bollini> coming back (sometime) :-)
[20:15] <helix84> bollini: would it be usable as-is?
[20:16] <tdonohue> I'm confused... Pull #78 says it refers to DS-1226 (which is closed & added to 3.0)?
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1226 ] - [#DS-1226] Batch import from basic bibliographic formats (Endnote, BibTex, RIS, TSV, CSV) - DuraSpace JIRA
[20:17] <bollini> mmm... my fault it is a different jira issue
[20:17] <helix84> that doesn't sound right, Ds-1226 was from EKT, #78 is from Andrea
[20:17] <robint> tdonohue: I think they covered some of the same functions
[20:17] <tdonohue> ok... hence my confusion here.
[20:17] <helix84> https://github.com/DSpace/DSpace/pull/46
[20:17] <kompewter> [ [DS-1226] Batch import from major bibliographic formats by EKT · Pull Request #46 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/46
[20:17] <robint> and the code for DS-1226 was committed for 3.0
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1226 ] - [#DS-1226] Batch import from basic bibliographic formats (Endnote, BibTex, RIS, TSV, CSV) - DuraSpace JIRA
[20:18] <tdonohue> so, do we leave Pull #78 open and create a new JIRA ticket for it? Or do we close it and wait for a new JIRA ticket + new Pull?
[20:18] <helix84> DS-1252
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1252 ] - [#DS-1252] (JSP)UI Import from bibliographics database/formats - DuraSpace JIRA
[20:18] <helix84> i'll change the PR title
[20:18] <bollini> thanks helix
[20:19] <tdonohue> Oh, thanks helix84.
[20:19] <tdonohue> ok. So, leave Pull #78 open for now? (and correct its title obviously)
[20:20] <bollini> I will add a comment to alert users that work is now "stopped" and will be resumed later
[20:20] <tdonohue> sounds good, bollini. thanks
[20:20] <tdonohue> Ok. we'll stop the Pull Request review there for today.
[20:21] <tdonohue> The rest of today's agenda is really relatively "open". I stuck in some placeholders on 3.2 updates and 4.0 Planning (and getting more volunteers for the 4.0 Release Team). But, we can talk about either one first
[20:22] <tdonohue> hearing nothing, i guess we'll start with 3.2 updates
[20:23] <tdonohue> it looks like we still have 3 tickets open which we've talked about as warranting a 3.2 -- DS-1469, DS-1525 and DS-1528
[20:23] * helix84_ (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-1469 ] - [#DS-1469] Repository name with the accent (dspace.cfg with UTF-8 encoding show incorrect) - DuraSpace JIRA
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-1525 ] - [#DS-1525] build.properties not interpolated properly when building with Maven 3 - DuraSpace JIRA
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-1528 ] - [#DS-1528] build.properties doesn't support UTF-8 encoding - DuraSpace JIRA
[20:23] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Ping timeout: 255 seconds)
[20:23] * helix84_ is now known as helix84
[20:24] <tdonohue> oh, I see.. DS-1469 is waiting for input from us: robint & helix84 had a discussion there
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-1469 ] - [#DS-1469] Repository name with the accent (dspace.cfg with UTF-8 encoding show incorrect) - DuraSpace JIRA
[20:24] <robint> No I think its is resolved
[20:24] <robint> It is committed
[20:25] <robint> Sorry!
[20:25] <robint> taling rubbish
[20:25] <tdonohue> yep. it's committed to "master" (4.0).
[20:25] <robint> yep
[20:25] <tdonohue> So, I guess the plan is to wait on 4.0 for that one...so it wouldn't be in a 3.2
[20:25] <robint> I left it open in case anyone felt strongly it hould go in 3.2
[20:26] <robint> But nobody has commented to that effect yet
[20:26] <hpottinger> is there any harm in back porting it?
[20:26] <helix84> my counter argument is that we don't want it into 3.2 because it doesn't really bring any benefit without also fixing the related ticket, OTOH it can break stuff
[20:27] <tdonohue> it looks like the concern in "backporting" is that it's a decent amount of code changes -- with no testathon in sight: https://github.com/DSpace/DSpace/pull/199/files
[20:27] <kompewter> [ Read config, email and license files UTF-8 encoded, fixes DS-1469 partly by tuub · Pull Request #199 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/199/files
[20:28] <tdonohue> (and those code changes are all in ConfigurationManager, which is obviously central to DSpace in general)
[20:28] <robint> That seems a reasonable argument to me so someone would need to argue that they really need it in 3.2
[20:29] <tdonohue> I'm fine with it waiting for 4.0. It'd be nice to release sooner, but I'm not sure it'll get enough testing sooner
[20:29] <hpottinger> code exists, if someone needed it, they could back port it themeselves
[20:29] <tdonohue> very true
[20:29] <bollini> mmm... just a note, are you reproduced this bug with the -Dfile.encoding=UTF8 settings?
[20:29] <helix84> bollini: no, i personally haven't tried that
[20:30] <bollini> I have see a very similar problem in a custom code for one our customer last week and I have realized that we have missed this configuration in the tomcat startup
[20:30] <bollini> the dspace manual say that it is required (I'm seeking the reference)
[20:30] <helix84> bollini: is there a way to make it default? or is that a problem?
[20:30] <robint> I tried that but FileReader doesn't seem to respect that
[20:31] <robint> FileReader seems to have a mind of its own and decides what endoing it fancies using
[20:31] <bollini> helix84: I think that default is better as it is required, but if the effect to force is the same of -Dfile.encoding we should be safe to include the change immediatly
[20:31] <helix84> https://wiki.duraspace.org/display/DSDOC3x/Installation#Installation-ServletEngine(ApacheTomcat5.5orlater,Jetty,CauchoResinorequivalent)
[20:31] <kompewter> [ Installation - DSpace 3.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC3x/Installation#Installation-ServletEngine(ApacheTomcat5.5orlater,Jetty,CauchoResinorequivalent)
[20:31] <helix84> second bullet point here ^^^
[20:33] <tdonohue> ok, well, it sounds like Ds-1469 can be closed (and switched to be "4.0" instead of "3.2"), since it's associated Pull Request (#199) is committed to master?
[20:34] <helix84> tdonohue: yes, that's what i meant
[20:34] <robint> Ok, I'll close it, thanks
[20:34] <tdonohue> thanks robint
[20:35] <bollini> ok, just put a note in the jira issue that add -Dfile.encoding could be a workaround for "old" release
[20:35] <robint> bollini: actually that doesn't work
[20:36] <helix84> btw i just checked and none of my instances (including demo) are configured with -Dfile.encoding
[20:36] <robint> Don't know why but FileReader doesn't pick it up
[20:36] <bollini> robint: ah ok, I was missed that!
[20:36] <robint> It seems to be a known problem but not well documented
[20:37] <robint> The fix is is to use an InputStream and specify the encoding in the constructor, which is what the pull request does
[20:37] <robint> I will not this in the Jira issue. Thanks
[20:38] <robint> not/note
[20:39] <tdonohue> Ok. So, the other two tickets that we had possibly scheduled for a 3.2 release were build.properties issues: DS-1525 and DS-1528
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1525 ] - [#DS-1525] build.properties not interpolated properly when building with Maven 3 - DuraSpace JIRA
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1528 ] - [#DS-1528] build.properties doesn't support UTF-8 encoding - DuraSpace JIRA
[20:39] <tdonohue> currently, both are unassigned...whoops.
[20:40] <tdonohue> mhwood - do you know how to fix Ds-1525 in our code (as you mention the workaround)
[20:41] <tdonohue> oh, wait...looks like a simple Maven config change perhaps?
[20:41] <mhwood> It awaits a release of the resources plugin that uses a sufficiently recent version of Plexus. I haven't tried this for a while, but the problem appeared in Resources 2.4 and 2.6 is out.
[20:42] <tdonohue> ok. So, did you actually run into a problem here? I'm just surprised I hadn't seen this yet in filtering of email addresses
[20:42] <tdonohue> (wondering specifically how to "reproduce" this in DSpace)
[20:43] <mhwood> I should have written more, because I don't recall exactly how I tripped over this.
[20:43] <hpottinger> I've been using build.properties and Maven 3.05 for a while now, and haven't noticed any problems with e-mail addresses, though perhaps it's a problem of me not noticing :-)
[20:44] <tdonohue> do we dare "close" this then? Do we leave open and write a note that we haven't been able to reproduce it recently?
[20:45] <tdonohue> (I'm in the same boat as hpottinger...have been running Maven 3 + DSpace 3 and haven't noticed email address issues at all so far)
[20:46] <mhwood> Maybe Resources 2.5 or 2.6 fixed it, and I didn't notice. I'd say, leave it open and bug mhwood to explain.
[20:46] <hpottinger> sez mhwood
[20:47] <tdonohue> oh, Resources 2.5 fixed it: http://jira.codehaus.org/browse/MRESOURCES-104
[20:47] <kompewter> [ [#MRESOURCES-104] while filtering resources the token replacement stops at the character @ - jira.codehaus.org ] - http://jira.codehaus.org/browse/MRESOURCES-104
[20:47] <tdonohue> so, it's fixed
[20:48] <tdonohue> I'm gonna close & note that the fix is to ensure you have maven-resources-plugin v. 2.5 or above (latest is 2.6) by running "mvn -U clean package"
[20:48] <mhwood> Yay! And we're actually *using* 2.5 or later? IIRC Maven pins down a set of standard plugin releases with each Maven release.
[20:49] <tdonohue> I don't think we specify the version of maven-resources-plugin. But if you run "mvn -U" then Maven will go get the latest version for you
[20:49] <mhwood> OK, if it works, it works.
[20:50] <tdonohue> closed & commented
[20:50] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) Quit (Ping timeout: 276 seconds)
[20:50] <mhwood> Thanks.
[20:51] <tdonohue> ok...might as well look at DS-1528 too then (the now "lone" ticket marked as 3.2)
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-1528 ] - [#DS-1528] build.properties doesn't support UTF-8 encoding - DuraSpace JIRA
[20:51] <mhwood> Ds-1528: so, if we ship with the Resources encoding configured we can close this one too?
[20:52] <tdonohue> re: Ds-1528: Surprisingly, I tried setting "maven-resources-plugin" to UTF-8 encoding, and I couldn't get it to work right.
[20:52] <tdonohue> But, now I wonder if maybe *I* had a bad version of the maven-resources-plugin as well
[20:52] <tdonohue> (i.e. maybe this is another bug they fixed?)
[20:53] <tdonohue> hmmm... searching Maven Resource plugin bug tracker. Found this (it sounds like the same issue): https://jira.codehaus.org/browse/MRESOURCES-175
[20:53] <kompewter> [ [#MRESOURCES-175] Bad encoding in filtering - jira.codehaus.org ] - https://jira.codehaus.org/browse/MRESOURCES-175
[20:54] <tdonohue> (though that ticket is brand new & unverified)
[20:55] <mhwood> The encoding may apply only to the resources being copied.
[20:57] <mhwood> The plugin doesn't read the properties it interpolates; that's some other part of maven or some other plugin. That is the place where the encoding of properties would matter.
[20:57] <tdonohue> where do you see that note, mhwood?
[20:58] <mhwood> Actually I say that because I *don't* see that Resources reads in properties. It uses the properties already defined.
[20:58] <mhwood> Not so?
[20:59] <mhwood> So build.properties would have to be loaded using the proper encoding. Let's see, which plugin reads it....
[21:00] <tdonohue> hmmm... I thought it read in the files. The Resources "encoding scheme" docs say that you can set "a character encoding scheme ... for the reading and writing of files": http://maven.apache.org/plugins/maven-resources-plugin/examples/encoding.html
[21:00] <kompewter> [ Maven Resources plugin - Specifying a character encoding scheme ] - http://maven.apache.org/plugins/maven-resources-plugin/examples/encoding.html
[21:01] <tdonohue> but, it's possible I'm confused here too (been a while since I looked at this closely... I may be missing something)
[21:01] <robint> Sorry but I have to run, cheers all
[21:01] * robint (522a6b02@gateway/web/freenode/ip.82.42.107.2) Quit (Quit: Page closed)
[21:01] * tdonohue notes that we are in "overtime". If you need to head out, feel free. I'll be around for a bit longer though
[21:02] <mhwood> That's the resource files. build.properties isn't a resource file; it's a source of properties to filter in. Waitaminute...<filters.file>....
[21:03] * l_a_p_ (~chatzilla@176.206.48.184) has joined #duraspace
[21:03] <mhwood> OK, build.properties is read because it's specified in <build><filters><filter>${filters.file}</filter></filters>....
[21:03] <tdonohue> yes, that is correct
[21:04] <bollini> good night (11pm in Italy), see you next week
[21:04] <mhwood> What reads in the "filter resources"?
[21:05] * l_a_p (~chatzilla@176.206.48.184) Quit (Ping timeout: 256 seconds)
[21:05] * l_a_p_ is now known as l_a_p
[21:06] * bollini (~chatzilla@host106-110-dynamic.16-87-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949])
[21:06] <tdonohue> mhwood - I thought it was the maven-resources-plugin which reads those filter resources. See: http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
[21:06] <kompewter> [ Maven Resources plugin - Filtering ] - http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
[21:07] <mhwood> <filters> is part of the BaseBuild.
[21:08] <mhwood> The example doesn't say what reads the <filter> resources.
[21:08] <tdonohue> yea, I'm realizing that. I had assumed it was that plugin..maybe I'm wrong though
[21:09] <mhwood> The example could be more clear.
[21:10] <tdonohue> agreed. One thing about maven & it's plugins...sometimes the documentation is unclear/vague
[21:11] * hpottinger just discovered all the free Maven-related ebooks on the Sonatype site
[21:11] <mhwood> I can't prove it but it looks to me as though Resources just asks something else for filter stuff. The something else would have to be configured to force Properties to load as other than 8859-1.
[21:11] <mhwood> Good luck with those. The _Complete Reference_ is not quite as incomplete as the _Definitive Guide_ was.
[21:12] <hpottinger> noted, thanks mhwood. I was mostly looking for Nexus documentation when I found them.
[21:12] <tdonohue> hmm... this sounds somewhat similar: http://www.coderanch.com/t/487058/tools/UTF-Maven-build-ISO-property
[21:12] <kompewter> [ An UTF-8 Maven build with n ISO-8859-1 property files [Solved] (Ant, Maven and Build Tools forum at JavaRanch) ] - http://www.coderanch.com/t/487058/tools/UTF-Maven-build-ISO-property
[21:13] <tdonohue> (not sure if that is the same problem we are having or not though)
[21:14] <mhwood> Perhaps not. It sounds like the problem there was with the files being copied, not with properties being interpolated.
[21:16] <helix84> i'm going to bunk down, bye!
[21:16] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[21:17] <mhwood> And I'm going to have to leave -- expected elsewhere.
[21:17] <tdonohue> ok. yea. I need to dig more into this. I'm still a bit confused as to what is going wrong... But, this discussion has helped
[21:17] <mhwood> Happy to be of service.
[21:17] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:18] * l_a_p (~chatzilla@176.206.48.184) has left #duraspace
[21:40] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:53] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
[21:55] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:06] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) Quit (Ping timeout: 256 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.