Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* Guest40911 leaves01:12
* elieab joins03:48
Hello, i have a question about configuring bagit in fedora 4.1.1, can anyone help me plz ?03:49
anyone available please ?07:04
* dwilcox joins07:45
<escowles>elieab: how do you want to use bagit with fedora?07:57
<elieab>sorry just noticed your reply08:01
i came across BagItConnector08:02
and this link: http://mirror.swem.wm.edu/DSDOC-nonear/wiki.duraspace.org/display/FF/How%2Bto%2BProject%2Bover%2BDirectory%2Bof%2BBagIt%2BBags.html
which explains how to federate on a directory containing Bagit bags08:03
the article seems almost 2 years ago
and im wondering if this is still working/supported in 4.1.108:04
* awoods joins08:26
* mikeAtUVa joins08:29
<elieab>Hello, i have a question about configuring BagItConnector in fedora 4.1.1, can anyone help me plz ?08:31
<awoods>ruebot: Could you alternatively make the migration test data available as a direct download from somewhere? (S3?) My DropBox account does not have the available capacity to include your test data as is.
elieab: Of course that depends on the actual question... but I will say that the BagItConnector was a proof of concept about two years ago and has not seen much attention since then.08:32
elieab: where did you come across the connector? in documentation? directly in GitHub?08:33
indeed the article seems almost 2 years old
is there a newer link or document that describe the integration with fedroa 4.1.1 because this one does not seems to work, testcases are failing and the dependency on maven does not exist08:38
<awoods>elieab: That page no longer exists, and the BagItConnector is not supported. I gather you have an interest in such a connector?08:39
<elieab>i was planning to federate over aips generated by archivematica08:40
do you think this makes sense ?
<awoods>elieab: It could make sense, depending on why you want to do that.
<elieab>the content is already there in the archivematica storage.. and it it would be a nice start for them to be accessed and served from fedora08:42
<awoods>elieab: You are thinking the AIPs would be read-only from Fedora's perspective?08:43
<ruebot>awoods: i could zip it up and put it on one of my servers.
<awoods>ruebot: that would be a treat.
<ruebot>awoods: give me a bit and it shall be done.08:45
<awoods>elieab: are you a Java developer?
ruebot: anytime before this weekend would be more that fast enough.
ruebot: anytime before this weekend would be more than fast enough.
<elieab>yes but im new to fedora
<awoods>elieab: Maven? Spring?
<elieab>yes np08:46
<awoods>elieab: great. If you could put some (small amount of) dedicated time to bring the BagItConnector back to life, I an others can offer help and feedback.08:47
elieab: It would be helpful if you defined what you would like the outcome to be.08:48
* dwilcox leaves08:55
* dwilcox joins
* dhlamb joins09:00
<ruebot>awoods: i'll have a link for you in about 40 minutes09:01
<awoods>ruebot: thanks, but no rush.09:02
<ruebot>awoods: zip and rsync. no biggie :-)
<elieab>i certainly dont mind trying to bring BagItConnector back to life, but I dont want to end up the only one using this approach. I would be interested in other approaches that are more common to manage content that did not ever exist in a repository09:05
* acoburn joins09:08
<awoods>elieab: The BagItConnector is currently out of shape. If you have interest in such an integration and can rally interest from the community (fedora-tech@googlegroups.com) it could come back to life. We are in the mode of making existing features tighter, not adding new features. However, maybe there is community interest in a BagItConnector... and it is a way for you to get exposure to Fedora development.09:09
<elieab>awoods: thanks a lot for your support09:12
* elieab leaves09:14
* ajs6f joins09:29
<ruebot>awoods: http://alpha.library.yorku.ca/releases/upgration-test-fixtures.zip09:41
<awoods>ruebot ++
* ksclarke joins09:58
* osmandin joins10:16
* scossu joins10:19
* scossu1 joins10:21
* awoods leaves10:23
* scossu leaves
* whikloj joins10:29
* awoods joins10:36
* awoods leaves10:41
* awoods joins10:56
<ajs6f>The hold music for FreeConferenceCall makes me feel like I'm watching a commercial for Delta airlines sometime around 1989.10:57
* ksclarke leaves
* ksclarke joins
<scossu1>ajs6f: I admire your memory. I would have swapped that out a while ago.10:59
<ajs6f>scossu1: Envy nothing of it. I can't remember what groceries my wife told me to get on the way home, which is _far_ more important.11:00
<scossu1>ajs6f: agreed.11:01
<ajs6f>awoods: Is that "click to expand" thing (which pops out into a bunch of Jira tickets) a macro?11:02
<ajs6f>awoods: That's what I meant.
I am here.
awoods: Me.
<awoods>whikloj: could you take notes for the meeting?11:08
<whikloj>awoods: ok
<awoods>whikloj ++
* pgwillia joins11:28
<ruebot>modsrdf *shudders*11:32
context: https://wiki.duraspace.org/display/hydra/Technical+Metadata+Application+Profile11:37
* github-ff joins11:51
[fcrepo4] escowles pushed 1 new commit to fcrepo-1532: http://git.io/vU9yS
fcrepo4/fcrepo-1532 738d442 Esmé Cowles: Using ebucore:filename for content filename
* github-ff leaves
* mikeAtUVa has an appointment and drops off the call...11:52
<ruebot>awoods: this is the message in the audit trail mappings thread https://groups.google.com/d/msg/fedora-tech/-7xfBGLdAaA/K4jAv5HzpqYJ
* travis-ci joins12:01
fcrepo4/fcrepo4#3645 (fcrepo-1532 - 738d442 : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/538c4315e552...738d442c9362
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/62568093
* travis-ci leaves
<awoods>escowles: yes, it seems that direct access based on UUID is gone.12:09
acoburn: my question from before: is there a way in the karaf console to clear all of the bundles and start from a clean slate?12:10
<dhlamb>awoods: escowles: :( was there a philosophical argument against direct uuid access, or was it just an unutilized feature and so was dropped?12:14
* dwilcox leaves12:15
<f4jenkins>Yippee, build fixed!12:16
Project fcrepo4-release-tests build #210: FIXED in 1 min 27 sec: http://jenkins.fcrepo.org/job/fcrepo4-release-tests/210/
<awoods>dhlamb: let me dig back in the git history. Direct UUID access does, however, seem to subvert some of the LDP concepts.
<dhlamb>awoods: is it becuase the identifier is not a uri?12:21
<awoods>dhlamb: a linked data resource needs a dereferenceable identifier which is its URI. The UUID is not that.12:27
<dhlamb>awoods: makes sense
<awoods>dhlamb: but using the UUID as a unique property on a resource seems reasonable.12:28
<ajs6f>awoods: escowles: dhlamb: Direct access would be gross, LDP or no LDP.
That's why barmintor invented the IdentifierConvertor machinery.
<dhlamb>ajs6f: gross even in the non LDP sense?12:30
<ajs6f>dhlamb: Yep. UUIDs are internal gearing. letting them leak is a recipe for heartburn and melancholy.12:31
<dhlamb>ajs6f: give me the thing identified by X doesn't seem so terrible
ajs6f: true that. i know people aren't gonna like the way they look.
<ajs6f>dhlamb: You must distinguish between "Give me the thingI identify by X", "Give me the thing YOU identify by X", and "Give me the thing WE identify by X".
* dwilcox joins12:32
<ajs6f>dhlamb: When you think about _who_ is doing the identifying, it becomees clear that identifers code responsibilites.
<awoods>ajs6f: currently, we expose the property: "fedora:uuid"
<ajs6f>awoods: I didn't know that. I'd rather not.
<awoods>ajs6f: That property has the value of the ModeShape-generated UUID12:33
<ajs6f>rather not do it, that is.
<dhlamb>is it just a re-branding of jcr:uuid?
<ajs6f>awoods Right. That's letting MODE leak. Just because it's opaque doesn't make it less leaky.
<awoods>dhlamb: yes
<ajs6f>awoods: Is that oozing out of the ontology, too?
<awoods>ajs6f: of course: https://github.com/fcrepo4/ontology/blob/master/repository.rdf#L44512:34
<ajs6f>awoods: Sarcastic "yay".
awoods: having that show up in the onto means that our theoretical Fedora spec will demand that every impl assign and publish UUIDs.12:35
awoods: That is a totally wrong-headed move.
<awoods>ajs6f: There is an outstanding question of whether we want to require UUIDs for each resource12:36
<dhlamb>ajs6f: i'm doing just that
<ajs6f>dhlamb: Doing just what?
awoods: I never heard of this. Who claims we should?
<dhlamb>ajs6f: assigning uuids
<ajs6f>dhalmb: That is totally fine. I'm saying that _Fedora_ should not be requiring you to. If you want to make that choice for yourself, no problem.12:37
<dhlamb>ajs6f: we have a distributed system. it's practically mandatory.
<ajs6f>dhlamb: Not sure I'd agree with that, but I really don't care. If it's _you_ doing it, fine. I just don't want _Fedora_ requiring you to.
Knock yourself out.
<awoods>ajs6f: we apparently are currently claiming we should.12:39
<ajs6f>awoods: Should what?/
<awoods>ajs6f: "should require UUIDs for each resource"
<ajs6f>awoods: Because of the ontology?12:40
<awoods>ajs6f: yes, because of the ontology and our current impl.12:47
<ajs6f>awoods: I think we've never thought this through. We just let MODE leak through.
<awoods>ajs6f: In any case, does having a UUID as a system-generated property make you uncomfortable?12:48
<ajs6f>awoods: Having one, no. Doesn't matter if it did— that's how MODE do. _Publishing_ it? Yes. Especially because we are trying to work out via praxis the theory that will eventually be published as the Fedora spec.12:51
<awoods>ajs6f: would you please create a ticket to remove the exposure of "fedora:uuid"?12:52
<ajs6f>awoods: OMW12:53
<dhlamb>awoods: ajs6f: i'd still like to take advantage of the uuid if it exists. i'm not concerned about its membership in the ontology.12:54
dhlamb: I'm sorry to say this, but I'd like to require you to mint your own.
<awoods>dhlamb: The direction this seems to be going is that a resource UUID will only exist if you (as a fedora user) create your own such property.
<ajs6f>What he said.
<dhlamb>awwods: ajs6f: so no direct access and i still have to make the lookup?
<ajs6f>dhlamb: That way, _when_ we switch out undergirding impl code or rework the use of UUIDs or make them mutable or other things, you're code doesn't explode in tears and fire.
dhlamb: You assign the ID, you can do the lookup. No diff than now, except you mint the ID.
<dhlamb>ajs6f: well, i was trying to avoid the lookup12:58
oh well
<ajs6f>dhlamb: If you want to index identifiers, nothing is stopping you.
<dhlamb>well... let fedora / mode do the lookup for me, at least
<ajs6f>dhlamb: We are really talking about writing a _very_ simple query, no?12:59
<awoods>dhlamb: what lookup were you trying to avoid?
<dhlamb>ajs6f: awoods: yes, it's a simple lookup. just trying to dodge everything i can.13:00
<ajs6f>dhlamb: You can dodge as fast and as well as anyone, but you play with Fedora, you're going to get dirty.13:01
<dhlamb>awoods: i have to line up drupal nodes with fedora nodes. i'm already using drupal uuid's, and was trying to line them up with fedora's instead of having to map.
<ajs6f>dhlamb: I get why you don't want to make life harder now, but I promise you with all of my heart, if you keep your identifiers for durability separate from your identifiers for presentation, _you will end up very happy you did_.13:02
<dhlamb>^ map to path
ajs6f: they're already hidden on the drupal end
you get autoredirected to their autoincrementing id13:03
<ajs6f>dhlamb: No, not hidden, _separate_. Use UUIDs anywhere you want, but don't use the same ones.
ie.e. the same ones between different spaces like the repository and drupal
<dhlamb>ajs6f: well nonetheless, not having direct access by uuid leaves me in the same spot. it's not that terrible.13:04
<ajs6f>dhlamb: I'm really sorry to give you work. But not entirely, because I really am sure that you (or your inheritor) will be glad of it, eventually. It may not even take that long.
<dhlamb>ajs6f: i'll tack drupal uuid's onto my resources and look them up in the triple store if we're getting rid of the fedora ones.13:05
<ajs6f>dhlam: Right on.
<dhlamb>ajs6f: you're not giving me work.
ajs6f: i was planning on doing the lookup before the carrot of direct access by uuid was dangled before me.13:06
ajs6f: awoods bewitched my ears with whispers of xanadu
<ajs6f>dhlamb: That poison carrot. We snatched it away from you only just in time.
<dhlamb>ajs6f: besides, if it offends you, then i'm sure it will offend my clientel as well13:07
<ajs6f>dhlamb: Doubt it. I'm pretty touchy. Ask awoods or barmintor.13:08
<dhlamb>ajs6f: oh, i know others
if i just got into a heated debate with ajs6f and lost, does that make me officially part of the club?13:09
<ajs6f>dhlamb: No one loses a debate with me.13:10
* dhlamb finally belongs!
ajs6f: you're too kind :)
<ajs6f>dhlamb: I'm too interested in Fedora for my own good.13:11
<dhlamb>ajs6f: i'd rebrand that as "passionate"
<ruebot>dhlamb++ ajs6f++13:17
<acoburn>awoods: back13:21
<ajs6f>I think there's a useful rule of thumb available here: UUIDs are unique up to syntax, but not semantics. In other words, you will not have collision problems amongst them, but that fact won't prevent you from having conflation problems. The only way to avoid that is to make explicit the semantic space within which you are situating some given fount of UUIDs. That's what dhlamb is going to do by segregating the Fedora-produced UUIDs from13:22
<awoods>acoburn: I need to step away... I will get your response on the flipside.
acoburn: my question from before: is there a way in the karaf console to clear all of the bundles and start from a clean slate?13:23
<ajs6f>awoods: You can pipe in karaf's shell.13:24
awoods: I.e. pipe ls to uninstall.
<ruebot>mikeAtUVa, dhlamb: are you cool with using a pull request for https://jira.duraspace.org/browse/FCREPO-1538 as a discussion point for what we/have not implemented?13:32
mikeAtUVa, dhlamb: I have a mappings table ready to go, but I'm not confident on how accurate it is, and figured we could use the pull request in GitHub to flesh it out if y'all are cool with it.13:33
<dhlamb>ruebot: works for me13:37
ruebot: now get me a predicate for that uuid!13:38
<ruebot>dhlamb: islandora:thisIsForDhlamb13:39
oh wait...13:40
that's better :-P
<dhlamb>ruebot: you should make an entire ontology just for it
* dhlamb scrambles to find that cat picture you sent me13:41
<dhlamb>ruebot: but srsly, i'm going to index it as that until you send me something appropriate
<ruebot>dhlamb: oh. you're serious. hold on.13:42
dhlamb: http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/#uuid13:46
* jgpawletko joins13:51
* github-ff joins13:57
[migration-utils] ruebot opened pull request #13: First pass at FCREPO-1538 -- adding property mappings to README. (master...FCREPO-1538) http://git.io/vUH5P
* github-ff leaves
<ruebot>awoods: I don't have the option to "start work" on 1538.13:58
<ajs6f>ruebot + dhlamb: How about just dc:identifier?13:59
<acoburn>ruebot: can you see the "Open Issue" button?14:00
<ruebot>acoburn: the "Create issue" button14:02
...yeah, i got that if so
<acoburn>ruebot: then you may need to have awoods change your permissions in jira14:03
ruebot: you can also try logging out and then back in (in case your permissions were changed since you last logged in)
<ruebot>acoburn: i've been able to start work before. maybe it is because it is set to received now.14:04
<acoburn>ruebot: jira is still a bit of a mystery to me14:06
* acoburn leaves14:10
* acoburn joins14:11
* acoburn leaves14:26
<whikloj>awoods: minutes are up14:29
* github-ff joins14:31
[migration-utils] mikedurbin opened pull request #14: Ensured that for each version RELS-INT is migrated last. (master...issue-12) http://git.io/vUQti
* github-ff leaves
<dhlamb>ajs6f: you know, every time i wanna do something like that i think the argument against it is 'someone else may be using it', which makes the re-use of ontologies seem like a slippery slope towards inevitably creating your own15:02
ajs6f: perhaps one day there will be enough obscure ontologies to fill all the gaps
<ajs6f>dhlamb: It is _perfectly fine_ if someone else is using it. Remember, OWA.15:03
<dhlamb>ajs6f: ontario waterpower assocation?
<ajs6f>dhlamb: https://en.wikipedia.org/wiki/Open-world_assumption15:04
<dhlamb>ajs6f: ah, thx
* acoburn joins15:05
<ajs6f>dhlamb: When you work with the OWA, you necessarily disallow the possibility that you control and can limit the semantics of a predicate.
dhlamb: You can _extend_ the semantics of a predicate. But you can't shrink them or limit them.
dhlamb: Because some joker can always come along and publish an assertion about the same damn predicate.15:06
<dhlamb>ajs6f: so just assume that there's more than one dc:identifier, and that one of them is yours?
<ajs6f>dhlamb: Right. There are lots of identifiers. If you know that you put one into play, then you know that one of them is yours.
<dhlamb>dhlamb: well, let's hope no one else puts a v4 uuid in there, then :D15:07
<ajs6f>dhlamb: Well, you can develop a custom predicate islandora:uuid, if you want. But at least publish the claim that islandora:uuid < dc:identifier. Give random people the chance to understand your stuff, without having to talk to you.15:08
dhlamb: Make your assertions machine-actionable.
<acoburn>awoods: ping15:17
* dwilcox leaves15:32
* scossu1 leaves15:34
* scossu joins15:38
* ajs6f1 joins
* ajs6f leaves
<acoburn>awoods: when I'm testing karaf and want to remove all existing bundles, I just remove the entire installation
<ajs6f1>I wonder what that is? The scissors are intrguing15:56
<acoburn>awoods: rm -rf karaf
acoburn: But that toasts _everything_, which for most people won't matter, but might be annoying if you have other customizations.
<acoburn>awoods: what ajs6f1 said15:57
<ajs6f1>acoburn: Earlier today, I said use a pipe in the Karaf shell between `ls` and `uninstall`.
<acoburn>ajs6f1: for _testing_ that's my approach, specifically because I don't want any customizations
<ajs6f1>acoburn/awoods: After all, it is a shell.15:58
acoburn: Tht makes sense. I just want to have a good set of tools in common.
<acoburn>ajs6f1: I tried piping to `uninstall` but that didn't work for me
<ajs6f1>acoburn: Maybe we should try ginning up a patch to `uninstall` to take a flag for everything.15:59
<awoods>acoburn: me neither
<ajs6f1>acoburn/awoods: What did you get?
<acoburn>ajs6f1: I get "no bundles specified"16:00
<awoods>karaf@root()> ls |grep service.id
ajs6f1: gives: service.id = 22
service.id = 9
service.id = 10
service.id = 1
service.id = 2
service.id = 6
ajs6f1: but "cut" is not recognized.
<ajs6f1>awoods/acoburn: Sounds like maybe a patch to `grep` to allow more `sed`-ish behavior.16:01
awoods: Or a new command 'cut'.
<acoburn>ajs6f1: I had been hoping for awk, but that isn't supported
<ajs6f1>acoburn: That would be a pretty sophisticated Karaf command.
<awoods>ajs6f1/acoburn: rm -rf data/*16:02
<ajs6f1>Maybe that's enough.
<awoods>acoburn: the following commands seem to work (no errors), but I would subsequently expect updates to F4 to result in triplestore activity, which does not happen.16:04
$> feature:repo-add mvn:org.fcrepo.camel/fcrepo-camel-toolbox/4.1.2-SNAPSHOT/xml/features
$> feature:install fcrepo-audit-triplestore
acoburn: is that an invalid expectation?
<ajs6f1>awoods: Does `ls` show the expected bundles in ACTIVE state?16:05
* dhlamb leaves
<awoods>ajs6f1: yes
<ajs6f1>awoods: maybe a JMS problem? Like we used to see with confusion between brokers and emitters and listeners coming up in the "wrong" order?16:06
* acoburn1 joins16:07
<awoods>ajs6f1: possibly
<ajs6f1>awoods: Do you see logging from Karaf when you mutate something in the repo?
* acoburn leaves
<acoburn1>awoods: have you looked at the logs?
<awoods>ajs6f1/acoburn1: looking at logs now
acoburn1: is my expectation correct?16:08
<acoburn1>awoods: yes, it is correct
<awoods>acoburn1: how do I pass in system properties to redefine the fcrepo.context?16:10
<acoburn1>awoods: create a file in $KARAF_HOME/etc/org.fcrepo.camel.audit.triplestore.cfg
<awoods>acoburn1: ok16:11
<ajs6f1>Out for the day.
* ajs6f1 leaves
<acoburn1>awoods: you can define any of the properties listed here: https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/tree/master/fcrepo-audit-triplestore
awoods: my mistake, the file should be org.fcrepo.camel.audit.cfg16:12
awoods: see: https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/blob/master/fcrepo-audit-triplestore/src/main/resources/OSGI-INF/blueprint/blueprint.xml#L11
awoods: but we may want to change that if we plan to have multiple audit backends16:13
<awoods>acoburn1: the odd thing is that I the process is trying to call back into F4.
acoburn1: the audit triplestore module should not need to call back into F4.16:14
<acoburn1>awoods: can you gist the error log?
awoods: you are correct, that it should not be calling back to fcrepo
<awoods>acoburn1: https://gist.github.com/awoods/7b11c688f7d407ece49f16:19
acoburn1: I need to jump on a quick call
<acoburn1>awoods: ok, those errors are from fcrepo-indexing-triplestore, which appears to be installed16:21
* escowles leaves16:23
* osmandin leaves16:25
<acoburn1>awoods: https://gist.github.com/awoods/7b11c688f7d407ece49f#file-karaf-log-L41916:26
awoods: this shows that the audit service is working properly
awoods: it's the fcrepo-indexing-triplestore service that's causing all the problem16:27
awoods: you don't by any chance have a jarfile sitting in $KARAF_HOME/deploy16:28
<awoods>acoburn1: back16:38
acoburn1: the deploy directory is empty16:39
<acoburn1>awoods: if you type bundle:list, do you see fcrepo-indexing-triplestore
<awoods>acoburn1: and the test associated with the gist I sent you resulted in good audit records in the triplestore16:40
126 | Active | 50 | 4.1.2.SNAPSHOT | fcrepo-indexing-triplestore
127 | Active | 50 | 4.1.2.SNAPSHOT | fcrepo-audit-triplestore
128 | Active | 50 | 4.1.2.SNAPSHOT | fcrepo-audit
<acoburn1>awoods: so how is fcrepo-indexing-triplestore getting installed?
<awoods>acoburn1: I just nuked data/* again16:41
acoburn1: starting from scratch
acoburn1: bundle:list comes back empty
acoburn1: I think we are good... I must have installed indexing-triplestore last time.16:44
<acoburn1>awoods: excellent!
<awoods>acoburn1: your PR is now verified
acoburn1: thanks for muscling through it.
<acoburn1>awoods: I think you did more muscling that I16:45
* github-ff joins16:47
[fcrepo-camel-toolbox] awoods pushed 1 new commit to master: http://git.io/vU7Og
fcrepo-camel-toolbox/master efcb7b7 Aaron Coburn: Add maven configuration for feature.xml generation...
* github-ff leaves
<awoods>acoburn1: I notice that the blueprint.xml files have slightly different values than the application.properties file.16:48
acoburn1: It would be nice if they did not have to be maintained separately.
<acoburn1>awoods: where are they different?
acoburn1: the default values are different. that is all.
<acoburn1>awoods: ah yes, those should be aligned16:51
awoods: would you like a pull request?
<awoods>acoburn1: but the blueprint takes on the value of the application.properties?
<acoburn1>awoods: no
awoods: application.properties is for the war file16:52
awoods: and the blueprint values are used only in OSGi deployments
awoods: so the war deployment never sees the blueprint.xml files
* mikeAtUVa leaves
* travis-ci joins
<awoods>acoburn1: but it seemed that values were not passed into the web deployment if there was not also a line with a given property also in the blueprint.
<travis-ci>fcrepo4-labs/fcrepo-camel-toolbox#74 (master - efcb7b7 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/compare/0305887bfbe3...efcb7b70be6a
Build details : http://travis-ci.org/fcrepo4-labs/fcrepo-camel-toolbox/builds/62608917
* travis-ci leaves
<awoods>acoburn1: are you saying they are completely detached from each other?16:53
<f4jenkins>Project fcrepo-camel-toolbox build #85: UNSTABLE in 5 min 37 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-toolbox/85/
awoods: Add maven configuration for feature.xml generation
<acoburn1>awoods: I thought they were, but let me check…
* github-ff joins16:54
[fcrepo-camel-toolbox] awoods closed pull request #21: added maven configuration for feature.xml generation (master...fcrepo-1479) http://git.io/vUeEK
* github-ff leaves
<acoburn1>awoods: for the warfile, the camelContext is defined in applicationContext.xml
awoods: https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/blob/master/fcrepo-camel-webapp/src/main/webapp/WEB-INF/applicationContext.xml
awoods: which references the org.fcrepo.camel classes directly without reference to the OSGi blueprint configuration16:55
awoods: that is, they only share the java classes, none of the configuration
<awoods>acoburn1: maybe the errors I saw related to integration tests.
<acoburn1>awoods: which errors?16:56
<awoods>acoburn1: definitely the build was not happy when I aligned properties across the three modules in the recent PR: https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/commit/3b012c7465f85000cfae34d2b74c89cb82c81c1d16:57
acoburn1: the errors were probably related to integration tests.
<acoburn1>awoods: I'll take a look16:58
<awoods>acoburn1: In any case, it would be good if properties were defined in blueprint.xml or in application.properties. If we use both files for the same properties, they will continue to be slightly different with subsequent commits.
<acoburn1>awoods: the issue is that the properties are tied to the deployment context17:00
awoods: if that deployment context is OSGi, then the properties are defined in a <context-id>.cfg file
awoods: with some sensible defaults in blueprint.xml
awoods: and the properties are scoped to the service (so you can define input.stream to be one thing for fcrepo-indexing-solr and something else for fcrepo-audit-triplestore)17:01
<awoods>acoburn1: Maybe the best we can do for now is add a comment in the various property files noting other files that should be updated on subsequent changes.
<acoburn1>awoods: that makes sense to me17:02
awoods: I agree that it seems a little messy with separate config files
<awoods>acoburn1: scoping is a slightly different issue, as in the web context they currently share property names (as you have previously noted).
<acoburn1>awoods: maybe ajs6f will have some ideas tomorrow
* dhlamb joins17:16
<awoods>acoburn1: we should probably use the same system property swapping in blueprint.xmls that are used in application.properties as well.17:25
<acoburn1>awoods: you mean the spring syntax: ${spring.value:default}17:26
<awoods>acoburn1: yes
<acoburn1>awoods: I have never been able to get that to work
awoods: I'm not against it, it's just that I've tried to use system values like that and (as I recall) it never worked properly17:27
<awoods>acoburn1: ok
* acoburn1 leaves17:38
* github-ff joins17:55
[migration-utils] awoods pushed 2 new commits to master: http://git.io/vU7yn
migration-utils/master 3517f21 Mike Durbin: Ensured that for each version RELS-INT is migrated last.
migration-utils/master b053cfe Andrew Woods: Merge pull request #14 from mikedurbin/issue-12...
* github-ff leaves
* dhlamb leaves17:58
* pgwillia leaves18:37
* scossu leaves18:45
* ksclarke leaves18:58
* scossu joins19:42
* scossu leaves19:45
* scossu joins20:00
* scossu leaves20:04
* ksclarke joins20:53
* dhlamb joins21:52
* ksclarke leaves21:54
* ksclarke joins
* awead_away leaves22:17
* awead joins22:20
* jgpawletko leaves22:54
* dhlamb leaves23:00

Generated by Sualtam