Timestamps are in GMT/BST.
[3:07] * mdiggory (~mdiggory@72.199.216.7) Quit (Quit: mdiggory)
[5:02] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[5:10] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[6:47] -kornbluth.freenode.net- *** Looking up your hostname...
[6:47] -kornbluth.freenode.net- *** Checking Ident
[6:47] -kornbluth.freenode.net- *** Found your hostname
[6:47] -kornbluth.freenode.net- *** No Ident response
[6:47] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:47] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:47] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:09] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:35] * cwilper (ad55a88f@gateway/web/freenode/ip.173.85.168.143) has joined #duraspace
[12:56] * ajs6f (89369ba5@gateway/web/freenode/ip.137.54.155.165) has joined #duraspace
[13:02] * elschlomo (~ruckus@HSI-KBW-046-005-164-187.hsi8.kabel-badenwuerttemberg.de) has joined #duraspace
[13:02] * barmintor (~barmintor@cpe-72-229-190-215.nyc.res.rr.com) has joined #duraspace
[13:06] * tecoripa (~sprater@saez.doit.wisc.edu) has joined #duraspace
[13:06] <elschlomo> thanks ben! i still have problems associating voices with names correctly ;)
[13:06] <barmintor> FCREPO Committers meeting starting with discussion of managed projects
[13:07] * tecoripa (~sprater@saez.doit.wisc.edu) has left #duraspace
[13:07] <barmintor> Problem: Coordinating limited resources for more ambitious, bigger projects
[13:08] <barmintor> How do we "sell" a vision of these projects to management at installation sites to garner development resources
[13:09] * tecoripa (~sprater@128.104.62.84) has joined #duraspace
[13:09] <barmintor> Google Summer of Code? Kickstarter?
[13:10] <barmintor> Jonathan proposes managed projects: Larger projects guided by a specific institutional partner
[13:11] <barmintor> Jonathan: Managed OSS projects come with risks, but also potential
[13:12] <barmintor> Jonathan: is most familiar with managed projects in which interested institutions collaborate on a scope of work, either with monetary or in-kind contributions
[13:13] <barmintor> Risks: 1. Out-of-control scope; 2. Too much removal from regular developer community -> poor integration
[13:13] <barmintor> Jonathan: Must have a process that includes the committer team in evaluating and tracking the work and its progress
[13:14] <barmintor> Jonathan: There are probably good opportunities for Fedora managed projects, but who would initiate?
[13:14] <barmintor> Jonathan: Need participation from commuter groups and steering group over the life of the project
[13:14] <barmintor> s/commuter/committer/
[13:14] <kompewter> barmintor meant to say: Jonathan: Need participation from committer groups and steering group over the life of the project
[13:15] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[13:15] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[13:15] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[13:15] <barmintor> Jonathan: Such projects have been led by Duraspace, by partner institutions, and by invested vendors
[13:16] <barmintor> Jonathan: Defining scope is key- must be manageable, and not overly ambitious
[13:18] <barmintor> Ben: Consider FESL. Is that what we're trying to do? How did that go?
[13:18] <barmintor> Chris: That project was too removed from the regular developers, but under much pressure to deliver *something*
[13:19] <barmintor> Chris: probably needed more ongoing committer review
[13:20] <barmintor> Scott: Recently had an experience as a consultant on another project in similar circumstances
[13:20] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[13:20] <barmintor> Scott: Looking back on that experience, risk of not integrating with regular developers is great
[13:21] <barmintor> Scott: That said, distance is not necessarily bad. Coders typically have varying levels of commitment, anyway (GSoC)
[13:22] <barmintor> Scott: Projects can probably be successful if there is a committer that cant review along with institutional mgmt and the actual developers
[13:23] <barmintor> Jonathan: Would like managed projects to be somewhat larger in scope
[13:24] <barmintor> Jonathan: Idea is to direct more substantial resources towards projects that might otherwise be unachievable
[13:25] <barmintor> Chris: 1. Projects must be scoped, but 2. big projects need to be done
[13:26] <barmintor> Chris: For example, "Do 4.0" is too broad in scope for a managed project, but maybe single feature/suites from the 4.0 bucket might be
[13:26] <barmintor> Adam: On the other hand, Fedora 2.0 *was* done under such a rubric
[13:27] <barmintor> Adam: Appropriate scope is tied to the managerial resources
[13:27] <barmintor> Adam: Not clear on where the ideas are generated. From community through magic? From institutions who vote with resources?
[13:28] <ajs6f> s/magic/wizardry
[13:28] <barmintor> Chris: Committers have some sense of needs from being closer to code/lists/etc. but should go to large stakeholders and solicit guidance
[13:29] <barmintor> Scott: On Evergreen project, institutions would submit written proposals to be vetted by committers, at which point resource support was arranged
[13:30] <barmintor> Chris: There needs to be that kind of buy-in
[13:30] <barmintor> Adam: and the efforts needs to be visible to the community
[13:30] <barmintor> Jonathan: Is there a fairly well-understood list of requested features/needs?
[13:31] <barmintor> Adam: Would actually need some time to convert sense of needs to actual technical requirements
[13:31] <barmintor> Adam: Sometimes we need to communicate the underlying requirements of frequently-requested features
[13:32] <barmintor> Eddie: Do we have a sense of the kind of resources we're discussing?
[13:32] <barmintor> Eddie: Fedora 2 was 4+ FTE effort- do we imagine that level of investment?
[13:32] <tecoripa> sample proposal: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:proposal:patron_statistical_categories -- scope, requirements, etc. (this was a document that evolved, BTW)
[13:32] <kompewter> [ dev:proposal:patron_statistical_categories [Evergreen DokuWiki] ] - http://evergreen-ils.org/dokuwiki/doku.php?id=dev:proposal:patron_statistical_categories
[13:33] <barmintor> Eddie: FESL was ~$20k in funding, but resulted in dispersed accountability that made project difficult to define/pursue
[13:34] <barmintor> Jonathan: Projects should be proposed with more than one possible scope, and see where is sufficient interest to form steering groups, establish funding, etc.
[13:35] <barmintor> Jonathan: Vette ideas, do initial scoping, estimate resources, then shop proposals for funding to partners
[13:35] <barmintor> Jonathan: Management must be effective enough to make sure sufficient resources are assembled for the effort
[13:36] <barmintor> Eddie: That makes sense, and I think managed projects are a great idea, but I'm concerned about practicable scopes
[13:36] <barmintor> Eddie: and what the structure is for soliciting resources
[13:38] <barmintor> Jonathan: You could try to pursue grant monies, but the circumstances would have to be appropriate (i.e., a related project that needs features from Fedora)
[13:38] <barmintor> Scott: Who would be doing the work of turning an idea in the community into a shop-able proposal
[13:39] <barmintor> Jonathan: thinks the committer group is in the best position to create a scope-of-work, but Duraspace or a lead institution could shop the proposal around
[13:40] <barmintor> Adam: In addition to scope difference (Fedora 2 vs. FESL), there was also a difference in unity of vision (FESL had "many cooks")
[13:41] <barmintor> Adam: Can avoid problem perhaps by giving some weight to consortial user's needs (Islandora, Hydra, APT Trust, etc.)
[13:41] <barmintor> Jonathan: imagines something like this evolving by starting with a scoped piece of work in which committers are confident of success
[13:42] <barmintor> Jonathan: then finding a community member interested in seeing proposal enacted
[13:42] <barmintor> Jonathan: Those institutions would begin project team and fund-raising
[13:43] <barmintor> Jonathan: stakeholders on steering committee would shape work, and committers should be involved, probably also Duraspace, and the project manager
[13:43] <barmintor> Jonathan: Whatever methods are used, vital to establish management for the project
[13:44] <barmintor> Jonathan: Must be a way to mediate development resources by committers and invested institutions
[13:44] <barmintor> Jonathan: We might approach Sakai and JA-SIG for experience in this arena
[13:45] <barmintor> Adam: If this is to go forward, committer calls may not be most appropriate forum for creating/discussing proposals
[13:45] <barmintor> Adam: If this is to go forward, we should be more aggressive in soliciting community involvement in the proposal-creation venue
[13:46] <barmintor> Scott: We would also need to solicit ideas from the users list
[13:49] <barmintor> Ben: If we can't always have resources for doing projects, will we have resources for oversight/integration?
[13:50] <barmintor> Adam: It has been difficult to get time already, even for integrating GSoC proejects
[13:50] <barmintor> s/oe/o/
[13:50] <kompewter> barmintor meant to say: Adam: It has been difficult to get time already, even for integrating GSoC projects
[13:51] <barmintor> Jonathan: Having seen some dysfunctional efforts in this vein, it is important to learn from mistakes, identify what necessary elements are to succeed in early planning
[13:52] <barmintor> Jonathan: perhaps should begin fairly small, to develop sense of necessary support resources
[13:52] <barmintor> Adam: There is some value in the proposal-generation process regardless, and that should go forward
[13:53] <barmintor> Chris: Before setting up a big project-handling infrastructure, we should do some "pathfinding" with (smaller?) project or two to get a sense of what works.
[13:54] <barmintor> Chris: We might just begin with ideas (from the 4.0 bucket?) to shape into proposals
[13:55] <barmintor> Chris: Maybe begin with a project or two, without aiming to already have in place the ultimate structure for *all* projects
[13:55] <barmintor> Chris: We could use some upcoming commuter call time to work some of this out
[13:55] <barmintor> Adam: It would be silly for us not to coordinate in advance!
[13:56] <barmintor> Chris: We need to provide a vision that partners will be attracted to
[13:57] <barmintor> Chris: It would be hard to go to community only with a broad solicitation
[13:58] <barmintor> Ben: But it would be easy to get specific ideas from, e.g., Hydra Steering, APT Trust, Discovery Garden, etc.
[13:59] <barmintor> Eddie: Also, we should use an effort like this to figure out where community might be grown if certain shortcomings were addressed
[14:00] <barmintor> Adam: For such outside groups, either committers or Duraspace likely have to speak up
[14:01] <barmintor> Jonathan: DGI might be interested, perhaps Mediashelf, in engaging with potential clients for gap identification
[14:02] <barmintor> Eddie: Agrees with suggestion that it would be valuable to start with a smaller project, and try to build off achievable "wins"
[14:02] <barmintor> Eddie: Thinks that DGI and MS probably can get a sense of barriers to adoption
[14:03] <barmintor> Eddie: Managed projects need to be continuing, and pool of projects/resources must support that
[14:04] <barmintor> Jonathan: Try to compile different lists of interested non-adopters, adopters struggling with current architecture, and identify some low-hanging fruit
[14:05] <barmintor> Adam: Where can we generate, compile, organize these ideas?
[14:06] <barmintor> Eddie: Let us not have another call.
[14:07] <barmintor> Adam: Wants to ensure this is understood as an open process, and not a way for committers to ask for money
[14:07] <eddies> big thanks to ben for the furious note-taking =)
[14:08] * barmintor blushes
[14:10] * tecoripa (~sprater@128.104.62.84) has left #duraspace
[14:12] * elschlomo (~ruckus@HSI-KBW-046-005-164-187.hsi8.kabel-badenwuerttemberg.de) Quit (Ping timeout: 260 seconds)
[14:28] <barmintor> Talk to you folks next week!
[14:28] * barmintor (~barmintor@cpe-72-229-190-215.nyc.res.rr.com) Quit (Quit: barmintor)
[14:31] * cwilper starts office hours: https://wiki.duraspace.org/display/~cwilper/Fedora+Office+Hours
[15:23] * elschlomo (~ruckus@HSI-KBW-046-005-164-187.hsi8.kabel-badenwuerttemberg.de) has joined #duraspace
[15:25] <elschlomo> Chris as you were offering help on IRC i was wondering if you can tell me how to run integration tests only..i tried doing "mvn integration-test" in ./fcrepo/fcrepo-integration fcrepo/fcrepo-integrationtest/fcrepo-integrationtest-configB
[15:26] <elschlomo> is this the right way to do it? becaus ei can see a tomcat spinning up but it seems not to react to any request and ingesting the demo objects takes ages...
[15:27] <elschlomo> according to JConsole theres not much done in the process
[15:27] <elschlomo> main thread seems to be hangin at Socket.accept as if no requests are send to him
[15:27] <cwilper> Hmm, I usually do all tests from root via "mvn clean install". But that does take forever. I'm pretty sure Aaron set it up to allow individual tests to be run...let me see...
[15:28] <elschlomo> thanks
[15:30] <cwilper> Ok, if the README is to be believed (heh), you should be able to specify -Dconfig=B when doing a mvn verify/install/deploy in order to run only a single suite at a time. If that's what you want, try from root, "mvn install -Dconfig=B"
[15:30] <elschlomo> argg my bad i had another tomcat process leftover from a failed run...
[15:31] <elschlomo> ok ill try that
[15:31] <cwilper> In addition, you can do -Dit.test=full.package.and.class.Name to run a specific class
[15:31] <elschlomo> but it seems the test are running fine now..
[15:31] <elschlomo> so doing a mvn integration-test from the corresponding folder might actually work ;)
[15:32] <cwilper> ahh ok. I usually don't experiment much with how to run the tests because it's a huge time investment just to run them.
[15:33] <elschlomo> yepp and it kind of sucks that the integration tests for trippi are in the fcrepo project so you have to update the dependencies...
[15:33] <elschlomo> well they alwys tell me branching is easy with git
[15:36] <cwilper> not sure which trippi integration tests you're referring to. The only ones I know of are are in the trippi project.
[15:36] <elschlomo> ahhh this is prefect -Dit.test=....
[15:43] * ajs6f (89369ba5@gateway/web/freenode/ip.137.54.155.165) Quit (Ping timeout: 245 seconds)
[15:57] <elschlomo> can oyu tell me hat the difference between the packages org.fcrepo.trippi and org.trippi is? the trippi prject i checked out is org.trippi.trippi-core bur fedora uses org.fcrepo.trippi.trippi-core...
[15:58] <elschlomo> just a difference of name?
[16:09] <cwilper> hmm...oh, org.fcrepo.trippi might be a groupId
[16:10] <cwilper> no, the groupId is org.trippi. So I'm wondering where you're seeing org.fcrepo.trippi?
[16:11] <cwilper> The trippi *project* is at github.com/fcrepo/trippi, but that doesn't have an effect on its groupId or package name.
[16:14] <elschlomo> right but in fcrepo-server the dependency in the pom is:
[16:14] <elschlomo> <dependency>
[16:14] <elschlomo> <groupId>org.fcrepo</groupId>
[16:14] <elschlomo> <artifactId>trippi-core</artifactId>
[16:14] <elschlomo> </dependency>
[16:15] <elschlomo> sry was talking about packages but of course i mean grouIDs
[16:15] <elschlomo> and in trippi it's :
[16:15] <elschlomo> <groupId>org.trippi</groupId>
[16:15] <elschlomo> <artifactId>trippi</artifactId>
[16:15] <elschlomo> <version>1.5.7-SNAPSHOT</version>
[16:17] <elschlomo> https://github.com/fcrepo/fcrepo/blob/master/pom.xml
[16:17] <kompewter> [ fcrepo/pom.xml at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/pom.xml
[16:17] <cwilper> Ok, yeah, that's confusing. Here's the story.
[16:17] <elschlomo> https://github.com/fcrepo/trippi/blob/master/pom.xml
[16:17] <kompewter> [ trippi/pom.xml at master · fcrepo/trippi · GitHub ] - https://github.com/fcrepo/trippi/blob/master/pom.xml
[16:18] <cwilper> Back before fedora was mavenized, we decided we needed to put many of our third-party dependencies within the "org.fcrepo" groupId. So you'll see mulgara is also like that.
[16:19] <elschlomo> ok so i can just do a mvn install -DGroupId=org.fcrepo ....?
[16:19] <cwilper> Basically anything we couldn't find in other maven repos, we uploaded to the duraspace m2 repo and put it under the org.fcrepo groupId as a way to say "we are responsible for this third-party dependency"
[16:20] <cwilper> But where we *need* to go ultimately is to have all those dependencies in central, with their proper groupIds, not using org.fcrepo, but, for example, using a groupId that more accurately reflects the real package name. For example, org.trippi, org.mulgara, etc.
[16:22] <cwilper> I'm not sure what you're trying to do. Usually you don't have to do a "mvn install -DgroupId=..." unless maven can't find a dependency *anywhere*. But the trippi libs should be available in the duraspace m2 repo.
[16:23] <elschlomo> ah yes but im working on fcrepo-1023 which includes an update to Trippi's SparqlTupleWriter, and for running an integration test versus my snapshot i have to change fcrepo's dependencies for including the new trippi version i built.
[16:24] <elschlomo> so im installing the trippi jar i built using mvn install:install-file with another groupId
[16:27] <elschlomo> so the fcrepo integration tests use the updated version from my local repository
[16:27] <cwilper> ok, that makes sense. Yes, you'd need to install locally that way in order to test your new version. Then when the time comes (after tests are passing), we'd need to publish your new jar to the duraspace m2 repo alongside the other trippi versions: https://m2.duraspace.org/content/repositories/releases/org/fcrepo/trippi-core/
[16:27] <kompewter> [ Index of /content/repositories/releases/org/fcrepo/trippi-core/ ] - https://m2.duraspace.org/content/repositories/releases/org/fcrepo/trippi-core/
[16:29] <cwilper> This would be a lot easier if the trippi project artifacts were hosted at sonatype, with the correct groupId (org.trippi).
[16:30] <cwilper> Then we could even set up Bamboo to auto-deploy snapshot builds to the sonatype snapshot repo, as has been done with a few other projects.
[16:30] <elschlomo> indeed and the process to have a jar available on central is very easy, i did this with 3 emails...
[16:30] <elschlomo> hmm this would be nice...
[16:31] <cwilper> So all you'd need to do is commit (and push) trippi changes, and update the fedora pom to point to the -SNAPSHOT version.
[16:31] <elschlomo> having an "official" build history for all the commits on master...
[16:32] <elschlomo> so a bamboo built would also be triggered by a commit to github?
[16:33] <cwilper> yes. and that bamboo build could do a normal set of tests, but could also send the snapshot jar to the sonatype snapshot repo if all tests passed.
[16:33] <elschlomo> it certainly beats installing dependencies locally by hand ;)
[16:34] <cwilper> wait just a minute. Eddie already started this process for trippi!
[16:34] <cwilper> I had forgotten. See http://search.maven.org/#search%7Cga%7C1%7Ctrippi
[16:34] <kompewter> [ The Central Repository Search Engine ] - http://search.maven.org/#search%7Cga%7C1%7Ctrippi
[16:36] <elschlomo> but the auto build on commit and SNAPSHOT publishing isnt done yet, right?
[16:37] <cwilper> But Fedora's pom doesn't point to that version of trippi, for one. And yes, the auto build and snapshot deployment isn't done.
[16:38] <cwilper> Also, the version declared in trippi's current root pom, 1.5.6-SNAPSHOT is clearly wrong if 1.5.6 has already been published to central. So first things first, trippi's root pom version needs to be changed to 1.5.7-SNAPSHOT
[16:38] <elschlomo> heh didn't even notice that ;)
[16:39] <elschlomo> hmm but my root pom has 1.5.7-SNAPSHOT....
[16:39] <elschlomo> as do all the children
[16:40] <cwilper> hmmm...did you make that change on your branch then? 'cause I just did a pull from master and it still says 1.5.6-SNAPSHOT
[16:41] <elschlomo> hmm i cant rememeber doing this, but i tend to forget things ;)
[16:41] <elschlomo> https://github.com/fcrepo/trippi/blob/master/pom.xml
[16:41] <kompewter> [ trippi/pom.xml at master · fcrepo/trippi · GitHub ] - https://github.com/fcrepo/trippi/blob/master/pom.xml
[16:41] <elschlomo> this says 1.5.7-SNAPSHOT...
[16:42] <cwilper> Just saw that. Somehow my local repo isn't updating. Time to blow it away and start fresh.
[16:42] <elschlomo> fetch instead of pull?
[16:43] <elschlomo> i always do this, and wonder were my changes are, rewrite them , and when commiting it merges them automatically with the same changes ive done before ;)
[16:43] <elschlomo> just happenend my with fcrepo 1023 again...
[16:44] <cwilper> i guess i thought a pull would get everything from upstream. confusing that it didn't. maybe fetch would, but starting fresh works too :)
[16:44] <elschlomo> hmm might actually make an alias mor git fetch ;)
[16:45] <elschlomo> yes pull is the good one ;)
[16:45] <elschlomo> fecth just updates the local repo but no checkout
[16:46] <cwilper> ok, so eddie has already updated trippi's pom so it's set up to deploy to sonatype. Fun fact: if either of us had permission on the org.trippi groupId at sonatype, we could just run a "mvn deploy" and I think that would deploy the snapshot.
[16:47] <elschlomo> nice gonna have to ask him next week about this...
[16:48] <cwilper> So there are two more things that need to be done before this can all be automated: 1) We need permission at sonatype, and 2) We need to make sure Fedora's pom is pointing to the new trippi...the one at central, 1.5.6, to verify that the central copy is in good working order.
[16:49] <cwilper> Let me see if I can find the sonatype ticket for org.trippi...that's how you request permission.
[16:49] <elschlomo> yes and im guessing it's possible to have different permissions for SNAPSHOTS and relseases, so some level of security about the implementation can be provided
[16:50] <elschlomo> btw have you ever had duplicate class errors when doing a "mvn install" in the root dir of fedora?
[16:50] <cwilper> Usually they just give you permission for both.
[16:50] <elschlomo> im getting these Compilation failures now:
[16:50] <elschlomo> duplicate class: org.fcrepo.client.APIAStubWrapper
[16:51] <elschlomo> think this has something to do with generated classes, but i have no expertise there, i tend to write my own stuff..
[16:51] <elschlomo> it happens during the build of the admin-client
[16:51] <cwilper> Duplicate class errors...hmm. Not that I can recall. You may have to manually delete a source directory...this is related to something Ben did recently.
[16:52] <elschlomo> ah ok, so just delete generated-sources in the admin client?
[16:53] <elschlomo> or is it the dir stubwrappers? sounds suspicous
[16:53] <cwilper> yes, any directory in there that says "generated"...i can't remember the exact name(s). Stuff under target/ would be removed automatically via clean, but there was an outlier.
[16:54] <cwilper> stubwrappers, yep, that's it!
[16:54] <elschlomo> thanks!
[16:58] <cwilper> eddies: can you request to add cwilper as an authorized releaser to the sonatype ticket for org.trippi?
[16:59] <eddies> cwilper: remind me what i need to do for that? =(
[16:59] <eddies> s/=(/=)
[16:59] <kompewter> Got an error.
[16:59] <eddies> s/=\(/=\)
[16:59] <kompewter> eddies meant to say: cwilper: remind me what i need to do for that? =\\)
[16:59] <eddies> heh
[16:59] <cwilper> lol, poor kompewter
[16:59] <cwilper> Just add a comment to https://issues.sonatype.org/browse/OSSRH-2943
[16:59] <kompewter> [ [#OSSRH-2943] Trippi Triplestore API - Sonatype JIRA ] - https://issues.sonatype.org/browse/OSSRH-2943
[17:00] <tdonohue> you broke kompewter! ;)
[17:00] <elschlomo> oh and another question in SparqlTupleWriter at line 55 there's a null check which rites bound=false to a SPARQL response. I didn't find anything about null nodes in the SPAQRL result format spec, do you have a tip on how to handle those null nodes?
[17:00] <elschlomo> https://github.com/fcrepo/trippi/blob/master/trippi-core/src/main/java/org/trippi/io/SparqlTupleWriter.java
[17:00] <kompewter> [ trippi/trippi-core/src/main/java/org/trippi/io/SparqlTupleWriter.java at master · fcrepo/trippi · GitHub ] - https://github.com/fcrepo/trippi/blob/master/trippi-core/src/main/java/org/trippi/io/SparqlTupleWriter.java
[17:00] <cwilper> Also, frank, if you don't already have a sonatype account, you can sign up via https://issues.sonatype.org/secure/Signup!default.jspa
[17:00] <kompewter> [ Sign up for JIRA - Sonatype JIRA ] - https://issues.sonatype.org/secure/Signup!default.jspa
[17:01] <elschlomo> i should have one, if onyl i can remember ;)
[17:01] <cwilper> (will be on a call for a bit...my typing's going to slow down)
[17:01] <eddies> cwilper: comment added
[17:01] <elschlomo> k
[17:01] <cwilper> eddies: thanks
[17:04] <elschlomo> ah yes im "smeg4brains" @ sonatype
[17:06] <elschlomo> hah nice got it running and my integration test fails as expected....
[17:20] <elschlomo> ok im off for today, can already smell the barbecue, thanks for the help, and have fun!
[17:20] * elschlomo (~ruckus@HSI-KBW-046-005-164-187.hsi8.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[21:05] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:12] * cwilper (ad55a88f@gateway/web/freenode/ip.173.85.168.143) Quit (Quit: Page closed)
[21:12] * ajs6f (89369ba5@gateway/web/freenode/ip.137.54.155.165) has joined #duraspace
[21:14] * ajs6f (89369ba5@gateway/web/freenode/ip.137.54.155.165) Quit (Client Quit)
[21:51] * 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.