Timestamps are in GMT/BST.
[5:57] * LouwVenter (8fa07c28@gateway/web/freenode/ip.143.160.124.40) has joined #duraspace
[5:58] * LouwVenter (8fa07c28@gateway/web/freenode/ip.143.160.124.40) Quit (Client Quit)
[6:45] -sendak.freenode.net- *** Looking up your hostname...
[6:45] -sendak.freenode.net- *** Checking Ident
[6:45] -sendak.freenode.net- *** Found your hostname
[6:45] -sendak.freenode.net- *** No Ident response
[6:45] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:45] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:45] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:17] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:24] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:21] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[17:02] <tdonohue> Hi All, if anyone has DSpace stuff to discuss, I'll be lurking here for the next 3 hours as part of my "Office Hours": https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[17:09] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[17:10] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has left #duraspace
[17:10] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[19:37] * helix84 (a@195.113.97.174) has joined #duraspace
[19:41] <helix84> hi tim, look at /space/AIP-restore/reset-dspace-content.log
[19:42] <helix84> probably postgres didn't manage to restart before you started pg_dump
[19:44] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[19:45] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Remote host closed the connection)
[19:45] <helix84> (nevermind kompewter hopping on and off, i'm playing with it)
[19:46] <tdonohue> helix84: yea, I actually wondered about that. I realized through some tests today that most the script is fine...just a matter of pausing briefly while rebooting postgres before doing an automatic "reset" of the demo server
[19:48] <helix84> i noticed it only accidentally. where's the script?
[19:48] <tdonohue> in ~/bin/reset-dspace-content -- it cleans out demo.dspace.org entirely and resets it to the AIPs in ~/AIP-restore
[19:48] <helix84> i see now
[19:50] <helix84> i'll try to find a good solution (wait, not poll)
[19:51] <tdonohue> I think the 'wait' bash command may be the easiest fix (since it's a bash script anyhow0
[19:52] <helix84> i don't know what to wait for ATM, but i'll figure something out
[19:54] <helix84> tim, can you please add one 3.0 agenda point? I added the list of patches by EKT to Release Notes.
[19:55] <tdonohue> Hi all, reminder that we have our weekly DSpace Devel Mtg at the top of the hour (~5 mins) here : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-01
[19:56] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[19:56] <helix84> nevermind, i didn't look at the agenda :)
[19:56] <tdonohue> helix84 -- those are already listed on the agenda. We'll be going through some 3.0 JIRA tickets today (instead of normal JIRA review) :)
[19:56] <tdonohue> yes :)
[19:57] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:57] <helix84> do you have any idea when the release team will start making a list of accepted features?
[19:58] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:58] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[19:59] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:59] <tdonohue> helix84: no, I'm admittedly not on the release team, but you can ask during the mtg in a few
[20:00] <tdonohue> Hi all. It's that time again. DSpace Devel Mtg starts now: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-01
[20:00] <kompewter> [ DevMtg 2012-08-01 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-08-01
[20:01] <tdonohue> Today we'll kick things off a bit different. As we have a list of 3.0 submissions still needing some review, I thought we'd tackle some of those JIRA tickets as our "JIRA Review"
[20:01] <tdonohue> (list of 3.0 tickets I'm talking about is on the top of the agenda)
[20:01] <tdonohue> we'll start off with DS-1127
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1127 ] - [#DS-1127] Submission improvements: document type-based submission - DuraSpace JIRA
[20:03] <tdonohue> this seems to be a new/updated version of the old work from robint (DS-464)? Thoughts on this for 3.0 or anyone want to volunteer to review it more thoroughly?
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-464 ] - [#DS-464] Item type based submission - DuraSpace JIRA
[20:04] <robint> I'll have a look although I don't have much self interest as it says its XMLUI
[20:06] <mdiggory> This just reloads the Describe step with the forms required based on a selected dc.type value?
[20:06] <mdiggory> Can someone get this into a Pull Request?
[20:07] <hpottinger> mdiggory, I was about to ask the same :-) would be much easier to sort out what has changed if it were a pull request
[20:07] <tdonohue> mdiggory -- to me it looks like it does just that. It uses a new <type-bind> field in input-forms.xml, and then changes the Describe step form based on the dc.type (or at least, that's my assumption based on the description)
[20:07] <tdonohue> robint thanks for volunteering to look at it
[20:08] <tdonohue> I agree with others that it'd be nice to see the changes easier via a Pull Request
[20:08] <helix84> I can prepare the pull requests for today's items (for the EKT issues I'll first ask EKT if they want to make pull request)
[20:08] <tdonohue> thanks helix84!
[20:09] <mdiggory> Reminds me of another task in my pipeline... we needed to present different submission forms to Reviewers vs Submitters. One strategy being considered was to add a field to designate if the input-form field should it show in the submission or reviewer workflows
[20:09] <helix84> just a quick note - i actually didn't ask EKT if they meant these issues for 3.0, I only assumed it and put them on the 3.0 release notes page
[20:10] <tdonohue> Ok, gonna move on to the next one now...trying to just get some quick opinions here on some of these tickets with patches attached
[20:10] <tdonohue> helix84 -- thanks for noting that.
[20:10] <tdonohue> This next one is one of those EKT patches that helix84 is talking about: DS-1223
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-1223 ] - [#DS-1223] Display frequencies of items in single browsing for selected indices - DuraSpace JIRA
[20:11] <tdonohue> this is for JSPUI only
[20:11] <helix84> in parallel, let me ask a question to anyone from the release team: when do you mean to start publishing the list of features accepted into 3.0? (or will you publish it all at once?)
[20:13] * tdonohue notes that actually it's the *committers* that have a final decision on what goes into 3.0. The release team can make suggestions, & say what they think is ready (if they want), but it comes down to all of us to make final decisions
[20:14] <robint> helix84: It will just be everything that gets reviewed, accepted, and commited in time for the first release candidate
[20:14] <mdiggory> I suspect this overlaps with Andrea's work on discovery / Browse in JSPUI
[20:15] <hpottinger> I imagine it will be a week or so after feature freeze, depending on work load of those testing... or, really, post-testathon, before we know what the release will roll with
[20:15] <helix84> mdiggory: look at the comments
[20:15] <mdiggory> helix84: We are starting our process as of last week, we will see a couple new JIRA tasks and Pull requests emerging each week, up until the freeze date
[20:15] <tdonohue> Has anyone heard from Andrea Bollini around whether the Discovery + JSPUI work will be ready for 3.0?
[20:16] <mdiggory> getting tired of people calling solr "heavy"
[20:16] <robint> tdonohue: Andrea is on holiday at the moment
[20:16] <mdiggory> you want heavy?... try ORacle
[20:17] * hpottinger nods grumpily
[20:17] <robint> I think he expects to have that work ready but not until the very last moment unfortunately
[20:17] <tdonohue> I guess the bigger question on Ds-1223 is whether we want to allow it as an alternative to Discovery? Or is Discovery our recommended route?
[20:17] <tdonohue> robint: ok. good to know.
[20:17] <mdiggory> thats the 100000 $ question
[20:17] * tdonohue admits that I'm getting a bit worried that everything seems to be coming "at the last moment"
[20:18] * helix84 (a@195.113.97.174) Quit (Read error: Connection reset by peer)
[20:18] <robint> Personally speaking i am +1 for coalecsing around Discovery
[20:18] <mdiggory> tdonohue: apparently the nature of the beast
[20:18] <robint> Forgive the spelling :)
[20:18] <tdonohue> any thoughts on Ds-1223. Do we want to allow this? Or is our answer to go with Discovery?
[20:19] <mdiggory> robint: thats ok... studies show people only read the first and last work of any sentance
[20:19] <robint> :)
[20:19] <tdonohue> (alternatively, we can bring the Discovery idea to a more formal vote on dspace-commit or similar)
[20:19] <mhwood> What would still have to be done to get Discovery to do the "frequencies" stuff -- whatever that is?
[20:19] * helix84 (a@195.113.97.174) has joined #duraspace
[20:19] <robint> Can we wait and see Andrea's work ?
[20:19] <helix84> DS-1217
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-1217 ] - [#DS-1217] DSpace Discovery for JSPUI - DuraSpace JIRA
[20:20] <mdiggory> And with OSX now picking my words for me... Its like I don't even have to think anymore...
[20:20] * helix84 had some minor connection issue
[20:20] <tdonohue> Sure, robint. we can link up Ds-1223 and Ds-1217 & wait to see what comes from Andrea
[20:20] <mdiggory> +1
[20:21] <tdonohue> Ok. Sounds like that's our summary for Ds-1223: Link up to Ds-1217 work, and wait to see what the JSPUI + Discovery work looks like.
[20:21] <helix84> oh, it has no patch, sorry
[20:22] <tdonohue> Ok, as we are now 20minutes here, I'm going to slightly "switch topics" and open the floor to 3.0 in general. We can still review a few more of these JIRA tickets, or we can talk about something larger (like Advanced Embargo, etc.)
[20:23] <helix84> i admit i haven't yet looked at the patch, but if it's simple, i'm for accepting it as an alternative to the discovery approach
[20:23] <helix84> discovery does raise tomcat memory greediness, so I understand if someone doesn't want to use discovery
[20:24] <tdonohue> 3.0 Release Team members -- Is there something you feel would be good to tackle/discuss for 3.0 right now?
[20:24] <robint> Erm cn I sneak in one last Jira ? https://jira.duraspace.org/browse/DS-1208
[20:24] <kompewter> [ [#DS-1208] Build time filtering to allow multi developer/environment builds - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1208
[20:24] <mdiggory> but the benefits of that greediness are superior to the current capabilities of DSpace
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-1208 ] - [#DS-1208] Build time filtering to allow multi developer/environment builds - DuraSpace JIRA
[20:25] <robint> https://github.com/DSpace/DSpace/pull/40
[20:25] <kompewter> [ Pull Request #40: DS-1208 Build time filtering to allow multi developer/environment builds by steveswinsburg · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/40
[20:25] <tdonohue> sure, robint. :)
[20:25] <robint> This is something we do here anyway to cope for having more that one developer
[20:26] <robint> so I am +1
[20:27] <tdonohue> I'm going to admit that I haven't tried this before, but it seems reasonable to me, assuming it is well documented :)
[20:27] * hpottinger needs to look into this...
[20:27] <helix84> mdiggory: i understand that and i'm using it myself. i'm just pointing out that others may feel different, ergo that patch exists.
[20:28] <robint> It would require a change to our build instructions
[20:28] <tdonohue> robint: Does this work significantly change our normal Installation (for normal users)?
[20:28] <mhwood> Sorry I haven't gotten back to you robint. I haven't thought of any way that it would interfere with the test environment stuff.
[20:28] <helix84> I looked at Ds-1223 and it looks lightweight enough. I'm +1
[20:28] <robint> no problem mhwood
[20:28] <robint> No major change. Instead of editing dspace.cfg you edit a build.properties file
[20:29] <robint> This allows for a build.properties.tim and a build.properties.helix84 etc
[20:29] <mdiggory> S2-1208 there are some features I like about this....
[20:30] <robint> It also cleans up the pom a little by removing some profiles
[20:30] <mdiggory> at this time we've been putting dev, test, prod properties into maven profiles
[20:30] <mdiggory> this seems to externalize that into java properties files.
[20:31] * ryscher (ae61f77a@gateway/web/freenode/ip.174.97.247.122) has joined #duraspace
[20:31] <tdonohue> So, the one thing that's slightly odd to me is that the 'build.properties' doesn't include all the stuff in dspace.cfg. So, I'm assuming 'build.properties' is really all about "basic configs to install/build" DSpace, and then dspace.cfg is still to tweak the "running" settings?
[20:31] <mhwood> Then I guess we need to tell Maven which file to use this time....
[20:31] <KevinVdV> It also appears to just filter a hardcoded numer of module config files instead of all of them
[20:32] <robint> tdonohue: yes
[20:32] <hpottinger> I've been using maven profiles as well, though I like the idea of there being a supported approach to dev/staging/production workflows
[20:32] <robint> KevinVdV: I noticed that too. I assume it could be changed to do them all
[20:33] <mdiggory> KevinVdV: yea, that'd need to change...
[20:33] <KevinVdV> Yeah perhaps we should look into making it dynamic so all config files are filtered all the time
[20:34] <tdonohue> It just hit me that this actually would be a way to potentially *ease* future upgrades of configs. The base configs in 'build.properties' could still make their way into the appropriate *.cfg file even if the name/location of the *.cfg file were to change (like when we created all those /module/*.cfg files)
[20:34] <mdiggory> the problem I've had with the current approach to filtering dspace.cfg, is that we have to parameterize any properties we want to replace the values on in the dspace.cfg and add properties to the maven profile to populate those parameters
[20:36] <mdiggory> this is still not great....
[20:36] <mdiggory> +dspace.dir = ${dspace.dir}
[20:36] <helix84> sidenote: Lyncode is reworking dspace configuration manager from scratch, this is post-3.0
[20:36] <tdonohue> The more I think about it, I think this could be a good change. "build.properties" kinda also helps "hide" some of the complexities of the full dspace.cfg from the user during installation -- they really don't need to worry about them until after the installation.
[20:36] <mdiggory> I would prefer that the ConfigurationService was adopted.
[20:36] <helix84> https://wiki.duraspace.org/display/~lyncode/Dynamic+Configurations
[20:36] <kompewter> [ Dynamic Configurations - DSpace @ Lyncode - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~lyncode/Dynamic+Configurations
[20:36] <robint> Yes you could add whatever you want to your personal build.properties files. It could vary for each developer/environment.
[20:36] <hpottinger> tdonohue: yeah, I was thinking along the same lines, it's dspace.cfg-lite
[20:37] <helix84> instead of "lite" we should think in terms of "overlay"
[20:38] <robint> mdiggory: +1 for ConfigurationService rather than ConfigurationManager
[20:38] <mdiggory> what would be more beneficial is if the filtering looked up the key in the cfg file and replaced the value.
[20:38] <tdonohue> So, I think I'm +1 Ds-1208. But, I think we need to make sure it is very well documented & advertised, as it's a rather significant change to how people may be used to installing DSpace.
[20:38] <hpottinger> :-) helix84, yes, overlay is far more accurate
[20:38] <helix84> so you can change anything (not only several selected things) and the rest is taken from the fallback dspace.cfg
[20:38] <mhwood> So I have to specify -Dfilters.file=build.properties.mine every time I run Maven?
[20:39] <tdonohue> mdiggory : I like the idea of the 'key' lookup + ConfigurationService. But, it's just a matter of seeing if we can find someone to look into / develop in the next week or so
[20:39] <robint> mhwood: No Maven expects to find a build.properties file
[20:39] <tdonohue> so, you have to just rename the file to "build.properties" and then run Maven
[20:40] <helix84> can someone please briefly explain what do you mean by ConfigurationService and how it's different from ConfigurationManager?
[20:40] <robint> tdonohue: yes
[20:40] <mhwood> OK
[20:40] <mdiggory> http://rafacastanho.wordpress.com/2011/03/03/maven-write-an-properties-file/
[20:40] <kompewter> [ Maven write an properties file « LIFE NOTES ] - http://rafacastanho.wordpress.com/2011/03/03/maven-write-an-properties-file/
[20:40] <robint> tdonohue: which begs another question
[20:40] <robint> As you point out the build will fail by default as there is no build.properties file
[20:41] <robint> this currently forces the developer to change build.properties.sample to build.properties, and edit it
[20:41] <mhwood> Strictly speaking, the resources plugin is instructed to expect that file. There used to be a built-in expectation of build.properties in Maven 1.x but they took it out at some point. (This confused me for a while.)
[20:42] <hpottinger> robint: I like the suggestion on the pull request to change the POM to look for build.properties
[20:42] <tdonohue> helix84: The "ConfigurationService" is a service of the DSpace Service Manager built to handle loading of config files, etc. See this page (and the Service Mgt Tutorial linked off it): https://wiki.duraspace.org/display/DSDOC18/DSpace+Service+Manager
[20:42] <kompewter> [ DSpace Service Manager - DSpace 1.8 Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC18/DSpace+Service+Manager
[20:43] <robint> hpottinger: ok thanks. I can see both arguments, its a trivial thing that we can adjust if there is general approval
[20:43] <hpottinger> build failures aren't that bad, as long as the error message is friendly
[20:44] <mdiggory> helix84: The ConfigurationService is a complete reimplementation of ConfigurationManager as a Spring Bean
[20:44] <robint> There have been a couple of +1's, anyone against ?
[20:44] <mdiggory> well, accept for all the email and license junk that never should have been in ConfigurationManager,,,
[20:44] <tdonohue> I don't like the idea of the build failing by default. I'd rather the build.properties file exist, personally. Unless we had a useful error (like hpottinger says) that would say "build.properties file is missing, please copy the build.properties.sample and fill it out"
[20:45] <tdonohue> +1 Ds-1208 (but I already stated that)
[20:45] <hpottinger> oh, sorry, I'm +1 for 1208, with the suggested modification to the POM to have a friendly error message in case build.properties is found to be missing
[20:45] <robint> The author, Steve, says he could do that if that is our preference
[20:46] <KevinVdV> If we can fix the modules I'm +1
[20:46] <hpottinger> tdonohue's suggested wording is fine with me
[20:46] <helix84> let me just check - if i say +1, does it mean any configuration option can be overridden?
[20:46] <tdonohue> (agree with KevinVdV that it'd be nice to fix the module configs so they work too)
[20:46] <mdiggory> helix84: it supplies property placeholder replacement of all dspace.cfg properties in the ServiceManagers Spring Application Context such that you can parameterize Spring beans in the XML with properties from dspace.cfg it can also be autowired into any beans added to the servicemanager.
[20:46] <robint> helix84: assuming it is parameterised in dspace.cfg
[20:46] <helix84> oh, then i'm -1
[20:47] <robint> helix84: whats the problem there ?
[20:48] <mdiggory> helix84: the eventual goal was to either (a) gut ConfigurationManager and call ConfigurationService from inside it. or (b) replace all usage of ConfigurationManager with ConfigurationService,
[20:48] <helix84> the problem is that you're defining which options can be overriden. i know that you can add parameters to dspace.cfg, but it doesn't play nicely with git, at least not with my workflow...
[20:48] * tdonohue notes that fixing Ds-1208 so that *any* config can be overridden may be harder than it seems -- it would also mean finding a way to override & enable configs that are commented out by default.
[20:49] <mdiggory> helix84: robint this is what I mean by my comments eariler about relpacing the values based on just the key in the dspace.cfg.
[20:49] <helix84> let me clear that up: commiters are defining the parameters. I assume admins can add their own parameters, but this is inconvenient because you'd have dspace.cfg changes in working directory and the whole point of this is to avoid that
[20:50] <tdonohue> SIDENOTE: One minor quibble with the Pull Request #40 -- I'm not a fan of the removing of comments from dspace.cfg https://github.com/DSpace/DSpace/pull/40/files
[20:50] <kompewter> [ Pull Request #40: DS-1208 Build time filtering to allow multi developer/environment builds by steveswinsburg · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/40/files
[20:50] <mdiggory> "mdiggory: what would be more beneficial is if the filtering looked up the key in the cfg file and replaced the value."
[20:51] <robint> I am not sure I understand. As it stands it doesn't do what Mark suggests, therefore you can't add extra parameters, it just filters existing ones
[20:52] <tdonohue> mdiggory: I agree with that as being "more beneficial". But, does that mean we reject something that is still possible "good enough for now"?
[20:52] <helix84> robint: ok, then it's even worse from my point of view
[20:52] <mdiggory> robint: it filters those that have foo = ${some.property.i.want.to.parameterize}
[20:53] <mdiggory> so the config files need to have this throughout them for every possible property
[20:54] <mdiggory> I'm trying to find a good alternative as a maven plugin while we are talking
[20:54] <helix84> I'm not sure everyone understands what I'm trying to say, so let me start from the beginning. I understand the point of this is that you can have multiple "profiles" of configuration property overrides for different developers/machines,
[20:55] <mdiggory> this seems close...
[20:55] <mdiggory> http://code.google.com/p/maven-replacer-plugin/wiki/UsageGuide
[20:55] <kompewter> [ UsageGuide - maven-replacer-plugin - Usage guide (how to use and parameter definitions) - Maven Plugin to replace tokens within a file with a given value - Google Project Hosting ] - http://code.google.com/p/maven-replacer-plugin/wiki/UsageGuide
[20:55] <helix84> Currently, you can just copy your config/ directory over your working copy and build away merrily. The inconvenience is, that your config/ changes show up in your working directory diff.
[20:56] <mdiggory> replaces by "tokenValueMaps" about 1/3 way down page
[20:56] <helix84> So by having an override file (build.properties in this case) that is in .gitignore, you can get these overrides out of your working dir diff and you can even have multiple profiles selectable by ant/maven flag.
[20:57] <helix84> The only problem I have with that is that you're saying "only these enumerated options can be changed".
[20:57] <tdonohue> mdiggory: that plugin still looks like it would require tokens (e.g. $token.to.replace$) to be added to the dspace.cfg file (or at least that's what it looks like from the example)
[20:57] <helix84> (Sorry for the verbosity, I hope that clears it up.)
[20:58] <mhwood> Why does Maven even care about any of that stuff? It's used at install time (meaningful to Ant) and runtime (meaningful to DSpace itself). Shouldn't this be pushed down to Ant? Or whatever we use to do the installation?
[20:58] <mdiggory> tdonohue: no... Each token/value pair should be in the format: "token=value" (without quotations). If your token contains ='s you must escape the = character to \=. e.g. tok\=en=value
[20:59] <robint> helix84: sorry, I'm being a bit slow. You can still change other values directly in dspace.cfg.
[20:59] <hpottinger> mhwood: I personally like that the stuff in my target/build dir is the same as what's installed... I often run diffs on deployed configs to see what might have changed (mysterious elves at work)
[20:59] <mhwood> *grumble* install-time and run-time configuration should be in separate files....
[20:59] <tdonohue> mdiggory: I read that as being the *format* for the "build.properties" file (i.e. the file that will specify the values to replace the tokens with)
[21:00] <helix84> robint: i know, and it will show when you run "git diff", which is not desirable most of the time.
[21:01] <tdonohue> helix84: I understand the concern about only certain values can be changed. But, isn't this still a step in the right direction? As it is, if you change dspace.cfg and run "git diff" you'll see those changes anyhow
[21:01] <mhwood> Hmmm. What I usually do is copy config/dspace.cfg to ~/dspaces/configs/some-name.cfg, edit that as needed, and specify -Dconfig=~/dspaces/configs/some-name.cfg when firing up Ant.
[21:02] <robint> I think this helps with the 90% situation where we just want to change the dbusername etc
[21:02] * hpottinger knows how to do this already with maven profiles... is just interested in 1208 if it is a *supported community standard*
[21:02] <mhwood> If you're running under TOmcat, you can have it provide the DataSource and DSpace will ignore the configured stuff.
[21:02] <mdiggory> tdonohue: I"m sure the only way to know is to experiment with it.
[21:02] <mhwood> I think there's a way to do the same in Jetty.
[21:03] <helix84> tdonohue: I probably just have a different use case in mind than everyone else. I know about the status quo and I thought that this patch would allow me to work around that by having an override file which is not under version control.
[21:04] <mdiggory> mhwood: your point about using Ant or whatever the deployment process will be is well made. The use of Maven does however, also allow creating profiles for specific dependencies and modules to be included into the distribution as well.
[21:04] <robint> I am sure there are numerous valid ways to do this, this iss just one that I personally I find this to be neat
[21:04] <mhwood> Hmmm. This is one reason I would have liked the multiple-config stuff to be more like the /etc/foo.d directories you see a lot in Unixland. If I drop 999-my-stuff.cfg into that directory, the configuration reader, which just scoops up any files it finds there, applies my values last and that's that.
[21:04] <helix84> yay to mhwood!
[21:05] <mdiggory> that was the original intent of dsapce/config/modules...
[21:05] <robint> I think we are going round and round here. Could I ask people to try it and comment in Jira ?
[21:06] <helix84> mdiggory: so can you override an option in a module?
[21:06] <mdiggory> but the final solution ended up focused heavily on prefixing based on file name.
[21:06] <mhwood> Yeah, every module knows what its file name is. Which means we can't introduce more file names.
[21:06] <mdiggory> think about the way HTTPD works...
[21:06] <hpottinger> robint: I'll test
[21:06] <robint> thanks hpottinger
[21:07] <mdiggory> you have httpd.conf, conf.d/ and vhosts.d/ and so on... its not hardcoded. they are includes in the httpd.conf
[21:07] <mhwood> Apache HTTPD? Exactly. "include foo.d" reads every file in foo.d/, in lexical order.
[21:07] <mhwood> You get overlays, not rewriting.
[21:07] <mdiggory> you can make up "foo.d" and tack it onto the end of httpd.conf and sick whatever you want in there...
[21:07] <KevinVdV> Needs run ..... Until next time !
[21:07] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: Leaving)
[21:08] <tdonohue> I agree with robint that we may want to all summarize our opinions on the JIRA ticket for DS-1208
[21:08] <mdiggory> mhwood: right you still have to be sensitive to replicating properties
[21:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1208 ] - [#DS-1208] Build time filtering to allow multi developer/environment builds - DuraSpace JIRA
[21:08] <helix84> can we postpone this post-3.0? I think it would be worth waiting for Lyncode's solution, maybe they'll have a better way of tackling this.
[21:09] <mdiggory> its not replacement.... you get two Listen 80 and you get a warning....
[21:09] <robint> helix84: That means waiting a year for 4.0
[21:09] <robint> This is available now if we want it
[21:09] <mdiggory> sorry, without knowing what the developer at Lyncode is working on or proposing, I can't comment on that solution
[21:09] <helix84> right, in httpd it's concatenation. i'm all for overriding.
[21:10] <helix84> robint: i know. i just don't want an imperfect solution and do another change of configuration system in the next version.
[21:11] <helix84> robint: this probably covers one use case perfectly, but conflicts with another
[21:11] <tdonohue> I think I'm in agreement with robint on this one. It seems odd to me to continually wait for the "perfect solution" to a problem when we can at least take a small step and do something that's "good enough" for now.
[21:12] <hpottinger> If I like 1208, it's staying in my code base, been looking for a better way than Maven profiles for a while
[21:12] <robint> helix84: I still don't quite understand the problem, would you mind documenting it in Jira ? Thanks
[21:13] <mhwood> So, adopt this "for now" and then discuss everybody's issues, perhaps replace with a more general solution later? (3.1, not 4.0)
[21:13] <mhwood> It sounds to me like this is a good solution to one problem, but others are looking at a different problem?
[21:13] <robint> mhwood: 3.x releases are for bug fixes, not new features
[21:13] <helix84> robint: i'll be glad to, but i already tried to verbosely explain it here. which part i didn't explain well enough?
[21:14] <tdonohue> mhwood -- 3.1 is "bug fix only" release. So, new features would have to wait for 4.0. I'm just saying that we shouldn't immediately reject an piece of code if we have a better "blue sky" idea. Instead, we should look at the current piece of code and determine if it's "good enough" until we can achieve the "perfect solution"
[21:15] <mhwood> Did we lose the distinction between "breaks contracts" (major release) and "new features" (major or minor release)?
[21:15] <helix84> tdonohue: you're right, i'm only one voice. let's just do a vote.
[21:15] <robint> I didn't quite understand why a change to build.properties is more of a problem than a change to dspace.cfg in terms of diff
[21:16] <tdonohue> yes, mhwood. We lost that distinction when we changed numbering schemes. The new scheme is "major.minor". Major = New features/breaks contract, and Minor = bug fixes only
[21:16] <helix84> robint: i assumed build.properties would be in .gitignore
[21:16] <robint> So the problem is that you don't see the changes ?
[21:17] <mdiggory> robint: I think the point is that folks want to avoid putting their config for different environments into the config directory
[21:17] <helix84> robint: I assumed the point is to have means of overriding configuration options, which happens to solve my problem. But the implementation doesn't.
[21:17] <robint> mdiggory: it could be outwith config dir
[21:18] <robint> helix84: but is it worse for you than the current setup ?
[21:18] <helix84> robint: No, it isn't worse. But it _almost_ solves the problem, just a little short of it.
[21:19] <helix84> what I expect and what it doesn't have are 2 things:
[21:19] <robint> So if it doesn't make it worse for you but does make it better for others is that not a good thing on balance ?
[21:20] <helix84> 1) allow any option to be overridden
[21:20] <mdiggory> robint: I guess it depends on who the "others" are ;-)
[21:20] <robint> That is what a vote is for :)
[21:20] <helix84> 2) allow me to have my configuration outside the working directory (in .gitignore or completely outside source dir)
[21:20] <tdonohue> mdiggory: The "others" include robint! Don't you want to help out robint! Come-on!
[21:20] <robint> I'm +1 because its good for me
[21:21] <helix84> s/configuration/overrides/
[21:21] <kompewter> helix84 meant to say: 2) allow me to have my overrides outside the working directory (in .gitignore or completely outside source dir)
[21:21] <hpottinger> if you wanted to version build.properties in a separate repository, you could do so, and just symlink it in to your dspace working copy
[21:21] <mhwood> I'll vote 0.
[21:22] <helix84> hpottinger: You're right. But since it doesn't do 1), I still don't have an empty "git diff".
[21:22] <mdiggory> tdonohue: I know... he's such a great guy....
[21:22] <tdonohue> helix84 -- from my understanding it does have your #2. It only falls down on #1, but you can manually achieve it by adding more "placeholders"/parameters to your existing dspace.cfg file if you want to override more options
[21:23] <robint> I would need to check but I imagine you can specify a file outside your source dir with a full path
[21:23] <helix84> tdonohue: If I add the parameters after checking out the source, it will still show in my diff.
[21:23] <helix84> yes, 2) is probably easily solved by having it outside the source dir
[21:23] <mhwood> I, too, want a clean diff, if I'm developing something to be shared, because I don't want to share local details.
[21:24] <helix84> mhwood: exactly
[21:24] <mdiggory> ok... TBH... this is a bit of overkill. I'd say commit it and see who complains.... this is just a bunch of cat herding...
[21:24] <hpottinger> others.addMember(hpottinger)
[21:24] <mhwood> I think I can just ignore it (after copying the .example) and continue doing what I do, so it's not a problem for me.
[21:25] <helix84> I understand I'm outvoted, I'm just pointing out how it could be improved...
[21:26] <mdiggory> helix84: you can't be outvoted
[21:26] <hpottinger> helix84: I think I understand, your objection is that, while it looks useful, it's not useful enough
[21:26] <robint> helix84: Actually you are not outvoted, any -1 is a veto :)
[21:26] <helix84> oh, i didn't know that
[21:26] <helix84> in that case, i vote 0
[21:27] <tdonohue> Ok, I think we've exhausted this discussion :) Honestly, I think it'd be good for a few to try it out and see if there are major complaints. If not, it sounds like more are seemingly in favor of it.
[21:27] <robint> Community development in practice ! :)
[21:28] <robint> I'll leave the pull request open for a while so feel free to object there or in Jira if anyone encounterss a problem. Thanks.
[21:29] <tdonohue> I think the meeting is officially adjorned for today. I'd *highly* recommend we find ways to start to commit/approve more of the outstanding features via email in the coming weeks. We only have 2 weeks till Feature Freeze.
[21:29] <tdonohue> Oh. I forgot. I'm out of the office next Weds (at a conference). Anyone want to lead the meeting on Weds 8/8 ?
[21:30] <tdonohue> (sorry for the last minute notice on that...slipped my mind till I just looked at my calendar)
[21:30] <robint> tdonohue: Maybe Sands might want to lead but if not I would do it
[21:30] <tdonohue> I'll send a note to dspace-release, and you all can fight over / share the honor of leading the meeting next week :)
[21:31] <mhwood> Must go. Thanks all!
[21:31] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:31] <robint> Me too. Cheers
[21:31] <hpottinger> gotta go too, bye!
[21:31] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:31] * ryscher (ae61f77a@gateway/web/freenode/ip.174.97.247.122) Quit (Quit: Page closed)
[21:31] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:45] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[21:51] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:29] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.