Members present: dglachs, wastl, westei, jfrank, wikier ---------------- Meeting summary: ----------------
1. Preface a. https://issues.apache.org/jira/browse/STANBOL-924 (westei, 1) b. wastl will update the documentation about the stanbol integration (wikier, 1) c. https://code.google.com/p/lmf/wiki/ModuleStanbol (wikier, 1) -------- Actions: -------- - wastl will update the documentation about the stanbol integration (wikier, 09:27:48) IRC log follows: # 1. Preface # 09:13:25 [wikier]: topics? 09:13:25 [wastl]: my only topic for today is the stanbol integration 09:13:33 [wikier]: testing testing testing 09:13:48 [jfrank]: lucy is waiting for stanbol... 09:13:50 [wikier]: poor lucy 09:14:10 [wastl]: so there is a stanbol part for lucy? 09:14:19 [jfrank]: not yet. 09:14:48 [wastl]: I am almost done, at least it feels like "almost there", but with Stanbol and OSGi you never know if there is another peak to climb behind what you see 09:15:10 [wastl]: progress report: 09:15:28 [wastl]: - there is now a running "stanbol-embedded" that can also be used indepenedently from the LMF 09:15:48 [wastl]: - I am currently in the process of adapting to the new configuration and engines used by the latest Stanbol release 09:16:18 [wastl]: - most notably, the keyword linking engine has disappeared and is replaced by the EntityhubLinkingEngine 09:18:19 [wastl]: that's it :) 09:18:33 [wastl]: I expect to merge back the branch at about lunchtime 09:18:48 [westei]: I am working on STANBOL-924 to fix some issues with running Stanbol in an Embedded OSGI environment 09:19:03 [westei]: #link https://issues.apache.org/jira/browse/STANBOL-924 09:19:43 [wastl]: yes, this was another issue :) 09:19:56 [wastl]: I had to patch the enhancer servicesapi 09:19:57 [wikier]: so no stable by the end of this week? 09:20:03 [wikier]: I mean, stanbol 09:20:10 [wastl]: no, it will use the stanbol snapshot 09:20:11 [wikier]: released 09:20:18 [wikier]: ok 09:20:20 [wastl]: there is no way around it 09:20:33 [wastl]: but it makes almost no difference 09:20:35 [wikier]: sure 09:20:42 [wikier]: not for lmf 09:20:55 [wikier]: but for marmotta it will 09:21:25 [westei]: Marmotta will not depend on Stanbol. It is much more likely the Stanbol will depend on Marmotta 09:22:58 [wastl]: yes 09:23:05 [wastl]: only the LMF will contain the stanbol integration 09:23:20 [wastl]: and the stanbol integration is an aggregated jar file 09:23:28 [wastl]: only the bundles inside are currently snapshots 09:23:37 [wastl]: not the jar itself 09:23:59 [wastl]: the architecture is currently like this: 09:24:13 [wastl]: - stanbol-embedded-XXX.jar: 09:24:35 [wastl]: - support classes for setting up EmbeddedStanbol 09:24:57 [wastl]: - merged in all stanbol API classes that should be accessible outside OSGi (i.e. mostly interfaces) 09:25:19 [wastl]: - directory with bundles that should be deployed in embeddes stanbol 09:25:34 [wastl]: - lmf-stanbol: 09:26:18 [wastl]: - glue code to let LMF and Stanbol Embedded interact (e.g. configure engines and chains, run chains, synchronize contexts, ...) 09:26:40 [wastl]: only the bundle directory inside stanbol-embedded will contain some snapshot bundles 09:27:26 [wastl]: I'll give you an intro to the architecture if you want (at a f2f) 09:27:48 [wikier]: #action wastl will update the documentation about the stanbol integration 09:27:55 [wikier]: #link https://code.google.com/p/lmf/wiki/ModuleStanbol 09:28:25 [wastl]: more likely this will at some point be another launcher inside the Stanbol repository 09:28:25 [wikier]: at some point we should contribute stanbol-embedded to stanbol, what do you think? 09:28:33 [wikier]: exactly 09:28:55 [wikier]: but our doc is quite out of date :-/ 09:29:03 [wastl]: yes, we already discussed this briefly, there are some extensions necessary before this is useful 09:29:27 [wastl]: mostly, you'd like to have a more generic EmbeddedStanbol and remove all "LMF" names from the classes and files 09:29:48 [wastl]: then also some tests :) 09:30:10 [wastl]: and then the problem with properly building the bundle list 09:30:25 [wastl]: but this is a topic for another day :) 09:30:40 [wastl]: Internet will stop working at 11, so let's move on 09:31:03 [wikier]: ups 09:31:10 [wikier]: on, stanbol on the way 09:31:12 [wikier]: great 09:31:19 [wikier]: next topics? 09:32:10 [jfrank]: i'm preparing lucy for stanbol... 09:32:48 [jfrank]: + i need a fix for the thumbnail-links... 09:33:03 [wastl]: yes, but we cannot patch dbpedia 09:33:12 [wikier]: unfortunately 09:33:18 [wastl]: maybe we can write a simple endpoint for ldcache that rewrites 09:33:56 [jfrank]: had sth. like that in mind... 09:35:33 [jfrank]: that's on my list for today... 09:37:18 [wikier]: yesterday I was trying to build an installer, but we'd need to check some things... maybe tomorrow 09:37:27 [wikier]: ah, yes 09:37:34 [wikier]: as you saw because the commits 09:37:48 [wikier]: yesterday we got news about INFRA-5624 09:38:03 [wikier]: https://issues.apache.org/jira/browse/INFRA-5624?focusedCommentId=13576891&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13576891 09:38:10 [wikier]: now awaiting again :-S 09:40:40 [wastl]: dietmar: what is the issue? 09:41:18 [wikier]: dglachs: report the details at jira 09:41:25 [dglachs]: 1st - when switching the database with "create" option, the tables are not recreated 09:41:26 [wikier]: I'll try to reproduce it 09:41:40 [dglachs]: ok 09:43:33 [wikier]: cool 09:43:33 [wikier]: thx 09:44:11 [wikier]: I'd also like to try those things with a running version from the installer 09:44:33 [wikier]: as we did for 2.2, in windows too 09:45:25 [wastl]: the "create" or anything does not have an effect any more 09:45:25 [wastl]: we can remove it 09:45:40 [wikier]: aja 09:45:48 [wastl]: the triple store simply creates the tables if they do not exist, upgrade them if a new version is required, or otherwise do nothing 09:46:18 [wastl]: "create" is a relict of Hibernate-thinking 09:46:34 [wastl]: so if there is something wrong, first thing to test is with an empty database 09:46:48 [wastl]: because the LMF will no longer overwrite existing tables 09:47:10 [dglachs]: to shorten the discussion ⦠i'm just creating the issue 09:47:28 [dglachs]: with a more precise description 09:47:40 [wastl]: ok, but maybe the issue is just that the database was not empty before 09:48:11 [dglachs]: true, it was not empty 09:48:19 [wastl]: so then it won't work 09:49:03 [wastl]: if this is desirable, I can first force-drop all tables that will be newly created 09:49:03 [wastl]: but this is not safe 09:49:10 [dglachs]: after dropping the db, the tables are created - but without the quartz tables 09:49:25 [wastl]: ok, so open an issue so we can check it 09:49:49 [wastl]: from MPOV the Quartz tasks should not be persisted in the database anyways 09:49:55 [wastl]: at least not in the same one 09:50:25 [wastl]: maybe the better solution is to always use an embedded H2 database for Quartz that stores the data in the LMF home 09:50:48 [wastl]: so we can finally get rid of the old persistence service 09:50:55 [wastl]: I will open an issue 09:51:03 [jfrank]: imho that would be the easiest solution 09:51:11 [dglachs]: since the amount of data is not that high ⦠09:51:40 [jfrank]: creating a quartz persistence store is not that simple... 09:51:50 [wastl]: yes 09:51:55 [wastl]: that's what I saw 09:52:03 [wastl]: embedded H2 is the best option probably 09:52:04 [jfrank]: +1 09:53:40 [wastl]: issue created 09:54:42 [wikier]: for 2.6? 09:55:10 [wikier]: or fur future versions? 09:55:18 [wikier]: s/fur/for 09:55:48 [jfrank]: 2.6 is fine, should not be a big issue 09:56:56 [jfrank]: afair lmf-scheduler will stay in lmf. right` 09:56:57 [wikier]: ok 09:57:25 [jfrank]: s/`$/?/ 09:58:26 [wikier]: I think so 10:00:48 [jfrank]: wastl?
