Timestamps are in GMT/BST.
[2:14] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[2:14] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[2:14] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[2:53] * lyncode (~DSpace@bl23-37-160.dsl.telepac.pt) Quit (Quit: lyncode)
[4:49] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[5:04] * eddies (~eddies@bb219-74-181-215.singnet.com.sg) has joined #duraspace
[5:04] * eddies (~eddies@bb219-74-181-215.singnet.com.sg) Quit (Changing host)
[5:04] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[5:07] * eddies (~eddies@unaffiliated/eddies) Quit (Client Quit)
[5:09] * eddies (~eddies@bb219-74-181-215.singnet.com.sg) has joined #duraspace
[5:09] * eddies (~eddies@bb219-74-181-215.singnet.com.sg) Quit (Changing host)
[5:09] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:27] -asimov.freenode.net- *** Looking up your hostname...
[6:27] -asimov.freenode.net- *** Checking Ident
[6:27] -asimov.freenode.net- *** Found your hostname
[6:27] -asimov.freenode.net- *** No Ident response
[6:28] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:28] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:28] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:44] * lyncode (~DSpace@bl23-37-160.dsl.telepac.pt) has joined #duraspace
[8:27] * lyncode (~DSpace@bl23-37-160.dsl.telepac.pt) Quit (Quit: lyncode)
[8:51] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) has joined #duraspace
[10:29] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[10:46] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[10:46] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[10:46] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[11:32] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) Quit (Quit: lyncode)
[11:55] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:49] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) has joined #duraspace
[13:23] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[16:46] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[16:59] * Jose__ (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has joined #duraspace
[17:01] <Jose__> Hey, Tim I'm taking some time to day to look at some of the xslt in Mirage and get a better understanding and I have some questions. As you know I'm pretty new with xslt, so I'm wondering what the purpose of the priorty parameter in templates. It seems like the template with the highest priority will always be called. So why bother with them?
[17:03] * tdonohue notes my Office Hours starts now: https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[17:03] <tdonohue> Hi Jose__ -- Those priority params just ensure that if a bit of XML matches *multiple* XSLT templates, then the one with the highest priority "wins".
[17:03] <tdonohue> Is that what you are asking about?
[17:05] <Jose__> Yes that is my question, but how could one with a low priority ever win over one with a higher priority?
[17:07] <tdonohue> you never have two *exact same* templates with different priorities (i.e. the "match" param will never be identical across any two templates). If you did, then you are correct, the lower priority one would never be called.
[17:08] <tdonohue> The "priority" setting is just there to ensure that if a bit of XML matches against two different templates (with two different "match" params), then it will use the one designated as higher priority
[17:08] <tdonohue> does that make more sense?
[17:10] <Jose__> Yes, so typical matches would be something like /a/b/c with priority say 1, and /a/b with priority 5, so the one with /a/b would be executed, right?
[17:11] <tdonohue> essentially yea..but it depends on what the XML structure is. Here, let me explain with a basic example from XMLUI
[17:13] <tdonohue> here's a basic example from dri2xhtml/structural.xsl... in that file there are a few templates that deal with "<dri:row>" section of DRI XML..>Here's just two of them:
[17:14] <tdonohue> There's the generic template matching "dri:row" with a priority of '1':
[17:14] <tdonohue> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/structural.xsl#L919
[17:14] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/structural.xsl at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/structural.xsl#L919
[17:14] <tdonohue> Then, there's a more specific template matching "dri:row[@role='header']" with a priority of "2":
[17:14] <tdonohue> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/structural.xsl#L885
[17:14] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/structural.xsl at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/structural.xsl#L885
[17:15] <tdonohue> If your XML comes in with a section that is <dri:row role="header"> inside it, it will actually match *both* of these templates (as it's both a valid "<dri:row>" tag and one that has the "role=header" attribute)
[17:15] <tdonohue> So, in this scenario, it looks at the priorities, and then uses the template with the *higher* priority
[17:16] <tdonohue> i.e. If your XML has <dri:row role="header"> it uses the template matching "dri:row[@role='header']", *because* it has a higher priority than the other matching template.
[17:17] <tdonohue> However, if your XML just has a section <dri:row role="somethingelse"> it will only match *one* of those templates...so, it ends up using the template that just has a priority of '1' (the first template listed above)
[17:19] <tdonohue> not sure if that helps explain it better or not. But, as you can see, the template that is used is based on the XML input, and then if *multiple templates* are valid for that input, only the higher priority one is used
[17:19] <mhwood> Wouldn't the template specifying role='header' be a more-specific match, though, and win anyway?
[17:19] <Jose__> Got it! That makes it clear. I think I was getting stuck thinking that it would always use the template with the closest match.
[17:20] <tdonohue> mhwood -- you could be right about that, this may be a "bad example" from me. But, the general concept of how the "priority" comes into play is correct.
[17:22] <tdonohue> To be honest, a lot of times in the XMLUI I'm not entirely sure the "priority" settings are necessary (I.e. the appropriate template would be chosen regardless of priority settings)
[17:22] <Jose__> So you have a huntch that if we got rid of the priority param, nothing would change.
[17:22] <mhwood> Yes, priprity is the tiebreaker. I'm trying to find precise rules for match specificity, but...Tidwell's _XSLT_ is a fine example of how indexing is becoming a lost art....
[17:23] <tdonohue> Correct, Jose__ -- I would suspect that in many cases, if you removed the priority param, you'd see no change. But, mhwood is correct, it's there essentially as a "tiebreaker". If two templates "tie", then the higher priority wins
[17:24] <Jose__> It seems then that priority might be used as debugging tool in general.
[17:27] <tdonohue> Here's a decent resource on how XSLT templates get processed (see the section on "Conflict Resolution for Template Rules" which also talks about setting "priority" attributes): http://lenzconsulting.com/how-xslt-works/
[17:27] <kompewter> [ How XSLT Works — Lenz Consulting Group, Inc. ] - http://lenzconsulting.com/how-xslt-works/
[17:28] <tdonohue> That resource also notes that certain types of templates get certain "default" priority settings...which is kinda what mhwood was getting at -- that some more specific templates automatically are given default higher priorities
[17:29] <mhwood> Here it is in the standard: http://www.w3.org/TR/xslt20/#conflict
[17:29] <kompewter> [ XSL Transformations (XSLT) Version 2.0 ] - http://www.w3.org/TR/xslt20/#conflict
[17:32] <Jose__> lots of things to remember with the rules. I think it would make it more clear not to use the priority param.
[17:32] <tdonohue> yea, it could be -- or at least explain why it is necessary in the comments of the XSLT.
[17:33] <tdonohue> I honestly think those priority params were just in Manakin from the beginning, and no one ever bothered to go through and see which ones are actually still necessary
[17:34] <Jose__> Ok. I have another question, good to move on?
[17:34] <tdonohue> sure, go ahead
[17:36] <Jose__> In the item display I want to make a distinction between the item handle and the other identifier.uri values. I think I'm going to write some xslt with regular expressions to do this. I don't like the idea, but I don't want to use a new dc value, it would affect things like the oai. What do you think?
[17:38] * helix84 (a@195.113.97.174) has joined #duraspace
[17:41] <tdonohue> Jose__ : So, you have multiple different identifiers all stored in dc.identifier.uri, and you want the Handle to somehow appear different (e.g. different style or something)? Am I understanding right?
[17:44] <Jose__> Yes, I want all uris to look like this: "URI: what ever", and then right below it "Handle: our_item_handle". We would never show the handle in the URI: line, just in the Handle:. Right now all uris are show in the URI: line in Mirage.
[17:49] <tdonohue> for that, you might need to just process each of the "identifier.uri" fields (in an <xsl:for-each> or similar) and just display the one beginning with "http://hdl.handle.net" differently than the others.
[17:51] <tdonohue> this would likely be in the "itemSummaryView-DIM-fields" template (which already has some similar <xsl:for-each> statements to display identifier.uri fields): https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/DIM-Handler.xsl#L601
[17:51] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/DIM-Handler.xsl at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml/DIM-Handler.xsl#L601
[17:52] <tdonohue> The only other thing I can think of doing, is actually displaying the Handle near the top of the page (by pulling it out of the <mets:METS @ID> attribute, where it also exists), and then change the "identifier.uri" <xsl:for-each> so that it skips the one beginning with "http://hdl.handle.net"
[17:54] <Jose__> Is there some regular expression examples in in Dspace for xslt. How do I say begginning with "http:..." in xslt?
[17:56] <mhwood> ^http://hdl\.handle\.net
[17:57] <tdonohue> hmm...rusty on my XSLT/XPath..but, I you could just do something like: <xsl:if test="contains($uri, 'hdl.handle.net')"> ... where $uri is an <xsl:variable> corresponding to the value of indentifier.uri
[17:58] <Jose__> Perfect. It now seems so simple.
[17:59] * lyncode (~DSpace@a89-155-3-84.cpe.netcabo.pt) Quit (Quit: lyncode)
[17:59] <tdonohue> it looks like there's some examples of using <xsl:if> with "contains()" in the structural.xsl
[17:59] <mhwood> See also starts-with()
[17:59] <tdonohue> aha -- yes, "starts-with()" is probably even better. I told you my XSLT/XPath is rusty :)
[18:00] <tdonohue> there's several examples of using "starts-with()" in structural.xsl as well.
[18:01] <Jose__> Ok, this has been very helpful. I wonder if I can keep manipulating the time with xslt question. Today is my day to conquer that monster.
[18:03] <tdonohue> You are welcome. best of luck on your XSLT work. let us know if you have more questions.
[18:05] <Jose__> I'm looking at item-view.xsl in Mirage. I wonder if you could get git url so I can talk about it using line numbers, Tim.
[18:06] <tdonohue> Here it is in GitHub: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/Mirage/lib/xsl/aspect/artifactbrowser/item-view.xsl
[18:06] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/Mirage/lib/xsl/aspect/artifactbrowser/item-view.xsl at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/Mirage/lib/xsl/aspect/artifactbrowser/item-view.xsl
[18:06] <tdonohue> (FYI you can actually link directly to line #'s in GitHub...just go to that Line Number & click on it)
[18:11] <Jose__> Great. Look at line 40. If I comment that line out. I don't see the short display of the item - as expected. But when I put it back in, and then comment the template in line 80, I see the short display but without the css being applied to it. Why? I thought line 40 called line 80?
[18:13] <tdonohue> The <apply-templates> in line 40 does "call" the template in line 80. However, if you comment out the template in line 80, The <apply-templates> on line 40 is still run. By default, if there are no matching templates, XSLT tends to just output the XML content as plain text (IIRC). So, that's likely why you still see output (but without CSS)
[18:14] <tdonohue> So, the only way to get rid of that section altogether is to comment out the <apply-templates>.
[18:15] <helix84> Jose__: tdonohue is almost right
[18:15] <tdonohue> (that's the story of my life = "almost right") Definitely feel free to correct me! :)
[18:16] <helix84> maybe you know that Mirage is based on dri2xhtml-alt, which is a skeleton template, basically a reorganized version of dri2xhtml
[18:16] <helix84> Mirage works by defining some templates, overriding some templates from dri2xhtml-alt and leaving the rest up to dri2xhtml-alt
[18:17] <helix84> this is exactly the case when it falls back to a template defined in dri2xhtml-alt
[18:17] <tdonohue> oh yea..I see where helix84 is going. He's right. it's using the default template in dri2xhtml-alt defined here: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml-alt/aspect/artifactbrowser/item-view.xsl#L80
[18:17] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml-alt/aspect/artifactbrowser/item-view.xsl at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml-alt/aspect/artifactbrowser/item-view.xsl#L80
[18:17] * helix84 will have to reconnect, his IRC client is going bonkers
[18:17] <helix84> brb
[18:17] * helix84 (a@195.113.97.174) has left #duraspace
[18:18] * helix84 (a@195.113.97.174) has joined #duraspace
[18:18] * helix84 (a@195.113.97.174) Quit (Read error: Connection reset by peer)
[18:19] <tdonohue> So, when you comment out the template on line #80 of Mirage's item-view.xsl, then XMLUI falls back to using the default template on line #80 of *dri2xhtml-alt's* item-view.xsl
[18:20] <tdonohue> (As helix84 stated, the reason this happens is that Mirage is an extension of the 'dri2xhtml-alt' base theme -- it just overrides a few templates in dri2xhtml-alt to apply some custom Mirage themes/styles)
[18:20] * helix84 (a@195.113.97.174) has joined #duraspace
[18:21] <Jose__> I see now. So if I comment both out ( Mirage and alt ), then would I see something? I'll try it and let you know.
[18:22] <helix84> more like see nothing ;)
[18:22] <tdonohue> Jose__ in general the *better* thing to comment out is the <apply-templates> call. Without a corresponding <apply-templates>, the <templates> will (should) never be called in the first place.
[18:23] <helix84> if you comment both out, there is simply nothing to process that part of DRI, so that part of HTML is not generated
[18:23] <tdonohue> If the <apply-templates> call is still there (but you comment out a template), it's possible that <apply-templates> call will match a different template, in which case something may still be displayed
[18:23] <mhwood> Won't the default templates come into play? To make input disappear I always have to match it.
[18:24] <helix84> alternatively, you can define your own empty template matching the same xpath
[18:24] * lyncode (~DSpace@bl23-37-160.dsl.telepac.pt) has joined #duraspace
[18:24] <helix84> i find that a much cleaner solution than commenting out apply-templates, which could have unintended side-effects
[18:25] <helix84> so in your theme which imports Mirage, define a template like this:
[18:25] <helix84> <xsl:template match="dim:dim" mode="itemSummaryView-DIM">
[18:25] <helix84> </xsl:template>
[18:25] <tdonohue> yea, creating an empty <template> (with the same 'match') would likely be the best route -- that ensures nothing else strange will happen
[18:25] <helix84> this one will override the one from Mirage, just like not the one from Mirage overrides the dri2xhtml-alt's one
[18:27] <helix84> btw this is a FAQ on dspace-tech: how do I remove [search field, menu block, whatever] from my homepage?
[18:29] <tdonohue> Seems like something worth documenting somewhere then -- I recall mention of an "XSLT / Theme Snippets" or "Cookbook" at one point. It would be nice to track some of these useful tips & FAQs
[18:29] <helix84> the solution os often easy: look at the DRI, find that item and take look at its attibutes. if it has an attribute that uniquely identifies it (usually @ID or @n), define an empty template matching it
[18:29] <helix84> tdonohue: definitely. there's just so much on my plate now and I have to prioritize.
[18:30] <tdonohue> oh, yea, I agree helix84 :) I actually wasn't trying to imply that you should do it. I was just mentioning this "out loud" on a logged channel in case anyone here felt they'd like to start such an area on the Wiki.
[18:31] <helix84> Wnce I will. But feel free to beat me to it (anyone).
[18:31] <helix84> s/^W/O/
[18:31] <kompewter> helix84 meant to say: Once I will. But feel free to beat me to it (anyone).
[18:36] <helix84> seems like we scared Jose away a while ago :)
[18:37] <tdonohue> Yea, Jose__ let us know if this makes sense or is utterly confusing. :) I know we talked about a lot above. The *BEST* solution though would be to do what helix84 mentioned -- create an empty copy of that template (or just comment out the *contents* of the template, leaving the opening/closing <template> tags as-is)
[18:37] <Jose__> Oh, no.I have one last question since I'm getting so much good information are you up for the challenge?
[18:37] * vtkeithg (~vtkeithg@2001:468:c80:a103:29ff:e63:1f7b:2540) has joined #duraspace
[18:37] <tdonohue> I'm still here...feel free
[18:39] <helix84> shoot
[18:39] <Jose__> Look at line 141: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml-alt/aspect/artifactbrowser/item-view.xsl#L141 I should be looking at the mets xml as the input for this right?
[18:39] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml-alt/aspect/artifactbrowser/item-view.xsl at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml-alt/aspect/artifactbrowser/item-view.xsl#L141
[18:40] <helix84> yes, that's why the template has match="dim:dim"
[18:40] <tdonohue> correct, anything having to do with "dim:*" is in the METS
[18:40] <Jose__> Sometimes I get confused if the xml to look at is the DRI or the XML, those are the only options right and dim:dim means mets and dri is the other, right?
[18:41] <helix84> (actually, the template which calls it)
[18:41] <helix84> yes, i think those are the only two used out-of-the-box
[18:42] <helix84> but take a look at the attributes of xsl:stylesheet to see the complete list of used namespaces (these don't have to be separate documents)
[18:42] <helix84> you can have multiple namespaces within one XML document
[18:43] <helix84> e.g. if you take a look at this METS document http://demo.dspace.org/xmlui/metadata/handle/10673/3/mets.xml
[18:44] <helix84> you can see both mets: and dim: namespaces there
[18:45] <helix84> you can search for the document() call in all XSL files to see which files are processed apart from DRI
[18:45] <helix84> makes sense?
[18:46] <tdonohue> Jose__ : Generally speaking, templates having to do with DRI will reference "dri:*" or "i18n:*". DRI only includes page layout sort of info. Whereas *anything* having to do with Metadata or Files is in the METS Document, and generally is prefixed with "mets:*" or "dim:*", as by default XMLUI generates METS documents that contain "DIM" metadata within them
[18:47] <tdonohue> (That all being said, what helix84 says above is also true)
[18:48] <Jose__> Yes. I accidentally called a mets file for the collection instead of an item and then that xpath did not make sense. It seems like magic the way the xslt know what xml file to look at. I know it's based on the path. I guess all the xml files are available and then it just looks for possible path matches, right?
[18:49] <helix84> the magic is in the namespaces the template matches
[18:49] <tdonohue> It's actually not "magic". As helix84 mentions above, the XSLT actually loads the proper METS XML file via a call to "document()".
[18:49] <helix84> if it matches dim:dim, that's where the relative xpath starts
[18:50] <helix84> the real fun starts when you realize that you can use this to your advantage
[18:51] <helix84> if you have some external web services which return XML, you can easily call them from XMLUI and process their output (display parts of it)
[18:51] <Jose__> Of course, it's not magic, I just meant hard to follow, but now becoming more clear.
[18:52] <lyncode> hi
[18:52] <helix84> welcome lyncode
[18:52] <lyncode> thanks helix, sorry i was reading your conversation
[18:52] <tdonohue> Yea, here's an example from Mirage -- it's utils.xsl loads the METS document ($externalMetadataURL variable) and starts the processing of the "summaryList" templates: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/Mirage/lib/xsl/core/utils.xsl#L63
[18:53] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/Mirage/lib/xsl/core/utils.xsl at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/Mirage/lib/xsl/core/utils.xsl#L63
[18:53] <helix84> the meeting will start soon, but the first half-hour will be just Jira review
[18:53] <mhwood> "Soon" is an hour and seven minutes from now, I think.
[18:53] <tdonohue> Actually the DSpace Developers Mtg isn't for another hour...it starts at 20:00 UTC. Currently it's 18:53 UTC
[18:53] <helix84> lyncode: this is a public channel, feel free to read and reply :) it's also logged: http://irclogs.duraspace.org/
[18:54] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/
[18:54] <helix84> right, thanks :)
[18:54] <tdonohue> But, lyncode you are welcome to take part in this discussion or ask questions. Currently, this is the "DSpace Office Hours": https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[18:54] <kompewter> [ DSpace Office Hours - Tim Donohue - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[18:55] <helix84> lyncode: I'm very eager to see your code
[18:55] <lyncode> :)
[18:55] <lyncode> i've a simple question, although powerful don't you think XMLUI could requires non so common expertise?
[18:56] <helix84> i think it's easy for people familiar with html
[18:56] <helix84> it's easy because you can modify the XSL, reload the page and see the results
[18:57] <helix84> of course, you should start with something simpler then the moloch XMLUI is
[18:57] <helix84> I learned it mostly using Xerxes portal, which is written very cleanly
[18:58] <helix84> it gives you all the data in its equivalent of DRI and so you can transform it any way you like
[18:59] <helix84> in DSpace, DRI doesn't give you all the information, some parts are given to different pages (URL paths) based on aspects
[18:59] <lyncode> yes, i've already made a xml theme
[18:59] <lyncode> but i've contact with some dspace administrators
[19:00] <lyncode> they say that xmlui could be powerful, but it requires some specific knowledge
[19:02] <lyncode> in other hand they have jsp, and some IDEs that make changes simple
[19:03] <helix84> that's why you developed the new Spring-based interface?
[19:03] <lyncode> no only
[19:03] <lyncode> not*
[19:03] <helix84> well the nice thing about DSpace is that you have so many options, like the choice of interfaces and APIs
[19:05] <lyncode> the reason of producing a new interface (spring based) was mainly because of the add-in possibility
[19:07] <lyncode> one jar could contain the interface and all the logic. So basically, one just need to upload an artifact
[19:07] <lyncode> to have a completely new functionality
[19:08] <helix84> I think I'll understand after I see it
[19:10] <lyncode> it's almost like wordpress/drupal plugin system
[19:45] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:45] * ryscher (98033b4c@gateway/web/freenode/ip.152.3.59.76) has joined #duraspace
[19:52] * KevinVdV (~kevin@d54C154B1.access.telenet.be) has joined #duraspace
[19:52] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:57] * sands (~sandsfish@18.189.31.239) has joined #duraspace
[19:58] <tdonohue> Hi all, our DSpace Devel Mtg starts here in a few minutes -- agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-20
[19:58] <kompewter> [ DevMtg 2012-06-20 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-20
[20:00] <tdonohue> Hi all, looks like we have quite a big group today, which is great!
[20:00] <tdonohue> We'll start off with some JIRA reviews: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1048+ORDER+BY+key+ASC
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-1048 ] - [#DS-1048] superfluous warning in dspace.log - DuraSpace JIRA
[20:00] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1048+ORDER+BY+key+ASC
[20:00] <tdonohue> starting with DS-1048
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-1048 ] - [#DS-1048] superfluous warning in dspace.log - DuraSpace JIRA
[20:01] * Jose__ (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) Quit (Quit: Page closed)
[20:01] <tdonohue> Oh wait..that was just closed...skip that one
[20:01] <tdonohue> DS-1053 is the first one
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1053 ] - [#DS-1053] Problem with choice presentation of type "select" - DuraSpace JIRA
[20:02] <tdonohue> this looks like a config question that should have been rerouted to dspace-tech
[20:04] <tdonohue> so, we'll just skip that & post a comment to move to dspace-tech -- but, if anyone knows the answer, feel free to let them know (I do not, offhand)
[20:04] * richardrodgers (~richardro@18.111.19.59) has joined #duraspace
[20:04] <tdonohue> I'm skipping over DS-1054, as helix84 said it's related to a larger issue / discussion (and is listed later in our agenda)...
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1054 ] - [#DS-1054] message catalog for ru_RU locale - DuraSpace JIRA
[20:04] <tdonohue> Next up is DS-1059
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1059 ] - [#DS-1059] Statistics utilities should be filters - DuraSpace JIRA
[20:05] <tdonohue> mhwood, do you need any support on this or feedback?
[20:05] <mhwood> No, just this nudge to get it moving, since nobody has any negative comments.
[20:05] <tdonohue> It sounds like a great idea to me (haven't looked at the code though)
[20:06] <tdonohue> ok, we'll keep moving along then to the next ticket, DS-1061
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-1061 ] - [#DS-1061] Filenames and BitstreamFormat detection break on filenames with equal signs in them - DuraSpace JIRA
[20:06] <helix84> +1 to the idea, although I haven't seen the code
[20:06] <sands> same.
[20:07] * tdonohue notes last two comments were for Ds-1059 (just for future clarity)
[20:07] <mhwood> 1061 sounds like a bug to me, but that's another part of the code I'm not so familiar with.
[20:07] <mdiggory> I am amicable to better handling of the logs in 1061
[20:08] <mdiggory> sorry now I'm creating confusion... I meant 1059
[20:08] <tdonohue> Yea, DS-1061 doesn't sound like fun. I hate having to dig into Cocoon bugs
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1061 ] - [#DS-1061] Filenames and BitstreamFormat detection break on filenames with equal signs in them - DuraSpace JIRA
[20:09] <mdiggory> for 1059, it would also be nice if the calculated Solr records were written to disk rather than having to retroll the original logs if the solr core needs to be restored.
[20:09] <tdonohue> Anyone have any leads/ideas on Ds-1061 (or anyone willing to investigate if Cocoon has patched this themselves)
[20:09] <sands> have we heard back from the cocoon folks on whether they plan on cutting another release soon?
[20:10] <sands> right.
[20:10] <hpottinger> I've been trolling their mail list, they're making noises about releasing *something*
[20:10] <KevinVdV> I'm willing to take the cocoon issue (IF I can find the time)
[20:10] <mdiggory> it would be nice to see file upload standardized across webapps using something like Spring multipart file upload support
[20:11] <mdiggory> which is based on Apache Commons File Upload
[20:11] <tdonohue> Ok, assign Ds-1061 to KevinVdV for investigation. If others hear anything from Cocoon lists, please let us know as well!
[20:12] <tdonohue> (Thanks KevinVdV -- if you end up finding you don't have the time, just let us know & we can reassign)
[20:12] <KevinVdV> *assigned myself*
[20:12] <KevinVdV> Will do
[20:12] <tdonohue> One last one for today: DS-1063
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1063 ] - [#DS-1063] Dependency on unsupported jdbc-postgresql version - DuraSpace JIRA
[20:12] <mhwood> mdiggory: yes, taking this peripheral stuff away from Cocoon sounds good, as does settling on something more commonly used.
[20:13] <mhwood> Looking for consensus on the range of versions we will support.
[20:13] <mdiggory> changes postgres version to whatever is latest in maven central repo
[20:13] <tdonohue> +1 to Ds-1063, I say we just get this fixed, as we have plenty of time before 3.0
[20:13] <mdiggory> sadly, postgres using non-numeric versioning breaks ranges
[20:14] <sands> ugh
[20:14] <mdiggory> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22postgresql%22%20AND%20a%3A%22postgresql%22
[20:14] <kompewter> [ The Central Repository Search Engine ] - http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22postgresql%22%20AND%20a%3A%22postgresql%22
[20:15] <helix84> we have talked about postgres versions we should support recently (I don't remember where) and concluded that 8.4 should be minimum 9.0 recommended for DSpace 3.0
[20:15] <mdiggory> just pick the latest stable for testing... I assume 9.0 works with previous postgres server versions
[20:15] <richardrodgers> If I understand correctly, the jdbc jars handle previous versions of the DB itself, so the 9.0 handles 8.2, 8.4 etc
[20:16] <mhwood> Yes, but mdiggory is right: Pg server/client and Pg JDBC are separate, and we need to pick a single version for JDBC.
[20:16] <helix84> here: http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg17471.html
[20:16] <kompewter> [ [Dspace-tech] Aside: PostgreSQL 9 working well with DSpace ] - http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg17471.html
[20:16] <sands> do we frown on just skipping the range and letting implementors switch the config to whichever they need?
[20:16] <mhwood> Yes, PostgreSQL typically recommends using the latest client code regardless of server (back to somewhere in the 7s).
[20:17] <mdiggory> everyone can set these versions themselves... it should reside int he dependency management section of the dspace-parent pom, if not correctly there already
[20:17] <helix84> that should be documented
[20:17] <sands> +1 to bumping to the most reasonable latest release.
[20:17] <mhwood> Does anyone know why we should not just update to the highest current JDBC driver version?
[20:17] <mdiggory> https://github.com/DSpace/DSpace/blob/master/pom.xml#L847
[20:17] <kompewter> [ DSpace/pom.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/pom.xml#L847
[20:18] <tdonohue> So, it sounds like we should just set this to the latest version in Maven? (If I'm understanding right?)
[20:18] <mdiggory> mhwood: no, that sounds just fine to me
[20:18] <sands> agreed.
[20:18] <mhwood> If nobody says "no" then I'll get it done.
[20:18] <mhwood> ("No" to "update it", not "is there any reason"!)
[20:19] <mhwood> Sorry, that was confusing.
[20:19] <tdonohue> +1 to updating it to the latest version
[20:19] <mdiggory> sorry mhwood I've become confused with the double negation ;-)
[20:20] <mhwood> If there are no objections, I will update the Pg JDBC driver to the latest version in Central.
[20:20] <mdiggory> no objection here
[20:20] <tdonohue> Ds-1063 Summary: Assign to mhwood to just get it done :) Update to latest version in Maven Central. If anyone has concerns, contact mhwood :)
[20:20] <richardrodgers> fine with me
[20:20] <helix84> +0, I'll do testing of the latest client driver against the 8.4 server, either before or after commiting the change
[20:20] <hpottinger> from discussion on dspace_tech, we probably need to bump the version number for the Oracle JDBC driver, too, to match whatever is likely to be distributed by Oracle/installed by users
[20:21] <mdiggory> after is always more entertaining, if not a means to get someone else to test for you
[20:21] <tdonohue> +1 hpottinger
[20:21] <tdonohue> In general, we might want to do a review of our dependencies overall and bump up versions where it makes sense -- we should be doing this for each new release (obviously)
[20:22] <helix84> mdiggory: you're right, i like how my questionable removal of that testing code spawned an overhaul of the testing framework ;)
[20:22] <sands> yes, i think this should be a pre-release task.
[20:22] * aschweer (765a5bc2@gateway/web/freenode/ip.118.90.91.194) has joined #duraspace
[20:22] <mhwood> helix84: it's traditional, every time I put something in, somebody takes half of it out. :-)
[20:22] <tdonohue> OK, closing up JIRA reviews for today. We'll move on to "Discussion Topics" now.
[20:23] <mhwood> Yes, dependency review should be part of the release cycle checklist.
[20:23] <sands> it would be great to do a while before the release so all the testing happens with the new vers.
[20:23] <sands> instead of right before we cut.
[20:23] <hpottinger> sands +1
[20:24] <tdonohue> sands +1 I say the 3.0 Release Team should make it happen :)
[20:24] <mhwood> sands +1
[20:24] <sands> agreed. i'll add it to "the list"
[20:24] <sands> on with the show then...
[20:24] <tdonohue> (and I'm glad to chip in some if you need more folks on that task)
[20:24] <sands> thanks tdonohue
[20:24] <tdonohue> ok...moving along then...
[20:24] <tdonohue> First topic, helix84 has been talking to lyncode about possible contributions to DSpace 3.0, the first being an OAI interface update described here: https://wiki.duraspace.org/display/DSPACE/LynCode
[20:24] <kompewter> [ LynCode - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/LynCode
[20:25] <tdonohue> helix84 or lyncode, do either of you want to describe this more? (I'm not fully in the loop here, admittedly)
[20:25] <helix84> most of what I know is on that wiki page
[20:25] <helix84> but i'd like to welcome lyncode who is today here with us
[20:26] <helix84> (although i told him Jira review takes 30 minutes so he may be AFK)
[20:26] <lyncode> im here
[20:26] <tdonohue> Hi, lyncode, welcome :) Is there anything more you'd like to add about this work? Is there Code available somewhere that we could look at?
[20:26] <lyncode> the code isn't yet available to public
[20:27] <lyncode> i have some questions
[20:27] <lyncode> if you dont mind
[20:27] <tdonohue> Ok. I'm assuming you have plans to release it at some point? Is there a timeframe you are looking at?
[20:27] <tdonohue> sure, go ahead with your questions. feel free
[20:28] <lyncode> mainly openaire project participants
[20:28] <lyncode> are requiring this new oai interface
[20:28] * helix84 would just like to oint out that now is the best time to get new features in (in august or so, the freeze will be upon us)
[20:29] <lyncode> i think it would be a good dspace improvement, but giving it to DSpace, all references to lyncode will be lost? (i've already asked helix, but didn't understand quite well)
[20:30] <mdiggory> reminds me that there is another project on the Fedora side that is a standalone OAI webapplication.
[20:30] <mdiggory> http://proai.sourceforge.net/
[20:30] <kompewter> [ Proai 1.1.1 Documentation ] - http://proai.sourceforge.net/
[20:31] <richardrodgers> lyncode - all contributions are recognized and documented, what is the concern?
[20:31] <helix84> I told him that e.g. the Mirage theme links back to @mire
[20:32] <tdonohue> lyncode, you would still have references that Lyncode developed the software. But, the copyright & licensing would need to turned over to DuraSpace. As mentioned, we do have notes in our code as to who initially created the software though
[20:32] <tdonohue> & as several mentioned, we attempt to recognize these contributions & document them publicly
[20:33] <tdonohue> So, it's really just the copyright/licensing "header" that needs to reference DuraSpace: https://github.com/DSpace/DSpace/blob/master/LICENSE_HEADER
[20:33] <kompewter> [ DSpace/LICENSE_HEADER at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/LICENSE_HEADER
[20:33] <tdonohue> Does that make sense?
[20:33] <lyncode> yes
[20:34] <lyncode> nice
[20:34] <mhwood> Or is it something separable into a core artifact that becomes an external dependency of DSpace, and an adapter that can belong to DSpace?
[20:34] <lyncode> well our oai solution have core library that we are about to upload to maven central
[20:34] * lyncode_ric (529b3711@gateway/web/freenode/ip.82.155.55.17) has joined #duraspace
[20:35] <tdonohue> The other option is that your code could be released separate from DSpace, in which case you could distribute it as an "Add-on" (which is installed separately alongside DSpace).
[20:35] <lyncode> well, i think this is just a beginning of our contribution to DSpace
[20:36] <lyncode> so i just have to create a jira ticket with the source code?
[20:36] <lyncode> are there any programming patterns
[20:36] <lyncode> that must be fulfilled?
[20:36] <helix84> lyncode has also been very helpful on dspace-tech recently
[20:36] <richardrodgers> maybe put up on github, lyncode ?
[20:36] <tdonohue> If you'd like to contribute the code to DSpace, then yes you can create a JIRA ticket for it. On the JIRA Ticket you can either include the code, or you can create a GitHub Pull Request to submit the code to our GitHub acct.
[20:37] <helix84> lyncode: Jira ticket is the place where we track the progress of the feature/bug. GitHub is the best place to put code and do pull requests.
[20:37] <tdonohue> These days, we *recommend* a GitHub Pull Request, as it's easier to review the code in GitHub, than it is to review file attachements to a JIRA ticket
[20:38] <lyncode> ok then
[20:38] <mdiggory> long term management of your customizations in relation to dspace releases is also improved via use of github.
[20:38] <tdonohue> We also have some general "Code Contributions Guidelines" posted up at: https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines (Though many of these are rather general guidelines)
[20:38] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines
[20:40] <tdonohue> Does that answer all of your questions, lyncode? Is there more you wanted to ask/discuss?
[20:40] <lyncode> yes, i have more
[20:40] <lyncode> as we are developing a new statistical module, with live statistics and so on
[20:41] <lyncode> we have realized that the set of events raised within dspace modules is just a short list of possibilities
[20:42] <lyncode> why not spread events through all dspace modules?
[20:42] <lyncode> oai
[20:42] <lyncode> sword
[20:42] <mdiggory> lyncode: are you aware there are currently two mechanisms for "events" in DSpace
[20:42] <lyncode> two?
[20:42] <PeterDietz> UsageEventListener is one
[20:43] <mdiggory> Yes, there are "Access" or Usage Events
[20:43] <lyncode> yes yes
[20:43] <mdiggory> and then there are model change events in the dspace-api
[20:43] <lyncode> i know
[20:44] <mdiggory> so model changes events are present in all apps that use it
[20:44] <mdiggory> usage events were initially developed to abstract the logging in the XMLUI and JSPUI.
[20:45] <mdiggory> and allow use in other places, so you wanting to expand usage to more apps is tangible
[20:45] <mhwood> Well, originally to make statistics pluggable.
[20:45] <tdonohue> I also want to note that if there are specific "events" you feel are missing (or would like to suggest we add), you are more than welcome to add suggestions to a new JIRA ticket, or start up discussions on dspace-devel mailing list.
[20:46] <lyncode> ok, imagine that i want to have statistical information about oai usage
[20:46] <lyncode> dspace is already prepared? does model change events fulfill my needs?
[20:47] <mhwood> That sounds more like a usage event.
[20:47] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/usage/UsageEvent.java
[20:47] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/usage/UsageEvent.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/usage/UsageEvent.java
[20:47] <mdiggory> the enum can be extended in some cases...
[20:47] <richardrodgers> why would that not be in the oai code? OAI is a 'read-only' application (so to speak), the model events are about changes in the data model
[20:48] <lyncode> yes, i think it's an usage event, i was wondering if it was possible to infer that usage event from the model change events
[20:49] <mhwood> "Model change" means install a new item, update metadata, etc.
[20:49] <tdonohue> in the case of OAI, I don't think you can infer usage events, as there are no model changes when someone browses your repository via OAI
[20:49] <lyncode> yes
[20:49] <tdonohue> as mhwood notes, "model change" events only happen when something inside DSpace *changes* or is added/removed.
[20:49] <lyncode> so, basically, it would be better to extend the usage event possibilities, that's it?
[20:50] <mhwood> I believe so, yes.
[20:50] <tdonohue> yea, that sounds right to me. If you run into more specific questions, I recommend asking on dspace-devel mailing list as well (we'd be glad to help!)
[20:50] * aschweer (765a5bc2@gateway/web/freenode/ip.118.90.91.194) has left #duraspace
[20:51] <lyncode> okey, i've just one more question
[20:51] <mhwood> I don't recall -- do we have an event for "someone looked at this item" (as opposed to "someone retrieved this bitstream")?
[20:51] <KevinVdV> Yes there is a difference between that mhwood
[20:52] <mdiggory> I guess what I would note is that we might consider adding an "application" property to the usage event so that logging tools can differentiate between accessing an oai record vs accessing an item view
[20:52] <sands> +1 to that mdiggory
[20:52] <mhwood> Yes, an answer to "what part of DSpace asked for this".
[20:52] <lyncode> yes
[20:53] <lyncode> distinguish between each module
[20:54] <mhwood> Sorry, you had another question...?
[20:54] <tdonohue> lyncode is your last question relatively quick? Realizing we are running out of time here (meeting is only an hour long). Also, to be clear, you are more than welcome to ask these questions on dspace-devel or during my weekly "DSpace Office Hours". Sometimes our developer meeting agenda's are just a bit packed
[20:54] <lyncode> it's a general question
[20:54] <lyncode> what do you think about a plugin system?
[20:55] <mhwood> Or just give a shout on #dspace anytime.
[20:55] <lyncode> is that interesting for the Dspace community?
[20:55] <mhwood> Another plugin system?
[20:55] <tdonohue> yes, as mhwood mentions, many of us are also on #dspace IRC most of the day, so questions are welcome there.
[20:55] <mhwood> We have PluginManager and ServiceManager. What's missing?
[20:56] <tdonohue> lyncode: you'd have to get more specific. We are always looking towards ways to easily "plug" things into DSpace (and have a few options already), but there could be places for improvement
[20:56] <lyncode> im speaking of adding extra functionality to DSpace on-the-fly
[20:57] <mhwood> I think ServiceManager would be the backend for that. What's missing is the UI.
[20:57] <tdonohue> like Spring / Services Framework/Manager? https://wiki.duraspace.org/display/DSPACE/DSpace+Services+Framework
[20:57] <kompewter> [ DSpace Services Framework - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Services+Framework
[20:57] <tdonohue> whoops -- wrong link. Here's the "official docs": https://wiki.duraspace.org/display/DSDOC18/DSpace+Services+Framework
[20:57] <kompewter> [ DSpace Services Framework - DSpace 1.8 Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC18/DSpace+Services+Framework
[20:58] <lyncode> hmmm
[20:59] <tdonohue> If you have thoughts on that, I'd welcome you to send us notes/thoughts on mailing list or jump into IRC, as we mentioned.
[20:59] <lyncode> :)
[20:59] <lyncode> ok
[20:59] <lyncode> i'll read about it, looking if it fulfill my needs
[20:59] <tdonohue> Sidetopic: Before folks start leaving/heading out
[20:59] <lyncode> many thanks
[20:59] <mhwood> Thanks to you as well, lyncode!
[20:59] <richardrodgers> thank you lyncode, for all your interest!
[21:00] <helix84> I'm looking forward to start testing your code, LynCode
[21:00] <sands> thanks much lyncode
[21:00] <lyncode> ok helix
[21:00] <lyncode> ill be in touch with you
[21:00] <tdonohue> yes, thanks lyncode!
[21:01] <tdonohue> Before folks leave, I do want to note that it has been determined that GPL Licensed code is against our DSpace Code Contributions. Therefore, unfortunately, we'll have to remove Pull Request #17 (Or get approval from EPrints to re-license the code): https://github.com/DSpace/DSpace/pull/17
[21:01] <kompewter> [ Pull Request #17: [DS-1178] XSLT stylesheet for OAI-PMH by helix84 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/17
[21:01] <tdonohue> https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions
[21:01] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions
[21:01] <tdonohue> I also reviewed this with DuraSpace, and in general DuraSpace projects have an "informal" policy that we unfortunately cannot accept GPL licensed code
[21:02] <richardrodgers> what was the reason for this patch?
[21:02] <tdonohue> So, for the time being, helix84 has contacted EPrints about re-licensing this code. If that falls through, we'll have to remove the code and have someone look into rewriting the same functionality under a different license
[21:02] <tdonohue> richardrodgers: Pull Request #17 relates to https://jira.duraspace.org/browse/DS-1178
[21:02] <kompewter> [ https://jira.duraspace.org/browse/DS-1178 ] - [#DS-1178] XSLT stylesheet for OAI-PMH - DuraSpace JIRA
[21:02] <kompewter> [ [#DS-1178] XSLT stylesheet for OAI-PMH - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1178
[21:03] <helix84> Yes, I just contacted them again. My second line of defense is that DSpace compilation doesn't depend on this module (see that Licensing of Contributions link)
[21:04] <tdonohue> I just wanted to let everyone know about this decision. Comments & questions are welcome. We'll obviously also send an email to dspace-devel once we figure out what the resolution will be.
[21:04] <richardrodgers> ok thanks tdonohue
[21:05] <mhwood> For future reference, is there a ruling on LGPL?
[21:05] <tdonohue> hi helix84: Unfortunately our DuraSpace informal policy is strict in stating that we just cannot have any GPL licensed code released "out-of-the-box" in any product. I've verified this with Michele Kimpton our CEO
[21:05] <tdonohue> LGPL is acceptable, as stated in our DSpace Licensing of Contributions here: https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions
[21:05] <kompewter> [ Code Contribution Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions
[21:05] <mhwood> Ah, thanks for the reference. I'm so lazy....
[21:06] <tdonohue> The main reason that GPL is unacceptable is that it limits commercial use/redistribution of DSpace (or any other Product), which we feel is important
[21:06] <hpottinger> I'm glad we've got a parent organization watching out for this stuff...
[21:07] <tdonohue> Again, please feel free to let me know if you have questions or comments. I'd be glad to forward them on to Michele & the rest of DuraSpace. :)
[21:07] <helix84> i have to point out that it's actually not true that GPL limits commercial distribution but of course i don't want to start licensing discussion here
[21:09] <richardrodgers> the problem is, I think, that a lot of it is legally untested (as least in US), so there is uncertainty...
[21:09] <tdonohue> helix84: this is the GPL license issue I'm talking about. Not that it cannot be distributed commercially, but that commercial entities could have their source code republished: http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLRequireAvailabilityToPublic
[21:09] <kompewter> [ Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation (FSF) ] - http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLRequireAvailabilityToPublic
[21:10] <tdonohue> That's the part of GPL that DuraSpace has concerns about. I'd also gladly forward on any addition feedback you have to Michele, as I said
[21:11] <helix84> So technially the problem is that it enhances distribution, not limits it :) I'm sorrt, I couldn't help myself. We can move on now.
[21:11] * lyncode_ric (529b3711@gateway/web/freenode/ip.82.155.55.17) has left #duraspace
[21:11] <tdonohue> yea. essentially, we are trying to protect the "Service Providers" model which DuraSpace feels is very important for our open source products.
[21:12] <tdonohue> in any case, that's it for the formal meeting. We're already over time (sorry). But, I'm glad to hang around if anyone wants to discuss anything else for a while
[21:13] <richardrodgers> I have a quick question - is there a Mockit/JUnit guru in the house?
[21:14] <tdonohue> maybe just ask the question, richardrodgers? :) Not sure if any of us feel we are at the "guru" level, but maybe we could still help
[21:15] <mhwood> What's the opposite of a guru? that's me.
[21:15] <mdiggory> Its been awhile since the last time (DS2.0 work had some JMockit in it)
[21:15] <richardrodgers> I can take it offline, but in my mds environment, the tests are failing because the Mock DBManager is not being called, but the real class. I thought the framework was supposed to take care of this....
[21:16] <richardrodgers> So I guess it's a classpath issue?
[21:16] <mdiggory> whats your env?
[21:16] <helix84> mhwood: would that be urug? http://crawl.chaosforge.org/index.php?title=Urug
[21:16] <kompewter> [ Urug - CrawlWiki ] - http://crawl.chaosforge.org/index.php?title=Urug
[21:17] <richardrodgers> Should be just the same as DSpace (some code is different, but the Unit test setup is the same, AFAIK)
[21:18] <mdiggory> I mean are you just running tests in maven or maven combined with some IDE
[21:18] <richardrodgers> straight maven cli
[21:19] <mdiggory> jdk 1.5 or 1.6 or ...
[21:19] <richardrodgers> 1.6
[21:20] * sands (~sandsfish@18.189.31.239) has left #duraspace
[21:20] <mdiggory> did you incorperate any of mhwoods latest changes?
[21:20] <richardrodgers> no
[21:20] <mdiggory> ok
[21:21] <mdiggory> so at this point its just like running some tests on dspace-api?
[21:21] <mhwood> Sorry, must go, probably can't help with JMockit anyway. 'bye....
[21:21] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:21] <richardrodgers> yep, the standard set of CommunityTest, CollectionTest, etc (about 20)
[21:22] <mdiggory> https://github.com/richardrodgers/mds
[21:22] <kompewter> [ richardrodgers/mds · GitHub ] - https://github.com/richardrodgers/mds
[21:22] <mdiggory> which project in there contains the tests and pom.xml config....
[21:22] * ryscher (98033b4c@gateway/web/freenode/ip.152.3.59.76) Quit (Quit: Page closed)
[21:22] <mdiggory> kernel?
[21:23] <richardrodgers> yes, kernel
[21:23] <richardrodgers> but don't try it directly - there is uncommitted code (so you would see spurious errors)
[21:23] <mdiggory> got this somewhere?
[21:23] <mdiggory> https://github.com/DSpace/DSpace/blob/dspace-1_8_x/pom.xml#L64
[21:23] <kompewter> [ DSpace/pom.xml at dspace-1_8_x · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/dspace-1_8_x/pom.xml#L64
[21:24] <richardrodgers> isn't that java 1.5 only?
[21:25] <richardrodgers> but I'll investigate that anyway, thanks mdiggory
[21:25] <mdiggory> yes, that line, but surefire itself may need the other config details to be present.
[21:25] <richardrodgers> OK, good thing to check
[21:26] <mdiggory> some more test env stuff in dspace-api pom to verify
[21:26] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/pom.xml#L56
[21:26] <kompewter> [ DSpace/dspace-api/pom.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/pom.xml#L56
[21:26] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/pom.xml#L109
[21:26] <kompewter> [ DSpace/dspace-api/pom.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/pom.xml#L109
[21:28] <mdiggory> most everything between lines 22 and 119
[21:29] <richardrodgers> I will double-check these, but most all my pom data is taken directly from DSpace master
[21:32] <richardrodgers> actually, I see differences already. Thanks, this gives me something to try!
[21:37] * KevinVdV (~kevin@d54C154B1.access.telenet.be) Quit (Quit: KevinVdV)
[21:38] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:39] <richardrodgers> I've got to run, thanks all
[21:39] * richardrodgers (~richardro@18.111.19.59) Quit (Quit: richardrodgers)
[21:53] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.