Timestamps are in GMT/BST.
[0:03] * ksclarke (~kevin@adsl-162-19-234.clt.bellsouth.net) Quit (Quit: Leaving.)
[0:47] * krnl_ (Andrius@193.219.34.106) Quit ()
[0:56] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[1:17] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[1:55] * krnl_ (Andrius@193.219.34.106) has joined #duraspace
[3:05] * Tonny_DK (~Tonny_DK@130.226.36.117) Quit (Quit: Tonny_DK)
[3:06] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[4:07] -hubbard.freenode.net- *** Looking up your hostname...
[4:07] -hubbard.freenode.net- *** Checking Ident
[4:07] -hubbard.freenode.net- *** Found your hostname
[4:07] -hubbard.freenode.net- *** No Ident response
[4:07] [frigg VERSION]
[4:07] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:07] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:07] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:07] -hubbard.freenode.net- [freenode-info] help freenode weed out clonebots -- please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
[4:13] * pvillega (~pvillega@62.77.170.185) has joined #duraspace
[4:22] * pvillega_ (~pvillega@86.47.50.67) has joined #duraspace
[4:23] <Davetaz> interesting dspace website :S
[4:25] * pvillega (~pvillega@62.77.170.185) Quit (Read error: Operation timed out)
[4:35] * Tonny_DK (~thl@130.226.36.117) Quit (Remote host closed the connection)
[4:37] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[8:07] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[9:07] * pvillega__ (~pvillega@62.77.170.185) has joined #duraspace
[9:11] * pvillega_ (~pvillega@86.47.50.67) Quit (Ping timeout: 258 seconds)
[9:11] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:21] * ksclarke (~kevin@adsl-162-19-234.clt.bellsouth.net) has joined #duraspace
[9:51] * sandsfish (~sandsfish@dhcp-18-111-28-197.dyn.mit.edu) has joined #duraspace
[11:05] * sandsfish (~sandsfish@dhcp-18-111-28-197.dyn.mit.edu) has left #duraspace
[11:06] * sandsfish (~sandsfish@dhcp-18-111-28-197.dyn.mit.edu) has joined #duraspace
[12:40] * pvillega__ (~pvillega@62.77.170.185) Quit (Remote host closed the connection)
[13:36] * snail1 (~stuart@130.195.86.37) has joined #duraspace
[13:36] * snail (~stuart@130.195.86.37) Quit (Ping timeout: 276 seconds)
[13:53] * pvillega (~pvillega@89.100.155.181) has joined #duraspace
[14:57] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:49] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[15:49] * bojans (~Bojmen@91.118.66.139) has joined #duraspace
[15:51] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:54] * kgilbertson (~Keith@207.138.47.158) has joined #duraspace
[16:00] <tdonohue> Welcome all -- today for the DSpace Dev Mtg, we are having a Special Topic Mtg concentrating on DSpace Services Framework. mdiggory will be leading the discussion. http://wiki.dspace.org/confluence/display/DSPACE/DevMtg+2010-05-26+-+DSpace+Services+Framework
[16:00] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) has joined #duraspace
[16:00] <tdonohue> take it away, mdiggory (whenever you are ready)
[16:01] <mdiggory> ok, just getting settled in
[16:02] <mdiggory> So, I want to caution that this is not a "presentation" so we should decide on the structure of the meeting
[16:02] <tdonohue> agreed, it's hard to "present" via IRC
[16:02] <sandsfish> Perhaps one item could be the existing use of the Services Framework in 1.6
[16:03] <mdiggory> The topic is how do we use the Service Framework as a tool for future DSpace development.
[16:03] <tdonohue> I think we should assume that everyone has read/reviewed the "Homework" on the Agenda -- http://wiki.dspace.org/confluence/display/DSPACE/DevMtg+2010-05-26+-+DSpace+Services+Framework
[16:03] <mdiggory> sandsfish: excellent point
[16:04] <mdiggory> Things have changed slightly since this was authored but for the most part it is a good starting point.
[16:04] <tdonohue> so, perhaps that's a place to start mdiggory? discussiong of existing use of Services in 1.6 -- and then expand to future development work that we can all think of? (while encouraging questions & discussion throughout)
[16:04] <mdiggory> in 1.6.1 DSpace Services are available and provide two capabilities off the shelf
[16:05] <mdiggory> 1.) Configuration Service
[16:05] <mdiggory> 2.) Event Service
[16:05] <mdiggory> The later is used currently for only the UsageEvents being logged into the dspace.log and statistics service
[16:06] <tdonohue> and (1) is for the initial load of the dspace.cfg (on startup), correct?
[16:06] <mdiggory> The wiki page outlines the "end user / developer" configuration of attaching Event Listeners to the Event Service to be alerted to Usage Events from the JSPUI and XMLUI
[16:06] <mdiggory> tdonohue: yes, I'll return to that
[16:07] <mdiggory> ToC links/anchors in the wiki would nice here
[16:07] <mdiggory> hang on one sec
[16:08] <mdiggory> http://fedora-commons.org/confluence/display/DSPACE/DSpace+Services+Framework#DSpaceServicesFramework-ConfiguringEventListeners
[16:09] <mhwood> Showing the other somewhat mysterious feature of 1.6: Spring is spreading.
[16:09] <mdiggory> Its important to qualify that The following configuration is happening after the ServiceManager/Kernel has started and is happening outside the intitialization of the service manager itself
[16:10] <mdiggory> thus as mhwood points out, we are currently using Spring in two places in dspace 1.6.1
[16:10] <mdiggory> (and 1.6.0)
[16:10] <mdiggory> ther is a Spring Application context available in the webapplication initialization that is specific to that webapplication
[16:11] <mdiggory> in XMLUI, it is the applicationContext that Cocoon provides
[16:11] <mdiggory> in JSPUI and other webapps, it is just plain old spring
[16:11] <mdiggory> These spring application Contexts actually have absolutely nothing to do the with dspace-services
[16:12] <mdiggory> but we use them as an opportunity to do configuration.
[16:12] <mdiggory> the second place we use spring is within the DSpace Service Manager
[16:12] <mdiggory> and that is utilized to provide application configuration to all the core services within the configuration manager
[16:13] <mdiggory> (this is where the wiki page could use some improvement)
[16:13] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/impl/src/main/resources/spring/
[16:14] <mdiggory> these exemplify the manner in which spring is used int he SpringServiceManager to intitialize the core services that the serivemanager provides
[16:14] <mdiggory> most specifically .... http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/impl/src/main/resources/spring/spring-dspace-core-services.xml
[16:14] <mdiggory> which initializes the "Session", "Request". "Caching" and "Event" services
[16:15] <mdiggory> you do not see any "DSpace" or "ServiceManager" object here because this is deep within the context of intitializing that framework
[16:16] <mdiggory> but perhaps this is getting too close, I will back away from this level of detail for this discussion
[16:16] <tdonohue> so, here's a quick question -- how are the initialized "Session", "Request" and "Caching" services used in 1.6.x (or are they yet?)
[16:16] <mdiggory> They are used in the following manner
[16:17] <mdiggory> And this is best exemplified a webapplication context
[16:17] <mdiggory> However, in this context the mapping is not 100%
[16:17] <mdiggory> A DSpace Request is analogous to the complete servlet request/response cycle
[16:18] <mdiggory> it is opened at the beginning of the request, and it is closed at the end
[16:18] <mdiggory> so, rather than creating a DSpace "Context" and passing it through all method calls
[16:19] <mdiggory> we are instead registering the new request in the RequestService where it can be found at any time by any code able to call new DSpace().getRequestService().getCurrentRequest()
[16:20] <mdiggory> Conceptually from a coding standpoint what we are doing is creating an "environment" within which all dspace code is executing
[16:21] <tdonohue> gotcha -- so does any code actually take advantage of this yet in 1.6.x? I'm assuming it's just mostly there for us to start to build off of?
[16:21] <mdiggory> In the non-webapp context, the "Request" is currently hardcoded in the CLI as the beginning and end of the Launcher execution
[16:21] <mdiggory> Currently the UsageEvent code utilizes this
[16:21] <mhwood> There's a servlet filter that notices an HttpRequest and sets up the DSpace request environment.
[16:21] <mdiggory> in the Webapplications
[16:21] <tdonohue> ok -- cool
[16:21] <mdiggory> thanks mhwood, yes
[16:22] <mdiggory> http://scm.dspace.org/svn/repo/dspace/trunk/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/WEB-INF/web.xml
[16:23] <sandsfish> mdiggory: as a quick aside, org.dspace.content.service.ItemService has nothing to do with this, is that correct?
[16:23] <mdiggory> <filter-class>org.dspace.utils.servlet.DSpaceWebappServletFilter</filter-class>
[16:23] <mdiggory> sandsfish: correct, this is older code that is not part of dspace-services
[16:23] <tdonohue> aha -- this is beginning to make more sense -- thanks mdiggory
[16:24] <sandsfish> looks like it's just using the term "service" abstractly. we should be careful to clarify misleading wording, now that we have a capital S Service.
[16:24] <mdiggory> So we started off with Spring configuration examples, but we should be clear, the goal with dspace-services is that it can be interacted with via java code directly
[16:24] <mdiggory> you do not need to use the XMLUI/JSPUI Spring applicationContext to register listeneres or new services
[16:25] <mdiggory> or providers etc.... the api provides the capability to interact with the ServiceManager to register and deregister Services, Providers, Listeners etc
[16:26] <mdiggory> in this regard the dspace-services SerivceManager can be a dynamic registry of services.
[16:27] <tdonohue> mdiggory -- is this the general example (at least how you get the ServiceManager to interact with it): http://fedora-commons.org/confluence/display/DSPACE/DSpace+Services+Framework#DSpaceServicesFramework-KernelStartupandAccess
[16:27] <mdiggory> and all a "service" really is in this situation is a JAva object singleton that is referenced by a key, in our practice this key is a Classname / signature
[16:28] <mdiggory> In a sense, this start to look a little like the OSGi services registered for a bundle...
[16:28] <mdiggory> but only supervficially as there is no classloader isolation or any of the lifecycle provided by an OSGi container
[16:29] <mdiggory> tdonohue: Yes, that is a generic example
[16:29] <tdonohue> are others getting this? comments/questions about usage in 1.6.x? (it's awfully quiet -- just want to check in)
[16:29] <mdiggory> Its important to recognize that "DSpace" is just a helper class encapsulating the real logic of getting to the ServiceManager
[16:30] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/utils/src/main/java/org/dspace/utils/DSpace.java
[16:30] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[16:30] <kgilbertson> mdiggory: is the ServiceManager shared by all running DSpace apps? Or they each get their own ServiceManager?
[16:31] <mdiggory> which basically looks like new DSpaceKernelManager().getKernel(null).getServiceManager().getServiceByName(EventService.class.getName(), EventService.class
[16:31] <tdonohue> good question, kgilbertson :)
[16:31] <mdiggory> kgilbertson: yes good question for which there are two answers :-)
[16:32] <mdiggory> in DSpace 2.0 the "Kernel" for a DSpace instance is registered as an MBean in the webapplication container, allowing it to be shared across webapplication Contexts
[16:33] <mdiggory> Theoretically, One webapplication can register Services while another can use the services without knowing where they came from
[16:33] <mdiggory> however...
[16:33] <grahamtriggs> sharing resources across web applications - particularly ones loaded from within the web applications themselves - is a really good way of shooting yourself in the foot
[16:34] <mdiggory> in DSpace 1.x, we stripped this capability in favor of isolating the webapplications and having one Kernel per webapp
[16:34] <mdiggory> as grahamtriggs so expressively stats
[16:34] <mdiggory> states
[16:34] <kgilbertson> ok
[16:34] <sandsfish> mdiggory: and following that (when you're ready) what kind of setup (DSpace-specific) in code is necessary to use this. Just using the DSpace object, grabbing the ServiceManager and starting to interact?
[16:35] <mdiggory> So at this time there is still an MBean registered for each webapp, they just are not shared.
[16:35] <mhwood> It looks like something, somewhere, needs to call DSpaceKernelInit.getKernel and then call start() on the DSpaceKernelImpl that comes back, or DSpace.anything will throw IllegalStateException.
[16:35] <mdiggory> sandsfish: since its already in DSpace 1.6.1, yes, you can just access it in your code
[16:36] <mdiggory> but
[16:36] <mdiggory> you need to think about how your code is initialized if you want to register your own services, etc
[16:37] <richardrodgers> so in the case of runtime configuration (1.6- based), this means webapp 'A' can change a configuration value, but webapp 'B' don't see it?
[16:37] <mdiggory> that is where I introduced using the webaplications spring applicationContext as a means to initiate configuration
[16:37] * kgilbertson (~Keith@207.138.47.158) Quit (Read error: Connection reset by peer)
[16:37] <mdiggory> richardrodgers: yes they are totally isolated atm
[16:38] <mhwood> Webapp config isolation = good.
[16:38] * Keith__ (~Keith@207.138.47.158) has joined #duraspace
[16:39] <mdiggory> mhwood: this is a matter of opinion. if AaronZ were here he would argue otherwise and extole the benefits of the shared Kernel approach
[16:39] <mhwood> As long as my three XMLUI instances in one Tomcat don't try to share.
[16:39] <grahamtriggs> richardrodgers: even if you share configuration between webapps, you can't discount having multiple servers for scalability / reliability
[16:40] <mdiggory> there are benefits to both strategies... but I don't intend to argue for or against them in this meeting
[16:40] <tdonohue> just over 20 mins left -- should we move on towards discussion of future development work around Services?
[16:40] <PeterDietz> What does swapped out at runtime / quick hot redeploy of code mean? While working in IDE and hitting the shiny green button, or something dspace command line
[16:40] <richardrodgers> grahamtriggs: agreed
[16:40] <mdiggory> they are isolated in 1.6.1 if we want to talk about future development then it might be a topic to discuss there
[16:41] <mdiggory> PeterDietz: good point... this is not OSGi
[16:41] <sandsfish> mdiggory: What are the drawbacks / costs of starting to use dspace-services, before we head into where to use them?
[16:41] <mdiggory> we are talking about juggling the execution of two Spring Application Contexts here..
[16:42] <mdiggory> once they execute, then the changes have been made.
[16:42] <mdiggory> that generally happens at webapplication initialization
[16:42] <mdiggory> however... we can write tools that interact directly with the service manager at runtime and alter its configuration if we want to
[16:43] <mdiggory> for instance, we might write a user interface that would register/deregister specific classes to be used as specific services
[16:43] <mdiggory> or write UI that allow us to alter the ConfigurationService or the configuration of any Service at runtime...
[16:44] <mdiggory> and that will lead us to a discussion about database driven configuration ....
[16:44] <mdiggory> sandsfish: not many drawbacks performance wise that I can think of
[16:45] <mdiggory> just perhaps the cost is really just learning to use them
[16:45] <mdiggory> but I may be optimistic here ;-)
[16:45] <mdiggory> So... intermission... tdonohue do we have other topics?
[16:46] <richardrodgers> How about a GSOC update?
[16:46] <mdiggory> because we can go into ConfigurationService and db driven config as a way to talk about that service
[16:46] <mhwood> Needs further documentation, especially, "how *should* we use these?" The framework is quite flexible, which usually means there are good and bad ways of doing common things.
[16:47] <richardrodgers> mdiggory: isn't ConfigurationService non-persisting?
[16:47] <tdonohue> well, we could open up for general discussion here -- do we like this direction? -- can we all come to an agreement that we should start to figure out ways to take advantage of this Services Framework?
[16:47] <mdiggory> richardrodgers: only in its current implementation as a file
[16:48] <mhwood> Write a new one and plug it in. That's what the framework is for, yes?
[16:48] <mdiggory> bingo
[16:48] <mhwood> Yes, *is* this our direction now?
[16:49] <tdonohue> I'd vote +1 to this being our direction, but I'd like to hear others' opinions
[16:49] <mdiggory> we may need to enhance the existing ConfigurationService api to support a few persistence methods... and there is another design startegy that Aaron employed to do this called "mixins"
[16:50] <mdiggory> Where additinal capabilities are mixed into an implementation via separate defined interfaces
[16:51] <tdonohue> understood -- there will always be enhancements, changes along the way :) just curious if people see this concept of a Services Framework as a "good idea" and worth working towards.
[16:51] <sandsfish> there certainly seem to be cleanliness / extensibility / etc. wins to be had from it's use. i'd vote for a cautious step toward using the framework, but i think there are a lot of discussions to be had, depending on how it is used. for instance, i'd float the idea that some areas, if it is intended that they be retrofitted to use spring, should not be slowly converted, given our new time-based release approach, but that projects sh
[16:51] <sandsfish> be formed around these conversions, and the trunk be branched to isolate the work on a sub-system, especially the core ones.
[16:51] <mhwood> So, if you want to know how you're configured, you can go ask the ConfigurationService each time, or you can implement a listener interface and be told when stuff changes, right?
[16:51] <mdiggory> mhwood: correct
[16:52] <mdiggory> and a best practice would be to make sure you pay good attention to the ConfigurationService and if you hang onto configuration state locally in fields, that you have a listener that will update those if they changes in configuration
[16:53] <tdonohue> sandsfish: agreed -- it's not a giant leap -- and we shouldn't just start breaking things in Trunk (also fyi -- we have new guidelines about how to treat trunk: http://wiki.dspace.org/confluence/display/DSPACE/Guidelines+for+Committing )
[16:53] <mdiggory> and this would also apply to other services as well. IMO a best practicee is to always go to the service manager for getting at things and avoid changin state locally in an instance class
[16:53] <tdonohue> so, yea, we'd have to branch off larger projects and merge them back in later
[16:54] <mdiggory> There are some important roadmap milestones we should explore for 1.7
[16:54] <mdiggory> and these also involve the GSoC projects
[16:55] <mdiggory> For instance there is still the "StorageService" that will be ported over.
[16:55] <mdiggory> and We need guidelines on how to replace usage of ConfigurationManager with ConfigurationService.
[16:55] <mhwood> Yes please.
[16:56] <mdiggory> and talk about how we might chac things like "Context" and tie it to the "Request" so we can stop having to pass it around
[16:56] <mdiggory> chac = cache
[16:56] <tdonohue> makes sense to me as well...we need guidelines and good examples of how to use this properly
[16:58] <mdiggory> finally, dspace-discovery introduces its own solr dirven "SearchService" and is the example case we currently have in the wild for how modules use and register new services
[16:58] <mhwood> *plug* I've been staring at the code trying to understand it well enough to fill out the Javadoc, so there is some more to read there. I'm sure I've misunderstood some of it.
[16:58] <sandsfish> yes, documentation / conventions will be key for any area we choose to start implementing spring in, so we don't end up with a mess of different implementations.
[16:59] <mhwood> Spring adoption sounds like another topic?
[16:59] <sandsfish> ah, yes. my mistype.
[17:00] <mdiggory> so, what I would recommend is that we need more eyes, like mhwood, looking at the framework and assiting in documentation and examples
[17:01] <tdonohue> I've noticed that most of the other devs/committers are silent on my "call" for acceptance of this direction. Maybe everyone should take some time over the next week or two to dig in further -- so we can make a decision soonish (next few weeks), and work towards best practices as necessary
[17:01] <mdiggory> We can agree that we need more guidance and docs... but we are the community that is originating this solution and it is upto us to provide this
[17:01] <PeterDietz> would you consider discovery to be the example to at in terms of how to use services?
[17:01] <sandsfish> tdonohue: +1 on time to educate.
[17:01] <PeterDietz> I'm looking over http://scm.dspace.org/svn/repo/modules/dspace-discovery/trunk/block/src/main/java/org/dspace/app/xmlui/aspect/discovery/BrowseFacet.java
[17:02] <mdiggory> (meaning the you cannot leave this to the 2.0 development team, they have used up a lot of their resources to bring it into existence)
[17:02] <PeterDietz> s/example to at/example to look at/
[17:02] <mdiggory> a lot = 110%
[17:03] <tdonohue> mdiggory: yes, what is the best code for us to all dig into (besides the Services API itself)? Discovery? or 1.6 Stats? or both?
[17:03] * gavinh (~root@86-44-107-163-dynamic.b-ras2.bbh.dublin.eircom.net) has joined #duraspace
[17:03] <mhwood> I can write lots of doco. but will need correction from those who understand the code better, at least until I understand it better.
[17:04] <mdiggory> mhwood: I've been watching you... its looking good so far... if you have a question its good for listserv topics and I'll answer where I can
[17:04] <mhwood> Thanks!
[17:04] <stuartlewis> Is everyone OK if we start chatting about the GSoC testing project, or does the DSpace dev meeting need a little longer?
[17:05] <mdiggory> PeterDietz: maybe thats a good example of where I didn't eat my own dog food ;-)
[17:05] <tdonohue> so, mdiggory, what is a good example for everyone?
[17:05] <tdonohue> (stuartlewis -- closing up very shortly )
[17:05] <stuartlewis> tdonohue: Thanks.
[17:06] <mdiggory> sometimes wrong examples are more informative.... that is good, I just am (1) not listening to configuration and (2) hanging onto the search service I go in the constructor
[17:07] <sandsfish> mdiggory: when you have time, i'd like to know what you mean by your reference (in the DDSUG 2009 presentation) to "default services" (vs. other services?).
[17:07] <mdiggory> So maybe a good project would be to correct this as an example
[17:07] <tdonohue> Ok -- Everyone take time to review the Services Framework & code -- we will discuss this again and vote in next few weeks. If you have discussion topics to bring up, please start thread(s) in dspace-devel, so that we can all learn from your discoveries/questions.
[17:07] <mdiggory> sandsfish: http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/impl/src/main/resources/spring/spring-dspace-core-services.xml
[17:08] <mdiggory> these are "default services"
[17:08] <mdiggory> or "core services"
[17:08] <tdonohue> I'd like to close the Special Topic meeting now -- and hand things over to the GSoC Testing Project (as they wanted to discuss that project for the next hour)
[17:08] <mdiggory> I thinkw e should use "core"
[17:08] <mdiggory> tdonohue: ok
[17:08] <sandsfish> thanks tdonohue & mdiggory
[17:08] <mhwood> As interested as I am in testing, I've gotta go. Will read the log.
[17:09] <tdonohue> So, if you'd like to stick around for GSoC Testing, please do (as this may effect us all with Unit Testing, etc) -- otherwise, we'll see you next week.
[17:09] <stuartlewis> Ok - if it is good with everyone, we'll spend a while talking about the DSoace GSoC testing project: http://fedora-commons.org/confluence/display/DSPACE/GSOC10+-+Add+Unit+Testing+to+Dspace
[17:09] <kshepherd> thanks mdiggory, i think i need to read the first 1/2 of the meeting in the archives to get some more context ;)
[17:09] <mdiggory> many thanks for showing up folsk
[17:09] <kshepherd> (thought i was logging :P)
[17:09] <tdonohue> thanks mdiggory!
[17:09] <mdiggory> (I need a new keyboard_
[17:09] <gavinh> evening all.
[17:09] <richardrodgers> thanks mdiggory !
[17:09] <gavinh> glad ye ran late, as i was :)
[17:09] <pvillega> evening ;)
[17:09] <mdiggory> Hello
[17:09] <PeterDietz> thanks mdiggory, hi gavinh
[17:10] <tdonohue> hi all...I'll stick around as much as I can :)
[17:10] <stuartlewis> What I'd like to propose is, everyone (if you haven't already), have a quick read over the wiki page so you know the outline of the proposal: http://fedora-commons.org/confluence/display/DSPACE/GSOC10+-+Add+Unit+Testing+to+Dspace
[17:10] <gavinh> pere - i blame matt and guinness..
[17:10] <stuartlewis> Then if Pere can talk us through his proposed project plan.
[17:10] <pvillega> gavinh: all forgiven then ;)
[17:10] <stuartlewis> Then we can go from there, discuss the plan, the scope, the content etc, and hopefully come to a consensus on the a final project plan.
[17:10] <pvillega> stuartlewis: whenever you want
[17:10] <stuartlewis> Does that sound OK?
[17:10] <kshepherd> tdonohue: please see #dspace for some stuff about ds-584 / dspace 1.6.2 so i don't derail the topic in here
[17:11] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:12] <gavinh> that page has filled out a lot since i last looked, seems quite comprehensive
[17:12] <stuartlewis> The most important bits for us to discuss, are the draft plan, and the 'tools' section.
[17:12] <pvillega> while you all are reading the page, I would like to point you to the "project plan" section, speacially the "draft" subsection, as it could be a starting point for today's discussion
[17:13] <stuartlewis> This project is hopefully going to form the basis for our ongoing test development efforts for DSpace, so we need to a broad consensus on how we go about this, and what toolsets we use.
[17:13] * cwilper (~cwilper@74-44-156-211.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[17:13] <mdiggory> (reading)
[17:14] <mdiggory> Based upon our previous meeting this is another good case for DSpace-Services.
[17:15] <pvillega> I'm afraid I did not pay too much attention to the previous meeting, sorry about that, had to finish some homework :(
[17:15] <mdiggory> In 2.0 we provided a "DataSource" service that exemplified the database resource used by other services
[17:16] <mdiggory> there were a couple implementations of that source to test against
[17:16] <mdiggory> http://scm.dspace.org/svn/repo/dspace2/core/trunk/impl/src/main/java/org/dspace/database/DSpaceDataSource.java
[17:16] <pvillega> (checking)
[17:17] <mdiggory> we tied in use of c3p0 for pooling / etc
[17:17] <mdiggory> (or I should say that Aaron did)
[17:17] <mdiggory> this case was derby...
[17:17] <stuartlewis> How much work is involved to go that way with DSpace as it is right now (e.g. trunk)?
[17:18] <stuartlewis> (in the context of the GSoC timeline)
[17:19] <mdiggory> I suspect that pvillega is going to have to dig around in the guts of DatabaseManager to alter the behavior...
[17:19] <mdiggory> And if he is in there... I'm recommending he do it "right"
[17:19] <mdiggory> in a manner that is correct for the roadmap / direction (if we have that yet)
[17:20] <pvillega> rght now I'm open to ideas, so if you think using dspace services is the way to go, we can follow that path
[17:20] <pvillega> you know Dspace code better than me :)
[17:20] <gavinh> there does need to be a balance of whats practical within the timeframe, so a complete project can be achieved, and to contribute to the roadmap of dspace.
[17:20] <mdiggory> gavinh: I don't think this is asking for anything out of scope.
[17:21] <stuartlewis> We also need to look at this in the whole scope of the project. We can do the low level single class unit tests without this, and we can do the high level functional tests without this.
[17:21] <mdiggory> in fact, I will say two things about any GSoC project....
[17:21] <pvillega> this would be more for integration tests, yes
[17:21] <stuartlewis> Where do we get most ROI in this project?
[17:21] <gavinh> mdiggory, indeed, scope is one thing, time taken to complete is another
[17:21] <mdiggory> (1) The student needs to get upto speed with DSpace and be aware of the development roadmap we are attempting to craft
[17:21] <richardrodgers> the field is wide open ATM - they would all be big wins....
[17:22] <tdonohue> +1 richardrodgers -- anything would be a huge "win", even if just a functional testing model
[17:22] <mdiggory> (2) We spent an entire year developing that direction and not using it means the student will be doing even more work rather than adopting want is there
[17:22] <mdiggory> want = what
[17:22] <stuartlewis> richardrodgers: That way my thought too, so was wondering if we're better maybe looking at these other types that require less refactoring, as the refactoring could take a large proportion of the project time?
[17:22] <gavinh> stuart - interesting point, if there is a certain amount of "hours" you need to max the impact of that time, but still allow a completeness within it.
[17:23] <mdiggory> stuartlewis: not following
[17:23] <richardrodgers> stuartlewis: yes, I'd try to at least devise the project plan with cut-outs like that...
[17:23] <mdiggory> I'd rathe have well fit solutions that will work in 1.7 rather than prototypes that are too far removed
[17:24] <gavinh> if a client came to me with this overall plan, we would estimate each part in isolation and see what fits within budget and priorities.
[17:24] <pvillega> about the completeness, I think the point here is to create the proper structure more than to create a lot of tests. I mean, having tests for all the code would be great, but (quoting stuart) I'm sure if we create a good scaffolding the tests will come
[17:24] <mdiggory> Likewise I want the architectural roadmap to inform the students work
[17:24] <gavinh> shouldnt we approach gsoc in same way?
[17:24] <pvillega> so maybe is good idea to spend more time creating the right scaffolding
[17:24] <mdiggory> gavinh: no
[17:25] <gavinh> why not? isnt a project a project?
[17:25] <tdonohue> Since, anything is a win, you could approach this from the "top-down" i.e., start at a Functional level, and move more towards Unit Testing -- if Unit Testing doesn't end up 100% complete, then hopefully we at least have a model to work from.
[17:25] <richardrodgers> pvillega: I'd say yes, as long as you have at least one proof-of-concept areas (functional, etc) that you know can be delivered
[17:25] <mdiggory> This is about pvillega having a successful project in which he learns the "open Source Way"...
[17:26] <pvillega> richardrodgers: yes, of course, some tests and samples would ahve to be done
[17:26] <mdiggory> and often that runs contradictory to client driven development strategies
[17:26] <stuartlewis> Can we get some basics on the table, and agree those, and then look at each one in turn? I'd like to suggest the three levels are 1) single class simple junit tests, 2) integration tests requiring an embedded db, 3) higher level tests (e.g. selenium funcational tests).
[17:27] <gavinh> sounds good place to start
[17:27] <tdonohue> though sound good to me
[17:27] <tdonohue> though --> those
[17:27] <mdiggory> Because in a client driven strategy, one may cut corners to meet deadlines rather than keep architecturally pure
[17:27] <richardrodgers> ok by me
[17:27] <gavinh> mdiggory - point taken.
[17:27] <stuartlewis> OK - so lets start with #1, then talk about #2, and finally #3?
[17:28] <pvillega> stuart: ok
[17:28] <richardrodgers> OK for #1 the nice thing is that one can have partial coverage and still have good value...
[17:28] <stuartlewis> Or... do we have a preference as to which is most important and should be tackled first?
[17:28] <stuartlewis> I think #1 would give us an early win
[17:28] <tdonohue> +1
[17:29] <stuartlewis> The sooner we can get this sort of scaffolding in, and get some tests written, hopefully other tests will follow from the community, and we can start building an expectation that new code comes with some tests?
[17:29] <mdiggory> ok...
[17:29] <mdiggory> (2) seeems most important to get the design right on...
[17:29] <stuartlewis> mdiggory: Yes.
[17:30] <stuartlewis> Which perhaps is a good reason to delay it slightly, and do other work first, to give us tie to agree on the best way to go?
[17:30] <stuartlewis> s/tie/time
[17:30] <richardrodgers> stuartlewis: pvillega if you share the framework early, I can try to have the MIT 1.7 targeted work attempt to comply...
[17:30] <stuartlewis> Ok - so is there consensus we start #1 first?
[17:31] <stuartlewis> And if so, what scaffolding do we build around this to enable the tests to be run?
[17:31] <pvillega> I agree... keep in mind we have 2 phases, 1 month each. We can focus now in one area and leave another for the second half
[17:31] <gavinh> indeed pere, and tackling #1 and then #2 is a good path perhaps?
[17:31] <pvillega> richardrodgers: I will try :)
[17:31] <richardrodgers> how much out of the box support does maven have for this?
[17:32] <mdiggory> richardrodgers: for which type of testing?
[17:32] <pvillega> to run the unit tests, surefire
[17:32] <richardrodgers> sorry I mean just #1 unit test execution
[17:32] <pvillega> well, unit testing is easy with maven
[17:32] <mdiggory> richardrodgers: we use it in dspace-services... if you check out and run package you will see all the JUnit test execution
[17:32] <richardrodgers> exactly, so what additional framework are we talking about?
[17:33] <richardrodgers> (for this phase)
[17:33] <mdiggory> likewise if you checkout dspace2, you will see the Datasource JUnit test execution if you pacage that
[17:33] <stuartlewis> By the sounds of it, we don't need any other frameworks then.
[17:33] <stuartlewis> Which is good.
[17:33] <richardrodgers> stuartlewis: that's where I was going
[17:33] <pvillega> richardrodgers: just add junit dependencies, jmockit or another mock tool and just create tests
[17:33] <mdiggory> http://scm.dspace.org/svn/repo/dspace2/core/trunk/impl/src/test/java/org/dspace/database/DatabaseTest.java
[17:34] <stuartlewis> So it sounds like the first thing is for Pere to get some basic junit tests written, and maven poms edited to allow them to be run?
[17:34] <stuartlewis> In which case, what would be some good candidates for Pere to look at first?
[17:35] <pvillega> yes, I would like to decide some packages as target
[17:35] <stuartlewis> org.dspace.content.* ?
[17:35] <stuartlewis> (http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/content/)
[17:35] <pvillega> so once we have that part done, we can move to #2 or #3, and after that, if there is time, go back for more
[17:35] <stuartlewis> Yes - sounds good.
[17:35] <stuartlewis> What would you like as a timescale for this?
[17:35] <stuartlewis> 3 weeks?
[17:36] <mdiggory> So this is just write test against an existing dspace instance or do we have any agreement on where/how the db is getting configured
[17:36] <mdiggory> meaning a postgres db?
[17:36] <richardrodgers> it'd be nice to do without a real instance
[17:36] <pvillega> mdiggory: as far as I understand, unit tests don't use database, they mock it if require it
[17:36] <richardrodgers> (i.e. an existing repo)
[17:37] <mdiggory> richardrodgers: I agree, but think that is orthogonal to testing with a embedded db instance like derby
[17:38] <richardrodgers> mdiggory: agreed
[17:38] <stuartlewis> I was assuming #1 could be done without a db, #2 would require one (preferably something like hsql), and #3 perhaps against a real db?
[17:38] <pvillega> yes, I though like that
[17:39] <stuartlewis> So testing something like DCDate could be done without a db, and after the problems we've had with that class recently, would really benefit from some decent tests?
[17:40] <mdiggory> But to be clear.... your just testing the "interface" and you might not get all the interaction between other resources and database down to the persistence / db tier exemplified by using jmockit.
[17:40] <richardrodgers> DCDate is a unit test poster child
[17:40] <kshepherd> +1 for testing DCDate! (and other org.dspace.content.* classes)
[17:40] <pvillega> mdiggory: yes, but as I understand unit test is that, testing the class in isolation. #2, integration test, goes for the interaction and there is where we need the db
[17:41] <mdiggory> pvillega: ok, good stuff
[17:41] <stuartlewis> #1 is a quick easy win. Might not give us deep interaction testing, but is a good start for now?
[17:41] <mdiggory> just making sure we all know it
[17:42] <pvillega> mdiggory: perfect :)
[17:42] <stuartlewis> So Pere: How long do you want to get #1 going, with some good exemplar classes tested?
[17:42] <pvillega> mm let me see...
[17:42] <pvillega> i would say 13th-20th of june, if that seems reasonable
[17:43] <richardrodgers> I have to run - thanks pvillega & all GSOC mentors & participants!
[17:43] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[17:43] <pvillega> thanks richardrodgers!
[17:44] <pvillega> that would give 2-3 weeks (not counting this) for this, and leave another 3-4 before the mid term evaluation
[17:44] <stuartlewis> SOunds good.
[17:44] <gavinh> sounds fair.
[17:44] <gavinh> hope the sunshine in evenings we are having wont impact it :)
[17:44] <stuartlewis> So the next question - do we plan the rest of the project now, or do so once we've got #1 done?
[17:44] <gavinh> ireland is having the next decade of summers this month..
[17:45] <pvillega> if everybody agrees, I would like to decide at least the first half
[17:45] <stuartlewis> I'm tempted to not plan the rest, as we don't know what will be uncovered during #1?
[17:45] <stuartlewis> We can still decide a high level plan though.
[17:45] <pvillega> ok
[17:45] <tdonohue> stuartlewis -- you could always sketch out a plan -- change later on as needed
[17:46] <mdiggory> I would like to explore using the DataSource from DSpace 2.0 as an example of creating a dspace 1.x module that could be added in for database driven uint testing
[17:46] <stuartlewis> Would be nice to do a bit of #2 and #3 if we have the time.
[17:46] <pvillega> gavinh: no worries, I'm a geek, sun is harmful for my transparent skin ;)
[17:46] <stuartlewis> The order of #2 and #3 could depend on when we've agreed how to tackle #2?
[17:46] <gavinh> as long as there is weekly? report meetings or something, we should see what is uncovered as it happens?..
[17:46] * cwilper (~cwilper@74-44-156-211.dsl1-erie.roch.ny.frontiernet.net) Quit (Quit: Leaving)
[17:46] <stuartlewis> gavinh: Yes! pvillega: Weekly status reports will be required! :)
[17:46] <pvillega> I would say after having #1 done, #2 is the next logical step.
[17:47] <pvillega> stuarlewis: no problem on weekly reports :)
[17:47] <stuartlewis> #2 next - yes, as long as we're all on the same page, and all have the same understanding by then, which hopefully we will.
[17:47] <mdiggory> I will agree to create a modules project that exemplifies how this would be ported. And pvillega you are welcome to use this later for (2). I think this would reduce the "uncertainty" that others are feeling about dspace-services
[17:47] <gavinh> i think an outline of whats next with a review meeting prior to going onto it, to be sure there is still consensus?
[17:48] <gavinh> that sounds a great idea mdiggory.
[17:48] <stuartlewis> Pere: OK - can you revise the project, based on a #1 #2 #3 approach? We can then meet up again like this in 2 weeks time to see how #1 is going, and start looking at #2 (or #3)?
[17:48] <pvillega> mdiggory: that would help a lot, as for what it's been shown, the services would help a lot in integration testing
[17:48] <stuartlewis> mdiggory: Thanks - sounds great. Much appreciated.
[17:48] <mdiggory> yep, it will be a good example for the rest of the community as well
[17:49] <pvillega> stuartlewis: i will update the wiki after the meeting
[17:49] <stuartlewis> Is everyone happy with that as a conclusion? Pere will work on #1 for 3 weeks. Pere will report weekly to gsoc and devel lists. We'll create an svn branch based on trunk for his work.
[17:49] <stuartlewis> We can then meet in 2 weeks to work out where next, and look at what has been completed so far?
[17:49] * sandsfish (~sandsfish@dhcp-18-111-28-197.dyn.mit.edu) Quit (Quit: sandsfish)
[17:49] <pvillega> it seem fair enough to me
[17:50] <mdiggory> pvillega: how much do you need to alter in the codebase itself as opposed to the poms/
[17:50] <gavinh> and if he needs to demo his work, we will provide elluminate conferencing room to enable the sharing,etc... and realtime video/voice.
[17:50] <mdiggory> I will recommend that I'm concerned about the following branching
[17:51] <pvillega> poms, a bit, not too much. Codebase, for unit testing, there should not be any alterations
[17:51] <stuartlewis> gavinh: Thanks :)
[17:51] <pvillega> besides adding the tests themselves
[17:51] <mdiggory> namely that branching can get too far off if there is not a plan for merging back at stable points
[17:52] <stuartlewis> My assumption was we could merge back at the end of each phase? (#1, #2, #3) assuming everyone was happy with the work?
[17:52] <mdiggory> is there any way we can introduce the tests in a "disabled by default" state in the trunk intitially?
[17:52] <pvillega> stuartlewis: that shoould be easy
[17:52] <mdiggory> I assume that testing can be disabled in maven
[17:52] <pvillega> mm i will look into that
[17:53] <stuartlewis> In the background we can also continue our exploratory discussions over a CI server.
[17:53] <pvillega> about merging, should be easy. My question is: should I work with a copy from trunk, or from 1.6.1 tag
[17:53] <mdiggory> pvillega: I would use trunk
[17:53] <kshepherd> +1 trunk
[17:53] <stuartlewis> pvillega: At present, trunk is almost identical to 1.6.1, but trunk will start changing more as we head towards 1.7, so better keep with trunk.
[17:53] <mdiggory> and we need to be mergin backa t those points of stability because others will be integrating as well at the same time
[17:54] <pvillega> ok, trunk then
[17:54] <tdonohue> reminder -- you'll likely need to do two way merging eventually -- trunk will change over time -- so you may need to reload from trunk on occasion as well :)
[17:54] <stuartlewis> Assuming all goes to plan, we'll aim for a first merge in three weeks, so hopefully that won't be too painful.
[17:54] <stuartlewis> Is there much more to discuss, or is the meeting over? (I'll write a summary for the gsoc and devel lists).
[17:55] <mdiggory> tdonohue: right or if you've merged back to trunk... throw way your current branch and start again with a new one.
[17:55] <tdonohue> yep -- exactly, mdiggory
[17:56] <pvillega> stuartlewis: I think this is ok, I have lots of notes and my workplan for the next weeks :)
[17:56] <mdiggory> this has been a great meeting... a good example of what the other students need to be doing as well
[17:56] <mdiggory> and mentors as well
[17:56] <stuartlewis> Assuming we're all happy.... I'd like to say THANKS to everyone who came along and got involved. This has (from my point of view anyway) been a really useful meeting, we've got positive outcomes to work on, and things to think about for the medium term.
[17:56] <pvillega> let me say THANKS too, it helped me a lot :)
[17:56] <tdonohue> also, a reminder that merging *into trunk* will require the code being in front of other committers -- so, it's good to keep these discussions as public as possible (and this is a great start)
[17:56] <tdonohue> yes -- great meeting -- glad to have you on board, pvillega!
[17:57] <gavinh> was very interesting, indeed, thanks all
[17:57] <pvillega> thanks tdonohue ;)
[17:57] <kshepherd> cheers all, this project sounds great
[17:57] <stuartlewis> In my writeup, I'll mention our next meeting in 2 weeks time too.
[17:58] <pvillega> stuartlewis: that will be the 9th of June, isn't it?
[17:58] <stuartlewis> (or the 10th, if you're in one of the world leading countries such as NZ ;) )
[17:58] <kshepherd> ^5
[17:58] <tdonohue> so, that's your spin on it "world leading" :)
[17:59] <stuartlewis> :p
[17:59] <gavinh> world leading? you mean when you are leaving us all in the past?
[17:59] * stuartlewis didn't decide where the date line went! :)
[17:59] <gavinh> also means, you are getting old before the rest of us.
[18:00] <kshepherd> you all get our used-up days
[18:00] <kshepherd> we get fresh ones
[18:00] <gavinh> you are the worlds beta-testers for a day..
[18:00] <tdonohue> it's weird that I talk to future stuartlewis and future kshepherd every day -- I can never keep up, always a day behind
[18:00] <pvillega> but you don't get nice vulcanos closing your air space!
[18:00] <gavinh> if it is bad, we stay in bed and roll over to sleep more.
[18:00] * stuartlewis didn't intend to open this can of worms, and slinks off quietly into the darkness....
[18:00] <kshepherd> heh
[18:01] <pvillega> it's been a great meeting people
[18:01] <pvillega> thanks for coming
[18:01] <tdonohue> ok -- i'm heading offline for the night -- good meeting all. Looking forward to seeing the project progress!
[18:01] * Keith__ (~Keith@207.138.47.158) Quit (Quit: Leaving)
[18:02] <stuartlewis> Bye Tim. Thanks.
[18:02] <kshepherd> yep, i'm off too, thanks all
[18:02] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:02] <gavinh> nn all, may the wind be at your back!
[18:03] * bojans (~Bojmen@91.118.66.139) has left #duraspace
[18:04] <stuartlewis> We have the sun on our faces (morning here), but you can have the winds of destiny to carry you aloft to dance with the stars now it's night for you! :) Good night!
[18:04] <gavinh> thanks
[18:04] <pvillega> good night all! :)
[18:06] <stuartlewis> pvillega: Create an account int trac, and pinkg me once you have, so I can give you appropriate svn commit rights to the branch I'll create for you.
[18:06] <stuartlewis> s/int/in
[18:07] <stuartlewis> s/pinkg/ping
[18:07] * stuartlewis needs a new keyboard like mdiggory
[18:08] <stuartlewis> https://scm.dspace.org/trac/dspace/register
[18:08] <gavinh> hehe
[18:08] <gavinh> some keyboards are so evil.
[18:09] <pvillega> doing, sec :)
[18:10] <pvillega> stuartlewis: account pvillega created, waiting for the confirmation token
[18:11] <pvillega> ok, account verified
[18:13] <stuartlewis> Thanks. Will work the magic my end in the next half hour or so.
[18:16] * gavinh (~root@86-44-107-163-dynamic.b-ras2.bbh.dublin.eircom.net) Quit (Quit: leaving)
[18:27] <pvillega> bye guys, thanks for attending!
[18:27] * pvillega (~pvillega@89.100.155.181) Quit (Remote host closed the connection)
[18:28] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[20:10] * krnl_ (Andrius@193.219.34.106) Quit (*.net *.split)
[20:10] * krnl_ (Andrius@193.219.34.106) has joined #duraspace
[21:11] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) Quit (Ping timeout: 252 seconds)
[21:53] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[22:05] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[22:06] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[22:09] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Ping timeout: 252 seconds)
[22:09] * mdiggory_ is now known as mdiggory
[22:51] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[23:10] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[23:13] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Ping timeout: 260 seconds)
[23:13] * mdiggory_ is now known as mdiggory
[23:21] * ksclarke (~kevin@adsl-162-19-234.clt.bellsouth.net) Quit (Ping timeout: 264 seconds)
[23:49] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.