Timestamps are in GMT/BST.
[0:23] * peterdietz (~peterdiet@c-76-111-124-211.hsd1.md.comcast.net) Quit (Quit: peterdietz)
[6:26] -card.freenode.net- *** Looking up your hostname...
[6:26] -card.freenode.net- *** Checking Ident
[6:26] -card.freenode.net- *** Found your hostname
[6:26] -card.freenode.net- *** No Ident response
[6:26] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:26] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:26] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:34] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:00] * peterdietz (~peterdiet@c-76-111-124-211.hsd1.md.comcast.net) has joined #duraspace
[12:12] * peterdietz (~peterdiet@c-76-111-124-211.hsd1.md.comcast.net) Quit (Quit: peterdietz)
[12:16] * peterdietz (~peterdiet@c-76-111-124-211.hsd1.md.comcast.net) has joined #duraspace
[12:22] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[12:23] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:16] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[13:17] * awoods is now known as awoods_vacation
[14:05] * roeland (~roeland@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:06] * roeland (~roeland@85.234.195.109.static.edpnet.net) has left #duraspace
[14:16] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[14:41] * peterdietz (~peterdiet@c-76-111-124-211.hsd1.md.comcast.net) Quit (Quit: peterdietz)
[14:50] * peterdietz (~peterdiet@c-76-111-124-211.hsd1.md.comcast.net) has joined #duraspace
[14:56] * bezoeker (51a580aa@gateway/web/freenode/ip.81.165.128.170) has joined #duraspace
[14:56] * roeland (~roeland@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:58] * bram-atmire (~bram@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:59] * Germanbio (b5a6465c@gateway/web/freenode/ip.181.166.70.92) has joined #duraspace
[14:59] <bram-atmire> Hi
[14:59] <pbecker> hi bram
[14:59] * artlowel (~art@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:01] <tdonohue> Hello all. It's time (15UTC) for our weekly DSpace Developers Meeting. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-07-30
[15:01] <kompewter> [ DevMtg 2014-07-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-07-30
[15:01] <tdonohue> First and foremost, as it's a higher priority for 5.0 (at least for the XMLUI), I know we have a few @mire folks in the room to talk about the Mirage 2 contribution
[15:02] <tdonohue> So, I figured we could start there for today... here's the ticket: DS-2052
[15:02] <kompewter> [ https://jira.duraspace.org/browse/DS-2052 ] - [DS-2052] Mirage 2 Responsive theme for the XMLUI - DuraSpace JIRA
[15:02] <bram-atmire> Thanks Tim
[15:02] <tdonohue> No problem. I'll hand things over to you, bram-atmire
[15:02] <bram-atmire> As part of the Mirage 2 development process I’ve been mainly dealing with communication and our early adopter group.
[15:02] <bram-atmire> I am joined here today by two key members of our team:
[15:03] <bram-atmire> artlowel is Mirage 2’s main design lead
[15:03] <artlowel> Hi!
[15:03] <bram-atmire> and responsible for taking the hard picks in terms of technologies, frameworks etc
[15:03] <tdonohue> welcome, artlowel!
[15:03] <bram-atmire> roeland is our maven wizard who has done several inventive additions to the specific Mirage 2 build process
[15:03] <roeland> Hi
[15:03] <tdonohue> and welcome, roeland!
[15:04] <bram-atmire> The reason why we wanted to bring Mirage 2 to this table today, is because we would like to see the pull request accepted as soon as possible
[15:04] <bram-atmire> the reason is that we have a few other contributions in store
[15:04] <bram-atmire> for which we’d like to provide Mirage 2 UI compatibility
[15:04] <tdonohue> Mirage2 PR is DSPR#587
[15:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/587 ] - [DS-2052] @mire Mirage 2 Contribution by KevinVdV
[15:04] <bram-atmire> and it would be a lot easier if we could develop & finalize them on the current master branch, with mirage 2 included
[15:05] <bram-atmire> so apart from general Q&A on how we approached specific challlenges, we’re mainly looking for questions and criticism to see if we need to change anything to the pull request
[15:05] <bram-atmire> as it currently stands
[15:05] * Muelle (59805377@gateway/web/freenode/ip.89.128.83.119) has joined #duraspace
[15:05] <bram-atmire> prior to its acceptance in the core
[15:06] <bram-atmire> So … feel free to fire away ;)
[15:06] * bill (8654719a@gateway/web/freenode/ip.134.84.113.154) has joined #duraspace
[15:06] * bill is now known as Guest94567
[15:06] <tdonohue> So, as it stands, Mirage2 is it's own "top-level" Maven project, right... at [src]/dspace-mirage2/ ?
[15:06] <bram-atmire> correct!
[15:07] <bram-atmire> we’ve changed this after the feedback on our initial approach to put it under /dspace/modules
[15:07] <tdonohue> I guess the obvious question is... What advantages are there to putting it at the top level, *instead* of embedding under [src]/dspace-xmlui/ somewhere (since it obviously is XMLUI specific)?
[15:08] <tdonohue> One detriment I can see is that it could be confused as being "generic" (XMLUI or JSPUI) if folks see it at the top-level
[15:08] <tdonohue> (which obviously would be a misunderstanding we'd like to avoid)
[15:10] <roeland> The main reason we put it there is to not to bloat the xmlui pom.xml with a feature not all of us want to use initially and which is rather complex.
[15:10] * Bavo (55eac36d@gateway/web/freenode/ip.85.234.195.109) has joined #duraspace
[15:10] * Guest94567 (8654719a@gateway/web/freenode/ip.134.84.113.154) Quit (Client Quit)
[15:11] <tdonohue> roeland: not sure I understand that as a reason... That would imply that it sitting at [src]/dspace-xmlui/ may "bloat" the top-level (i.e. [src]/pom.xml) instead?
[15:11] * wtantzen (8654719a@gateway/web/freenode/ip.134.84.113.154) has joined #duraspace
[15:11] <tdonohue> err..sitting at [src]/dspace-mirage2/ I mean
[15:12] <tdonohue> I.e. it seems like the dspace-mirage2 POM itself should be the one that handles dependencies for Mirage2... Sure, there would likely need to be a custom Maven profile (or similar) in the dspace-xmlui POM, but I don't understand how that would "bloat" it
[15:12] <artlowel> I think the idea is that, if we were to include it in dspace-xmlui, more code in that pom would refer to mirage 2 than to other xmlui stuff
[15:13] <hpottinger> The same stack of tools would be useful for *any* of the theme approaches, yes?
[15:13] <artlowel> not right away ofc, but yes, with some tweaking
[15:14] <peterdietz> oh hi, morning meeting
[15:15] <hpottinger> I think I'm OK with "bloat" in dspace-xmlui, if the tools are generally useful
[15:16] <tdonohue> So, overall, I think Mirage 2 is looking good. But, I'm not yet convinced that it should be a top-level project....I worry about the precedence this begins.
[15:16] <hpottinger> tdonohue++
[15:17] <tdonohue> I.e. I really don't want to see a ton of top-level projects under [src], especially if they are highly dependent on another top-level project
[15:17] <roeland> If you would put a fully built mirage2 into the /dspace-xmlui pom it would also encourage people to edit the generated css files, which is a bad practice. Putting it in the top level, we encourage using the override/overlay mechanism to customize mirage2.
[15:17] <mhwood> That's the way Maven wants to do it: parent-pom, all dependencies one level down.
[15:17] <peterdietz> We've been using the compiled version of mirage2, and keep it in dspace-xmlui/src/main/webapp/themes/Mirage2, we've been pretty happy with it there
[15:18] <artlowel> Thats fine for people running a dspace instance
[15:18] <artlowel> but we don’t want people contributing to dspace to edit compiled files instead of the soure
[15:19] * uhusiano (2948d782@gateway/web/freenode/ip.41.72.215.130) has joined #duraspace
[15:19] <tdonohue> I'm still not sure why XMLUI + Mirage2 cannot be more like how the LNI project is organized...e.g. [src]/dspace-lni/ is the toplevel project, but within it there's a [src]/dspace-lni/dspace-lni-client/ project which is the sample LNI specific client
[15:19] <tdonohue> I.e. why can't we put the *full source* of Mirage 2 at [src]/dspace-xmlui/dspace-mirage2/ ? And just build it from *there* instead?
[15:20] <peterdietz> But we can save a lot of complexity, if we keep both the source/compiled css in the mirage2 theme. i.e. css/file1.sass ... file10.sass, and then you compile those to css/combined.css. Have a big notice at the top of that combined.css file that says edit file1.sass, and run sass --watch
[15:20] <hpottinger> we can just add the generated css to .gitignore...
[15:22] <pbecker> Of course people should edit the source and not the compiled files, but this can be achieved only by knowledge (or documentation) and is not depend where the files are located. If people edit compiled files in dspace-xmlui/... they would do the same in /dspace-mirage2/... Wouldn't they?
[15:22] <peterdietz> (I prefer to have my compiled css in VCS, I don't want a site that we deploy to, to not have CSS lying around).. Sorry if we're bike shedding on location. But Mirage2 is a great contribution, a solid advancement for the user interface
[15:22] <artlowel> as it is now, compiled css is never located in the source folders
[15:22] <artlowel> only in the target folders
[15:22] <artlowel> you can’t accidently commit it
[15:22] <mhwood> Actually dspace-lni-client should move up. It works, but it's bending Maven a little.
[15:23] <tdonohue> mhwood: why is it "bending" Maven?
[15:24] <tdonohue> Maven doesn't much care how many levels of subfolders you have...it just needs to know which ones to build.... In the case of 'dspace-lni-client', it's merely placed at '[src]/dspace-lni/dspace-lni-client' for human purposes...to make it clear that it's a part of the larger project.
[15:24] <mhwood> It's one of those things that Maven expects in the layout. What we do still works but I would not be shocked if if it stopped after some future Maven upgrade.
[15:24] <mhwood> Oh, well, that's a digression.
[15:25] <roeland> @tdonohue that we could indeed do: make a dspace-xmlui module and two submodules dspace-xmlui-webapp and dspace-mirage2.
[15:25] <mhwood> Compiled files should be in a generated-source/something, which ought to be a clue for people looking for what to edit.
[15:27] <bram-atmire> This would imply that that dspace-xmlui in itself will become a container and not a WAR of its own.
[15:27] <tdonohue> roeland & bram-atmire: no, you misunderstand me. You need not make two submodules... Look at how dspace-lni works... [src]/dspace-lni is a WAR project, but [src]/dspace-lni/dspace-lni-client/ is a JAR. They are *both* built by this profile in the main POM: https://github.com/DSpace/DSpace/blob/master/pom.xml#L477
[15:27] <kompewter> [ DSpace/pom.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/pom.xml#L477
[15:27] <peterdietz> ok, I guess we should be dissecting this project too much, but an overview of mirage2-source is that it uses sass to compile the stylesheets, and bower/grunt to manage javascript dependencies, fetching, and minifying
[15:27] <peterdietz> s/should/shouldn't/
[15:27] <kompewter> peterdietz meant to say: ok, I guess we shouldn't be dissecting this project too much, but an overview of mirage2-source is that it uses sass to compile the stylesheets, and bower/grunt to manage javascript dependencies, fetching, and minifying
[15:28] <tdonohue> so, it's possible to keep [src]/dspace-xmlui/ AS-IS...and just place 'dspace-mirage2' under that directory.
[15:28] <roeland> that is the bend mhwood was referring to
[15:29] <peterdietz> By adding mirage2-source to DSpace, how much more complex is a fresh install of DSpace going to be? i.e. does this require that the installation also adds 4 local packages or so?
[15:30] <tdonohue> roeland: ok, I see the point there... just not liking the other options either. hmmm...
[15:30] <bram-atmire> @peterdietz no, we’ve substantially improved the build process, specifically to make installation as easy as possible
[15:30] <bram-atmire> this happens during the overlay process here: https://github.com/atmire/DSpace/blob/mirage2-contribution/dspace/modules/mirage2/pom.xml
[15:30] <kompewter> [ DSpace/dspace/modules/mirage2/pom.xml at mirage2-contribution · atmire/DSpace · GitHub ] - https://github.com/atmire/DSpace/blob/mirage2-contribution/dspace/modules/mirage2/pom.xml
[15:30] <tdonohue> peterdietz: as far as I can tell, Mirage2 doesn't build by default...you have to pass a flag to Maven to enable it to build
[15:31] <roeland> precisely
[15:31] <bram-atmire> There are two modes, a mode that doesn’t require the extra dependencies to be installed locally. Node etc are downloaded and executed by maven
[15:31] <tdonohue> peterdietz: here's the docs on building Mirage2: https://github.com/atmire/DSpace/tree/mirage2-contribution/dspace-mirage2
[15:31] <kompewter> [ DSpace/dspace-mirage2 at mirage2-contribution · atmire/DSpace · GitHub ] - https://github.com/atmire/DSpace/tree/mirage2-contribution/dspace-mirage2
[15:31] <bram-atmire> for developers, who do have the dependencies installed natively, can use the other mode
[15:31] <bram-atmire> where the build assumes that the dependencies are present
[15:32] <bram-atmire> as a result, that build is significantly faster
[15:32] <bram-atmire> after the build
[15:32] <bram-atmire> all that remains to deploy mirage, is the activation of the theme in xmlui.xconf and the aspect
[15:34] <tdonohue> roeland & bram-atmire: perhaps another option regarding "where does the code sit" is to merely rename the toplevel project to [src]/dspace-xmlui-mirage2/ Yea, it's a bit of a mouthful, but at least that makes it clear it is ONLY for XMLUI, plus it groups it alphabetically next to [src]/dspace-xmlui/
[15:34] <bram-atmire> makes sense
[15:34] <roeland> simple. I like it.
[15:35] <peterdietz> okay, so UniversityX that wants to use DSpace5 with mirage2, passes the flag, maven does everything (npm, bower, grunt, sass) to create the compiled theme. If they have xmlui.xconf configured to use this, then they get it
[15:35] <tdonohue> I'd be satisfied with that minor change in name
[15:35] <bram-atmire> peterdietz: yes
[15:36] <peterdietz> How would you feel about also including mirage2-compiled in xmlui/themes/, for an alternative/simpler getting started....
[15:37] <peterdietz> now that I'm thinking about it. Say we made a bug-fix to mirage2-source, we'd have to duplicate that fix into the shipped compiled version. Kind of annoying
[15:37] <bram-atmire> technically that would be possible, but it’s unreadable because of the minification etc. It would also be a burden to keep that in sync
[15:37] <tdonohue> Or, can mirage2-compiled just get pulled in as a Maven dependency via the overlay processes? Does it do that already?
[15:38] <mhwood> Aha, should the stuff to be compiled be a separate dependency? Then you can build your own, or just get the stock from Central?
[15:38] <tdonohue> i.e. You have two options... have mirage2-compiled get pulled in as a Maven dependency (via overlays).... or install all the tools & build it yourself (which is recommended if you really want to tweak)
[15:38] <peterdietz> I would prefer to not have an external thing, for what should be as simple as a theme
[15:39] <peterdietz> i.e. Nobody understood services when they lived outside of DSpace
[15:39] <peterdietz> DSpace's theme of the future shouldn't be so complicated, I hope we figure out the best way forward
[15:40] <tdonohue> peterdietz: Not sure we are talking about the same thing... If you download the "pre-compiled" release of DSpace from SourceForge, you are already pulling down things like pre-compiled WARs from Maven Central.
[15:40] <tdonohue> My question was just whether Mirage2 would be included in that.... Is it possible to *enable* Mirage2 in a "pre-compiled" release of DSpace (downloaded from SourceForage)? Or do you *have* to build from source to use it?
[15:41] <hpottinger> my question (very similar to tdonohue, who types faster) is: how does the current PR (or the name-change-variant previously-discussed) work with overlays?
[15:41] * grahamtriggs (526e8af2@gateway/web/freenode/ip.82.110.138.242) has joined #duraspace
[15:41] * knowledgearc (516b95c4@gateway/web/freenode/ip.81.107.149.196) has joined #duraspace
[15:42] <tdonohue> And if Mirage2 is *not* included in the "pre-compiled" DSpace releases...then that might be an issue here.... or we need to stop shipping "pre-compiled" releases as an option
[15:43] <roeland> If you download the binary release the process remains the same.
[15:43] <tdonohue> If you aren't sure what I'm talking about..."pre-compiled" releases are those that are named dspace-4.2-release.[ext] here: https://sourceforge.net/projects/dspace/files/DSpace%20Stable/4.2/
[15:43] <kompewter> [ DSpace - Browse /DSpace Stable/4.2 at SourceForge.net ] - https://sourceforge.net/projects/dspace/files/DSpace%20Stable/4.2/
[15:43] <bram-atmire> e.g. you can use mvn package -Dmirage2.on=true both on the source and the binary release
[15:43] <artlowel> … and mirage 2 will still need to be built
[15:44] <tdonohue> roeland: Binary releases only include [src]/dspace/ though... so there would be no [src]/dspace-xmlui-mirage2 directory (unless you changed the binary release scripts)
[15:44] <bram-atmire> and that happens through the overlay principle:
[15:44] <bram-atmire> with the corresponding pom sitting here: https://github.com/atmire/DSpace/blob/mirage2-contribution/dspace/modules/mirage2/pom.xml
[15:44] <kompewter> [ DSpace/pom.xml at mirage2-contribution · atmire/DSpace · GitHub ] - https://github.com/atmire/DSpace/blob/mirage2-contribution/dspace/modules/mirage2/pom.xml
[15:46] <peterdietz> I have a question about mirage2 on more practical matters. Say I want to have 3 themes: Faculty-Mirage2, Thesis-Mirage2, and Gallery-Mirage2, in which I've made interesting customizations to each, such that they are distinct in features, and are distinct in colors. Where would one store their customized mirage2 themes?
[15:48] <roeland> that would be in dspace/modules/mirage2/src/main/webapp
[15:50] <tdonohue> peterdietz: mirage2 supports overlays, as roeland notes...just like current XMLUI, etc. So, mirage2 custom themes are similar to how you'd do a current mirage custom theme...except you'd put it under [src]/dspace/modules/mirage2/ instead of [src]/dspace/modules/xmlui/
[15:51] <tdonohue> I do still have possible concerns here about how this affects Releases (i.e. are we releasing Mirage2 to Maven Central? If so, that does change our Release requirements a tad...which is OK, but we'd need to note that). But some of that we might be able to "fix" after the initial PR
[15:51] <bram-atmire> good question peter, just discussing this here
[15:52] <bram-atmire> where it would be easiest to do would depend on whether you alter XSL or not
[15:52] <peterdietz> The target output will make your modules/mirage2/facultyMirage2 benefit from bug-fixes to the mirage2-source base(?)... I'm working part of it ou in my head too
[15:52] <bram-atmire> if it’s only colours, the entry for these specific themes could be part of the grunt build, in order to generate these different color schemes
[15:53] <bram-atmire> with differences in xsl, it may be better to keep them all in separate theme folders
[15:54] <mhwood> Might be best (simplest) to just advise people to always do separate theme folders?
[15:54] <mhwood> Never mind, didn't read well enough.
[15:54] <bram-atmire> I think we’ll have to get back to you with a more easily configurable way to support the usecase for substantially different themes in the same repo
[15:55] <tdonohue> by "separate theme folders" are you meaning that you'd copy [src]/dspace/modules/mirage2/ into a [src]/dspace/modules/faculty-mirage2/ folder?
[15:55] <tdonohue> (and make minor POM tweaks, obviously)
[15:55] * grahamtriggs (526e8af2@gateway/web/freenode/ip.82.110.138.242) Quit (Quit: Page closed)
[15:55] <artlowel> yes
[15:56] <bram-atmire> we’ll ensure that making tweaks to a pom is NOT a requirement for deploying different themes on the same repo.
[15:57] <tdonohue> sounds good
[15:57] <artlowel> different mirage2 based themes
[15:57] * tdonohue notes I unfortunately have to leave in to another mtg in ~3 minutes
[15:57] <peterdietz> with mirage1, (or in our situation mirage2-compiled) living in webapps/xmlui/themes/...... Our child themes can xsl include mirage2, and then their unique xsl's css / js / etc just happens
[15:58] <bram-atmire> so small recap of the TODO’s we got out of this:
[15:58] <tdonohue> I feel like we've made some "headway" here...but there seems to still be questions / to-dos
[15:58] <bram-atmire> folder will be renamed to dspace-xmlui-mirage2
[15:58] <bram-atmire> and we’ll ensure that the usecase for deploying multiple themes easily is better supported
[15:58] <hpottinger> I'm just now getting the hang of the xslt include trick that peterdietz mentiosn above
[15:59] <tdonohue> RE: "folder renaming"... I'd suggest [src]/dspace-xmlui-mirage2 AND [src]/dspace/modules/xmlui-mirage2 (for consistency, both should be changed)
[15:59] <bram-atmire> tdonohue: confirmed
[15:59] <bram-atmire> xsl imports from existing themes are still possible
[16:00] <peterdietz> Another confirmation from today is that xmlui remains tricky
[16:00] <bram-atmire> it’s only for those files that you change for which we would suggest separate folders.
[16:01] <bram-atmire> peterdietz: agreed, once this finally gets in, let’s break down the back end and put something else in place in the next years ;)
[16:02] <pbecker> peterdietz, bram +1
[16:02] <tdonohue> I unfortunately need to head out now (to another meeting). Do we need to have a followup Developer Mtg conversation on mirage2? e.g. Next week? In two weeks?
[16:02] <bram-atmire> the way it’s setup now, mirage 2 if it would be contributed, doesn’t disturb any other features
[16:02] <bram-atmire> so it would be great that if we make these two changes
[16:02] <bram-atmire> that we could get the PR committed
[16:02] <bram-atmire> and work the rest out with other bugfix PR's
[16:03] * uhusiano (2948d782@gateway/web/freenode/ip.41.72.215.130) Quit (Quit: Page closed)
[16:03] <tdonohue> I'd like to also see us finalize things quickly to help us all out, and help us fix any other minor things that pop up along the way
[16:03] <bram-atmire> any committer who objects to that
[16:03] <mhwood> Yes, it seems not invasive, so let's get it in quickly and start picking it apart. :-)
[16:03] <tdonohue> I don't have objections...but we'd like need to vote on that
[16:04] * Germanbio (b5a6465c@gateway/web/freenode/ip.181.166.70.92) Quit (Quit: Page closed)
[16:04] <bram-atmire> we’ll send an email for the vote as soon as we get the changes in place
[16:04] <tdonohue> sounds good
[16:04] <hpottinger> Would 3 +1s on the PR suffice?
[16:04] <tdonohue> I'm off to another meeting, so I have to close this one up for now. Feel free to continue discussions here... I'll catchup later
[16:05] <bram-atmire> mdiggory, bbosman, kevinvdv, myself = 4 ;) let’s make it at least 1 non @mire vote ;)
[16:05] <bram-atmire> thanks for all of your questions and input - this was great & motivating
[16:05] <hpottinger> I'm pretty sure @mire doesn't want to go there :-)
[16:06] <hpottinger> if people can hang out, I have a question on DS-1775
[16:06] <kompewter> [ https://jira.duraspace.org/browse/DS-1775 ] - [DS-1775] Increase robustness of SolrServiceImpl date format guessing - DuraSpace JIRA
[16:06] <peterdietz> My main objections today are more about making mirage2 as universally useful. As opposed to difficult to configure thing
[16:07] <mhwood> Thank you all from @mire for coming to present and have your work kicked around. :-)
[16:07] <peterdietz> Now we're officially in the after meeting. Yeah, good discussion today, thanks all for coming.
[16:07] <hpottinger> Are we OK with the concept of making the handling of date format recognition more "natural language friendly"?
[16:08] <peterdietz> I've been working on trying to make DynamicConfiguration work. And I've recently PR'ed Batch Import through XMLUI: https://github.com/DSpace/DSpace/pull/591
[16:08] <kompewter> [ DS-1641 Batch ItemImport from XMLUI by peterdietz · Pull Request #591 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/591
[16:08] <peterdietz> ohh, right, Hardy's SOLR/date things
[16:08] * artlowel (~art@85.234.195.109.static.edpnet.net) has left #duraspace
[16:08] <mhwood> Dates are such a mess, that at first glance this seems sensible.
[16:09] <bram-atmire> @peterdietz: universally useful in terms of theming would be that we finally get around offering some basic color & images configuration in the admin UI, instead of keeping it in the area of development
[16:09] <bram-atmire> thanks for picking the solr date thing up hardy
[16:09] <hpottinger> a +1 from mhwood is good enough for me, as long as my boss OKs the time expenditure, I'm tackling DS-1775
[16:09] <kompewter> [ https://jira.duraspace.org/browse/DS-1775 ] - [DS-1775] Increase robustness of SolrServiceImpl date format guessing - DuraSpace JIRA
[16:11] <hpottinger> peterdietz: post a link to your demo video, it's awesome
[16:11] <bram-atmire> can’t exactly remember what problem I came acros that make me post this
[16:11] <bram-atmire> I think it was a report on the mailing list
[16:11] <peterdietz> The YouTube video is at the last link in the description of PR#591
[16:12] <peterdietz> ohh yeah. I wrote BatchImportUI in the car, during a 7 hour drive. I had a very tolerant driver
[16:12] <hpottinger> bram-atmire: if you rebuild Discovery's index, and it takes longer than you think it ought to, you might look at the dspace.log file, and if your metadata has any "funky" date formats, you'll see those messages.
[16:13] <bram-atmire> it was originally this problem: http://dspace.2283337.n4.nabble.com/Fwd-SOLR-Discovery-Date-Parsing-td4668812.html
[16:13] <kompewter> [ DSpace - Tech - Fwd: SOLR/Discovery Date Parsing ] - http://dspace.2283337.n4.nabble.com/Fwd-SOLR-Discovery-Date-Parsing-td4668812.html
[16:13] <pbecker> have to leave, good bye!
[16:13] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[16:15] <hpottinger> peterdietz: re: dynamic configuration, are you starting with Lyncode's existing work?
[16:17] <peterdietz> yeah, I was looking at lyncode's stuff as my starting point. His work essentially provides an alternative to configurationService that allows you to set further values, and the eventually a properties.save()
[16:17] * Bavo (55eac36d@gateway/web/freenode/ip.85.234.195.109) Quit (Ping timeout: 246 seconds)
[16:17] <peterdietz> But there's nothing that actually uses that, so I have no idea if it is working. I've done some changes to it, to spring wire it up, and resolve some issues.
[16:18] <peterdietz> My goal is part of this AdminFriendly idea, where perhaps an admin can actually change some things about their site from the UI.
[16:19] <mhwood> See also DS-1390. We need to get ConfigurationManager and ConfigurationService on the same page.
[16:19] <kompewter> [ https://jira.duraspace.org/browse/DS-1390 ] - [DS-1390] DSpace has too many configurations - DuraSpace JIRA
[16:20] <hpottinger> peterdietz: wold you want to set this up as a "feature branch" like we did with REST-API (I think we did, anyway)?
[16:20] * bezoeker (51a580aa@gateway/web/freenode/ip.81.165.128.170) Quit (Quit: Page closed)
[16:22] * Muelle (59805377@gateway/web/freenode/ip.89.128.83.119) Quit (Quit: Page closed)
[16:23] * roeland (~roeland@85.234.195.109.static.edpnet.net) Quit (Quit: roeland)
[16:24] <peterdietz> I'm actually hoping that getting some wins in dynamic config can be found easily (days to week). I don't think I'll be able to stay on this project if it snowballs to a month+ project.
[16:26] <hpottinger> there's a lot of interest in this, so, maybe more hands will help?
[16:28] <peterdietz> Anyone who is a spring/magic expert might be able to help. I'm not at the point to where I'm persisting changes, just seeing if dspace-running can handle setProperty(key, value)
[16:28] <mhwood> I want to see 1390 finished and I think that will smooth the path for this.
[16:29] <mhwood> Dunno if I'm a Spring *expert* but I'm willing to look at Spring stuff.
[16:30] <hpottinger> I'm tempted to say let's feature branch this, just to telegraph intentions
[16:30] <hpottinger> and hooray if it encourages participation
[16:31] <mhwood> I hope that the branch can produce intermediate development points that can be merged fairly frequently, so it doesn't grow too far away from master as some have.
[16:49] <bram-atmire> go to go, have a nice evening/day
[16:52] * bram-atmire (~bram@85.234.195.109.static.edpnet.net) Quit (Quit: bram-atmire)
[16:57] * jm____ (5f679136@gateway/web/freenode/ip.95.103.145.54) has joined #duraspace
[17:11] * peterdietz (~peterdiet@c-76-111-124-211.hsd1.md.comcast.net) Quit (Ping timeout: 245 seconds)
[18:12] * Miusen (c837d0b2@gateway/web/freenode/ip.200.55.208.178) has joined #duraspace
[18:13] * wtantzen (8654719a@gateway/web/freenode/ip.134.84.113.154) Quit (Ping timeout: 246 seconds)
[18:45] * Miusen_ (c837d0b2@gateway/web/freenode/ip.200.55.208.178) has joined #duraspace
[18:47] * jm____ (5f679136@gateway/web/freenode/ip.95.103.145.54) Quit (Quit: Page closed)
[19:32] * Miusen (c837d0b2@gateway/web/freenode/ip.200.55.208.178) Quit (Quit: Page closed)
[20:15] * mxrtinez (~quassel@200.16.119.251) has joined #duraspace
[20:17] * knowledgearc (516b95c4@gateway/web/freenode/ip.81.107.149.196) Quit (Ping timeout: 246 seconds)
[20:58] * mxrtinez (~quassel@200.16.119.251) Quit (Remote host closed the connection)
[21:08] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:01] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[22:02] * Miusen_ (c837d0b2@gateway/web/freenode/ip.200.55.208.178) Quit (Ping timeout: 246 seconds)
[22:13] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.