You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by "A. Soroka" <aj...@eservices.virginia.edu> on 2012/03/01 23:00:44 UTC
Stanbol on Karaf?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPT/GNAAoJEATpPYSyaoIk6aYH/iLIbm64J6oDhCb8Ieb7IC9m
mmU+jKdhV4XoKEAKvk12p1dmDEyScNa/BqjbcT/E4uIPUfephX5JAWVUeLjuFVWc
j9jvwCvxv+dKbhGNS6uFQcqSLnsLW51u9N2GR1fUQItrzco7hdeZee1TEyQYTD8V
fso53nbB+RVBIfOMaILovepT15o+VPYlHAdgv6blyUkHkkqv7ymgJLKC3Cxlhorf
yexZ42jIveGPcRuAOooBZKMDtKbzOXZfvVsc/uGK8CeewDFzMOtGNaiRf5Q6IYyR
XHTgDVPunbyrs7KwFASbf/hsSF7Jh2dtubwhRNOiRDF0r/YmJcUJhAXfkj0drlU=
=3Nx4
-----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by Dave butlerdi <bu...@gmail.com>.
I am also having this problem. I also noticed a significant increase in
heap space.
Re: Stanbol on Karaf?
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks! I'm having the devil of a time building ContentHub, because the LDPath artifacts switched today to use the ".bundle" file extension in their Maven repo. I'm getting messages such as you see below my sig. Is anyone else seeing this problem?
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
Failed to execute goal on project org.apache.stanbol.contenthub.ldpath: Could not resolve dependencies for project org.apache.stanbol:org.apache.stanbol.contenthub.ldpath:bundle:0.9.0-incubating-SNAPSHOT: Could not find artifact at.newmedialab.ldpath:ldpath-core-bundle:jar:0.9.5-20120307.140506-9 in kiwi-snapshot-repo (http://devel.kiwi-project.eu:8080/nexus/content/repositories/snapshots/
On Mar 7, 2012, at 10:43 AM, Ali Anil Sinaci wrote:
> Hi,
>
> I have removed the dependency "Contenthub --> CMSAdapter" with r1297400. Could you please check with an updated version?
>
> Anil.
>
> On 03/07/2012 05:34 PM, ajs6f@virginia.edu wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
>>> Allows to connect Stanbol directly with CMIS, JCR
>>>
>>> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
>>> I think this depends on the Enhancer and the CMS Adapter
>> Hm. It seems that there might be a circular dependency here:
>>
>> karaf@root> features:install stanbol-cmsadapter
>> Error executing command: Could not start bundle mvn:org.apache.stanbol/org.apache.stanbol.cmsadapter.core/0.9.0-incubating-SNAPSHOT in feature(s) stanbol-cmsadapter-0.0.0: Unresolved constraint in bundle org.apache.stanbol.cmsadapter.core [608]: Unable to resolve 608.0: missing requirement [608.0] package; (package=org.apache.stanbol.contenthub.servicesapi.store)
>> karaf@root> features:install stanbol-contenthub
>> Error executing command: Could not start bundle mvn:org.apache.stanbol/org.apache.stanbol.contenthub.search.related/0.9.0-incubating-SNAPSHOT in feature(s) stanbol-contenthub-0.0.0: Unresolved constraint in bundle org.apache.stanbol.contenthub.search.related [616]: Unable to resolve 616.0: missing requirement [616.0] package; (package=org.apache.stanbol.cmsadapter.servicesapi.helper)
>>
>> I can probably slice around this by interleaving bundles or something of the sort, but if I'm right and there is a circular dependency between the services, it might be worth spending some time to disentangle these guys.
>>
>> - ---
>> A. Soroka
>> Software& Systems Engineering :: Online Library Environment
>> the University of Virginia Library
>>
>> On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:
>>
>>> Hi
>>>
>>> Sorry for the rather late replay, but we are currently very busy with
>>> preparing the first Stanbol release.
>>>
>>>
>>>
>>> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka<aj...@eservices.virginia.edu> wrote:
>>>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>>>>
>>> Thank you for the very positive feedback.
>>>
>>>> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>>>>
>>>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>>>>
>>> I do not have any experiences with Karaf, but assuming that you need
>>> also to configure the required bundles with start levels I can provide
>>> you with the following information that might help you to create a
>>> working configuration with Apache Karaf. In addition I will provide
>>> additional information on how Apache Stanbol uses the Apache Sling
>>> OSGI installer framework as I assume this will be the major hurdle you
>>> will need to overcome to successfully run Apache Stanbol in Karaf.
>>>
>>> Before I come to the details let me add two things:
>>>
>>> 1. If you have any problems feel free to ask here on the list or also
>>> on the #stanbol channel at "freenode.net"
>>> 2. If you have success it would be extremely nice if you could share
>>> you results with the Stanbol community
>>>
>>> - - - - - - - - - - - - - - -
>>>
>>> BundleLists:
>>>
>>> Apache Stanbol uses the "partial bundle list" feature of the Sling
>>> Launcher. This lists dependencies that are collected when building the
>>> launcher
>>>
>>> The following lists are required by Apache Stanbol:
>>>
>>> 1. OSGI framework bundle list:
>>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
>>>
>>> I assume that you will already have most of those dependencies. I
>>> assume that you will not need "org.apache.sling.commons.log" because
>>> Karaf will have an own logging component.
>>>
>>> 2. Stanbol Commons bundle list:
>>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
>>>
>>> There are some dependencies that need further investigation
>>>
>>> (a) Configuration: Apache Stanbol uses the sling osgi installer
>>> framework [3] for handling its configuration. So there will be no way
>>> around to getting this to run within Karaf.
>>>
>>> Related dependencies:
>>>
>>> * org.apache.sling.installer.core: This is used by Stanbol to
>>> install service configurations via the Configuration Admin. Such
>>> configuration are provided by the launcher (see e.g. [1] but are also
>>> be provided by the bundles via [2]. You will need this to run Apache
>>> Stanbol. See [3] for the documentation of the Sling installer. My
>>> guess is that this will run fine without Sling, but you might need to
>>> manually add some sling specific properties such as "sling.home" (see
>>> [4] for more infos).
>>>
>>> * org.apache.sling.installer.factory.configuration: required
>>> because it adds support for configurations (the main reason why
>>> Stanbol uses this)
>>>
>>> * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>>>
>>> * org.apache.sling.installer.provider.file: Optional: This is
>>> similar to the OSGI FileInstaller as it tracks files you add/remove to
>>> a configured directory. The directory is configured by the
>>> "sling.fileinstall.dir" property via the bundleContext#getProperty or
>>> "sling_fileinstall_dir" via System#getProperty. Because you will not
>>> be able to load the default configuration from the launcher [1] I
>>> would try to copy those files to a directory and load them by using
>>> the File installer.
>>>
>>> * org.apache.sling.launchpad.installer: This would normally copy
>>> the config from [1] during the first start of the sling launcher. I
>>> suppose that you will not be able to use this. Because of that I
>>> suggested to use the File Installer instead (see above). I think this
>>> will not be needed when using Karaf. Same for
>>> org.apache.sling.launchpad.api.
>>>
>>> * org.apache.stanbol.commons.solr.install: Note that the
>>> installation of SolrIndexes also depends on the Sling installer
>>> framework (see [5] for details)
>>>
>>> A final note to configurations: You need to make sure that the
>>> configuration for a Service is installed after the service was
>>> started. Otherwise the service for the configuration will not be
>>> activated correctly. Because of this I would suggest to use a start
>>> level>= 30 for the configurations. So keep an eye on the start level
>>> of the "org.apache.sling.installer.provider.file" as it will install
>>> the configurations in the configured directory as soon as it stats.
>>>
>>> (b) Jersey
>>>
>>> Apache Stanbol depends on Jersey as JAX-RS implementation (see
>>> STANBOL-352). So you will need to use Jersey for now.
>>>
>>> The rest of the dependencies should not have any issues.
>>>
>>> 3. Enhancer Bundle List:
>>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
>>>
>>> 4. Entityhub Bundle List:
>>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
>>>
>>> 5. Data Bundle List:
>>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
>>>
>>> --- Up to here all Bundle Lists are required to get the same
>>> functionality as of the Stable Launcher! ---
>>>
>>> The Full launcher uses additional Bundle list:
>>>
>>> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
>>> Allows to connect Stanbol directly with CMIS, JCR
>>>
>>> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
>>> I think this depends on the Enhancer and the CMS Adapter
>>>
>>> * FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
>>>
>>> * Ontology Manager:
>>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
>>> * Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
>>> * Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
>>> Ontology manager, rules and reasoner should be only used together.
>>> Note that the RefactorEnhancementEngine
>>> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
>>> bundle list depends also on the availability of this.
>>>
>>>
>>>
>>> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
>>> [2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
>>> [3] http://sling.apache.org/site/osgi-installer.html
>>> [4] http://sling.apache.org/site/configuration.html
>>> [5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
>>>
>>>
>>>> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
>>> Hope this helps
>>>
>>> best
>>> Rupert
>>>
>>> --
>>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQEcBAEBAgAGBQJPV4AXAAoJEATpPYSyaoIkLq8H/jTQ/NP1IOysJEFk2JoryYpe
>> KH4sCPUfNEC8gXdh8n+XBqp8OeRy3mxn/kPKobMjAxr3kNpeLCVTHB5VtbCJFocT
>> svsSLZeefqJIN3M1B1/ys9Rp+bxyk5GaJnlfOGtfiPElR8xkrsGdZj0DvBf38sdy
>> Oqb32LTkTeckLHsxH0/xTepifdnjmQXqhRwFGMT49V+h16HI2Q3jzYcYSYTa/TKN
>> +YzALDMZJ0mbEKu71nviIZk5XuPFTrixcHeOlZNYuFz7aT34mHYGDC8mw47x1tlq
>> R/x1suuuhXoM0hf2Fu9aLVXDYJRSTfrufqPbWqwKTEaBMzFYycqS6Ejv+Sj4B6o=
>> =UU1i
>> -----END PGP SIGNATURE-----
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPV4qeAAoJEATpPYSyaoIkfm0IAJM71nYk2RkIcjO3yAd4Nw8m
mioxInnP2dRhtMbZOxSERFHxUIXMhOufmD8437mJFCH1kCkmJ4kKoVx4GA1pM7w3
EUMoahm9pwOzGU6aVGT0ksmBbCmLQa86IU0iSqy+kZvQQb4i1/ENpsgUsgADC1l6
kADG3WlYEm2QXigISuO03oavntYNJTIJOsBVToizJElCGHAR6XTpqk788nnzvqDA
cVh6CwqWRL8ApJEBXCzx8H74xG0svpFBMiirHzd0IrL2DG742GnQUjJOTTLIc/4Q
sr3V5dY6ljcVqso3TAS7R8WJN/WU4i79yxzyuw53624sbABV/FsTF8nRVQ8YN34=
=0Prd
-----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by Ali Anil Sinaci <a....@gmail.com>.
Hi,
I have removed the dependency "Contenthub --> CMSAdapter" with r1297400.
Could you please check with an updated version?
Anil.
On 03/07/2012 05:34 PM, ajs6f@virginia.edu wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
>> Allows to connect Stanbol directly with CMIS, JCR
>>
>> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
>> I think this depends on the Enhancer and the CMS Adapter
> Hm. It seems that there might be a circular dependency here:
>
> karaf@root> features:install stanbol-cmsadapter
> Error executing command: Could not start bundle mvn:org.apache.stanbol/org.apache.stanbol.cmsadapter.core/0.9.0-incubating-SNAPSHOT in feature(s) stanbol-cmsadapter-0.0.0: Unresolved constraint in bundle org.apache.stanbol.cmsadapter.core [608]: Unable to resolve 608.0: missing requirement [608.0] package; (package=org.apache.stanbol.contenthub.servicesapi.store)
> karaf@root> features:install stanbol-contenthub
> Error executing command: Could not start bundle mvn:org.apache.stanbol/org.apache.stanbol.contenthub.search.related/0.9.0-incubating-SNAPSHOT in feature(s) stanbol-contenthub-0.0.0: Unresolved constraint in bundle org.apache.stanbol.contenthub.search.related [616]: Unable to resolve 616.0: missing requirement [616.0] package; (package=org.apache.stanbol.cmsadapter.servicesapi.helper)
>
> I can probably slice around this by interleaving bundles or something of the sort, but if I'm right and there is a circular dependency between the services, it might be worth spending some time to disentangle these guys.
>
> - ---
> A. Soroka
> Software& Systems Engineering :: Online Library Environment
> the University of Virginia Library
>
> On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:
>
>> Hi
>>
>> Sorry for the rather late replay, but we are currently very busy with
>> preparing the first Stanbol release.
>>
>>
>>
>> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka<aj...@eservices.virginia.edu> wrote:
>>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>>>
>> Thank you for the very positive feedback.
>>
>>> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>>>
>>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>>>
>> I do not have any experiences with Karaf, but assuming that you need
>> also to configure the required bundles with start levels I can provide
>> you with the following information that might help you to create a
>> working configuration with Apache Karaf. In addition I will provide
>> additional information on how Apache Stanbol uses the Apache Sling
>> OSGI installer framework as I assume this will be the major hurdle you
>> will need to overcome to successfully run Apache Stanbol in Karaf.
>>
>> Before I come to the details let me add two things:
>>
>> 1. If you have any problems feel free to ask here on the list or also
>> on the #stanbol channel at "freenode.net"
>> 2. If you have success it would be extremely nice if you could share
>> you results with the Stanbol community
>>
>> - - - - - - - - - - - - - - -
>>
>> BundleLists:
>>
>> Apache Stanbol uses the "partial bundle list" feature of the Sling
>> Launcher. This lists dependencies that are collected when building the
>> launcher
>>
>> The following lists are required by Apache Stanbol:
>>
>> 1. OSGI framework bundle list:
>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
>>
>> I assume that you will already have most of those dependencies. I
>> assume that you will not need "org.apache.sling.commons.log" because
>> Karaf will have an own logging component.
>>
>> 2. Stanbol Commons bundle list:
>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
>>
>> There are some dependencies that need further investigation
>>
>> (a) Configuration: Apache Stanbol uses the sling osgi installer
>> framework [3] for handling its configuration. So there will be no way
>> around to getting this to run within Karaf.
>>
>> Related dependencies:
>>
>> * org.apache.sling.installer.core: This is used by Stanbol to
>> install service configurations via the Configuration Admin. Such
>> configuration are provided by the launcher (see e.g. [1] but are also
>> be provided by the bundles via [2]. You will need this to run Apache
>> Stanbol. See [3] for the documentation of the Sling installer. My
>> guess is that this will run fine without Sling, but you might need to
>> manually add some sling specific properties such as "sling.home" (see
>> [4] for more infos).
>>
>> * org.apache.sling.installer.factory.configuration: required
>> because it adds support for configurations (the main reason why
>> Stanbol uses this)
>>
>> * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>>
>> * org.apache.sling.installer.provider.file: Optional: This is
>> similar to the OSGI FileInstaller as it tracks files you add/remove to
>> a configured directory. The directory is configured by the
>> "sling.fileinstall.dir" property via the bundleContext#getProperty or
>> "sling_fileinstall_dir" via System#getProperty. Because you will not
>> be able to load the default configuration from the launcher [1] I
>> would try to copy those files to a directory and load them by using
>> the File installer.
>>
>> * org.apache.sling.launchpad.installer: This would normally copy
>> the config from [1] during the first start of the sling launcher. I
>> suppose that you will not be able to use this. Because of that I
>> suggested to use the File Installer instead (see above). I think this
>> will not be needed when using Karaf. Same for
>> org.apache.sling.launchpad.api.
>>
>> * org.apache.stanbol.commons.solr.install: Note that the
>> installation of SolrIndexes also depends on the Sling installer
>> framework (see [5] for details)
>>
>> A final note to configurations: You need to make sure that the
>> configuration for a Service is installed after the service was
>> started. Otherwise the service for the configuration will not be
>> activated correctly. Because of this I would suggest to use a start
>> level>= 30 for the configurations. So keep an eye on the start level
>> of the "org.apache.sling.installer.provider.file" as it will install
>> the configurations in the configured directory as soon as it stats.
>>
>> (b) Jersey
>>
>> Apache Stanbol depends on Jersey as JAX-RS implementation (see
>> STANBOL-352). So you will need to use Jersey for now.
>>
>> The rest of the dependencies should not have any issues.
>>
>> 3. Enhancer Bundle List:
>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
>>
>> 4. Entityhub Bundle List:
>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
>>
>> 5. Data Bundle List:
>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
>>
>> --- Up to here all Bundle Lists are required to get the same
>> functionality as of the Stable Launcher! ---
>>
>> The Full launcher uses additional Bundle list:
>>
>> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
>> Allows to connect Stanbol directly with CMIS, JCR
>>
>> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
>> I think this depends on the Enhancer and the CMS Adapter
>>
>> * FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
>>
>> * Ontology Manager:
>> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
>> * Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
>> * Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
>> Ontology manager, rules and reasoner should be only used together.
>> Note that the RefactorEnhancementEngine
>> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
>> bundle list depends also on the availability of this.
>>
>>
>>
>> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
>> [2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
>> [3] http://sling.apache.org/site/osgi-installer.html
>> [4] http://sling.apache.org/site/configuration.html
>> [5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
>>
>>
>>> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
>> Hope this helps
>>
>> best
>> Rupert
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJPV4AXAAoJEATpPYSyaoIkLq8H/jTQ/NP1IOysJEFk2JoryYpe
> KH4sCPUfNEC8gXdh8n+XBqp8OeRy3mxn/kPKobMjAxr3kNpeLCVTHB5VtbCJFocT
> svsSLZeefqJIN3M1B1/ys9Rp+bxyk5GaJnlfOGtfiPElR8xkrsGdZj0DvBf38sdy
> Oqb32LTkTeckLHsxH0/xTepifdnjmQXqhRwFGMT49V+h16HI2Q3jzYcYSYTa/TKN
> +YzALDMZJ0mbEKu71nviIZk5XuPFTrixcHeOlZNYuFz7aT34mHYGDC8mw47x1tlq
> R/x1suuuhXoM0hf2Fu9aLVXDYJRSTfrufqPbWqwKTEaBMzFYycqS6Ejv+Sj4B6o=
> =UU1i
> -----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
> Allows to connect Stanbol directly with CMIS, JCR
>
> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
> I think this depends on the Enhancer and the CMS Adapter
Hm. It seems that there might be a circular dependency here:
karaf@root> features:install stanbol-cmsadapter
Error executing command: Could not start bundle mvn:org.apache.stanbol/org.apache.stanbol.cmsadapter.core/0.9.0-incubating-SNAPSHOT in feature(s) stanbol-cmsadapter-0.0.0: Unresolved constraint in bundle org.apache.stanbol.cmsadapter.core [608]: Unable to resolve 608.0: missing requirement [608.0] package; (package=org.apache.stanbol.contenthub.servicesapi.store)
karaf@root> features:install stanbol-contenthub
Error executing command: Could not start bundle mvn:org.apache.stanbol/org.apache.stanbol.contenthub.search.related/0.9.0-incubating-SNAPSHOT in feature(s) stanbol-contenthub-0.0.0: Unresolved constraint in bundle org.apache.stanbol.contenthub.search.related [616]: Unable to resolve 616.0: missing requirement [616.0] package; (package=org.apache.stanbol.cmsadapter.servicesapi.helper)
I can probably slice around this by interleaving bundles or something of the sort, but if I'm right and there is a circular dependency between the services, it might be worth spending some time to disentangle these guys.
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:
> Hi
>
> Sorry for the rather late replay, but we are currently very busy with
> preparing the first Stanbol release.
>
>
>
> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka <aj...@eservices.virginia.edu> wrote:
>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>>
>
> Thank you for the very positive feedback.
>
>> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>>
>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>>
>
> I do not have any experiences with Karaf, but assuming that you need
> also to configure the required bundles with start levels I can provide
> you with the following information that might help you to create a
> working configuration with Apache Karaf. In addition I will provide
> additional information on how Apache Stanbol uses the Apache Sling
> OSGI installer framework as I assume this will be the major hurdle you
> will need to overcome to successfully run Apache Stanbol in Karaf.
>
> Before I come to the details let me add two things:
>
> 1. If you have any problems feel free to ask here on the list or also
> on the #stanbol channel at "freenode.net"
> 2. If you have success it would be extremely nice if you could share
> you results with the Stanbol community
>
> - - - - - - - - - - - - - - -
>
> BundleLists:
>
> Apache Stanbol uses the "partial bundle list" feature of the Sling
> Launcher. This lists dependencies that are collected when building the
> launcher
>
> The following lists are required by Apache Stanbol:
>
> 1. OSGI framework bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
>
> I assume that you will already have most of those dependencies. I
> assume that you will not need "org.apache.sling.commons.log" because
> Karaf will have an own logging component.
>
> 2. Stanbol Commons bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
>
> There are some dependencies that need further investigation
>
> (a) Configuration: Apache Stanbol uses the sling osgi installer
> framework [3] for handling its configuration. So there will be no way
> around to getting this to run within Karaf.
>
> Related dependencies:
>
> * org.apache.sling.installer.core: This is used by Stanbol to
> install service configurations via the Configuration Admin. Such
> configuration are provided by the launcher (see e.g. [1] but are also
> be provided by the bundles via [2]. You will need this to run Apache
> Stanbol. See [3] for the documentation of the Sling installer. My
> guess is that this will run fine without Sling, but you might need to
> manually add some sling specific properties such as "sling.home" (see
> [4] for more infos).
>
> * org.apache.sling.installer.factory.configuration: required
> because it adds support for configurations (the main reason why
> Stanbol uses this)
>
> * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>
> * org.apache.sling.installer.provider.file: Optional: This is
> similar to the OSGI FileInstaller as it tracks files you add/remove to
> a configured directory. The directory is configured by the
> "sling.fileinstall.dir" property via the bundleContext#getProperty or
> "sling_fileinstall_dir" via System#getProperty. Because you will not
> be able to load the default configuration from the launcher [1] I
> would try to copy those files to a directory and load them by using
> the File installer.
>
> * org.apache.sling.launchpad.installer: This would normally copy
> the config from [1] during the first start of the sling launcher. I
> suppose that you will not be able to use this. Because of that I
> suggested to use the File Installer instead (see above). I think this
> will not be needed when using Karaf. Same for
> org.apache.sling.launchpad.api.
>
> * org.apache.stanbol.commons.solr.install: Note that the
> installation of SolrIndexes also depends on the Sling installer
> framework (see [5] for details)
>
> A final note to configurations: You need to make sure that the
> configuration for a Service is installed after the service was
> started. Otherwise the service for the configuration will not be
> activated correctly. Because of this I would suggest to use a start
> level >= 30 for the configurations. So keep an eye on the start level
> of the "org.apache.sling.installer.provider.file" as it will install
> the configurations in the configured directory as soon as it stats.
>
> (b) Jersey
>
> Apache Stanbol depends on Jersey as JAX-RS implementation (see
> STANBOL-352). So you will need to use Jersey for now.
>
> The rest of the dependencies should not have any issues.
>
> 3. Enhancer Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
>
> 4. Entityhub Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
>
> 5. Data Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
>
> --- Up to here all Bundle Lists are required to get the same
> functionality as of the Stable Launcher! ---
>
> The Full launcher uses additional Bundle list:
>
> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
> Allows to connect Stanbol directly with CMIS, JCR
>
> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
> I think this depends on the Enhancer and the CMS Adapter
>
> * FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
>
> * Ontology Manager:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
> * Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
> * Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
> Ontology manager, rules and reasoner should be only used together.
> Note that the RefactorEnhancementEngine
> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
> bundle list depends also on the availability of this.
>
>
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
> [2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
> [3] http://sling.apache.org/site/osgi-installer.html
> [4] http://sling.apache.org/site/configuration.html
> [5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
>
>
>> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
>
> Hope this helps
>
> best
> Rupert
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPV4AXAAoJEATpPYSyaoIkLq8H/jTQ/NP1IOysJEFk2JoryYpe
KH4sCPUfNEC8gXdh8n+XBqp8OeRy3mxn/kPKobMjAxr3kNpeLCVTHB5VtbCJFocT
svsSLZeefqJIN3M1B1/ys9Rp+bxyk5GaJnlfOGtfiPElR8xkrsGdZj0DvBf38sdy
Oqb32LTkTeckLHsxH0/xTepifdnjmQXqhRwFGMT49V+h16HI2Q3jzYcYSYTa/TKN
+YzALDMZJ0mbEKu71nviIZk5XuPFTrixcHeOlZNYuFz7aT34mHYGDC8mw47x1tlq
R/x1suuuhXoM0hf2Fu9aLVXDYJRSTfrufqPbWqwKTEaBMzFYycqS6Ejv+Sj4B6o=
=UU1i
-----END PGP SIGNATURE-----
Re: Stanbol Default Configuration (was: Stanbol on Karaf?)
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Let me add even another piece of support: such default config modules would be the perfect place to in-line document some of the bits and pieces of configuration, such as "blessed" directories, URL segments, etc. While the OSGi config and supporting Felix Web console gear is really wonderful, some people will always be more comfortable reading through properties files and the like, and having them brought out clearly can make for easier automated installation.
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Mar 7, 2012, at 2:49 AM, Rupert Westenthaler wrote:
> Hi all,
>
> Note this question from A. Soroka:
>
> On 06.03.2012, at 23:07, ajs6f@virginia.edu wrote:
>
>> Some questions I feel emboldened to ask: would it perhaps be better for that "startup config" to be associated with the EntityHub service itself (and not the launchers), or would that be too direct a dependence? I can certainly imagine wanting to use a Clerezza Yard instead, or a remote Solr instance, or some other arrangement, but might it not be better to have everything the EntityHub service needs come with the bundlelist/feature repository itself?
>
> Maybe an own "o.a.s.{component}.defaults" module that uses [1] to provide the default configuration for the {component}.
>
> This would have the following advantages against the current solution (adding all the defaults to the 'resources/config' folder of the launcher)
>
> * It would allow us to manage the default config within an component (e.g. enhancer, entityhub, contenthub …).
> * the defaults-module could be added to the bundle list of that component
> * users that do not want to use the default config could just exclude the "o.a.s.{component}.defaults" bundle and provide their own configuration.
> * uninstalling "o.a.s.{component}.defaults" would cause the default configuration to be removed.
> * we would no longer need to duplicate the defaults for the different launchers.
>
> WDYT
> Rupert
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPV20KAAoJEATpPYSyaoIk18IIAKr9LWgOT7l3sVm8Nvq4i18F
2AZlyhfXQrrANM7C8fS+4pka3VjpNiXyM4qZTjJi7u/PgWIpUCluSlM+dM7YpMcR
kD5hT4ixN68MEbvZYFe2ptTL0JzfjYXmSsS8KaGvpWsholeFIHO5OenR3OxB4Ag6
xBj55KiwC3yLRtaFcc+/KXkjVLZBW5V3jOyTL1T9WgCG9dmwIPvs9ln4vV0SO30Z
G3GnhDGzr9UobIKfMr1JB34bsX7Fp950FMUg+Q4W5un4g/uUAPGVAAnZSZ7X43Uz
/+R2kuqOtQ9p27Ms/MPZU9LALOXAuDRmGpxTcHK62cVu3H0BRdJYz2kZtrcwD8Y=
=uIQt
-----END PGP SIGNATURE-----
Re: Stanbol Default Configuration
Posted by Rupert Westenthaler <ru...@gmail.com>.
created an issue for that
https://issues.apache.org/jira/browse/STANBOL-529
I will start to migrate the entityhub to the new system in the coming weeks.
best
Rupert
On 07.03.2012, at 09:43, Ali Anil Sinaci wrote:
> Hi,
>
> +1 for default configuration bundles for each component.
>
> Anil.
>
> On 03/07/2012 09:49 AM, Rupert Westenthaler wrote:
>> Hi all,
>>
>> Note this question from A. Soroka:
>>
>> On 06.03.2012, at 23:07, ajs6f@virginia.edu wrote:
>>
>>> Some questions I feel emboldened to ask: would it perhaps be better for that "startup config" to be associated with the EntityHub service itself (and not the launchers), or would that be too direct a dependence? I can certainly imagine wanting to use a Clerezza Yard instead, or a remote Solr instance, or some other arrangement, but might it not be better to have everything the EntityHub service needs come with the bundlelist/feature repository itself?
>> Maybe an own "o.a.s.{component}.defaults" module that uses [1] to provide the default configuration for the {component}.
>>
>> This would have the following advantages against the current solution (adding all the defaults to the 'resources/config' folder of the launcher)
>>
>> * It would allow us to manage the default config within an component (e.g. enhancer, entityhub, contenthub …).
>> * the defaults-module could be added to the bundle list of that component
>> * users that do not want to use the default config could just exclude the "o.a.s.{component}.defaults" bundle and provide their own configuration.
>> * uninstalling "o.a.s.{component}.defaults" would cause the default configuration to be removed.
>> * we would no longer need to duplicate the defaults for the different launchers.
>>
>> WDYT
>> Rupert
>>
>> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
>
Re: Stanbol Default Configuration
Posted by Ali Anil Sinaci <a....@gmail.com>.
Hi,
+1 for default configuration bundles for each component.
Anil.
On 03/07/2012 09:49 AM, Rupert Westenthaler wrote:
> Hi all,
>
> Note this question from A. Soroka:
>
> On 06.03.2012, at 23:07, ajs6f@virginia.edu wrote:
>
>> Some questions I feel emboldened to ask: would it perhaps be better for that "startup config" to be associated with the EntityHub service itself (and not the launchers), or would that be too direct a dependence? I can certainly imagine wanting to use a Clerezza Yard instead, or a remote Solr instance, or some other arrangement, but might it not be better to have everything the EntityHub service needs come with the bundlelist/feature repository itself?
> Maybe an own "o.a.s.{component}.defaults" module that uses [1] to provide the default configuration for the {component}.
>
> This would have the following advantages against the current solution (adding all the defaults to the 'resources/config' folder of the launcher)
>
> * It would allow us to manage the default config within an component (e.g. enhancer, entityhub, contenthub …).
> * the defaults-module could be added to the bundle list of that component
> * users that do not want to use the default config could just exclude the "o.a.s.{component}.defaults" bundle and provide their own configuration.
> * uninstalling "o.a.s.{component}.defaults" would cause the default configuration to be removed.
> * we would no longer need to duplicate the defaults for the different launchers.
>
> WDYT
> Rupert
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
Re: Stanbol Default Configuration (was: Stanbol on Karaf?)
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
it sounds reasonable to me to keep the configuration within a
component and allow flexible customization of that config.
+1
Am 7. März 2012 08:49 schrieb Rupert Westenthaler
<ru...@gmail.com>:
> Hi all,
>
> Note this question from A. Soroka:
>
> On 06.03.2012, at 23:07, ajs6f@virginia.edu wrote:
>
>> Some questions I feel emboldened to ask: would it perhaps be better for that "startup config" to be associated with the EntityHub service itself (and not the launchers), or would that be too direct a dependence? I can certainly imagine wanting to use a Clerezza Yard instead, or a remote Solr instance, or some other arrangement, but might it not be better to have everything the EntityHub service needs come with the bundlelist/feature repository itself?
>
> Maybe an own "o.a.s.{component}.defaults" module that uses [1] to provide the default configuration for the {component}.
>
> This would have the following advantages against the current solution (adding all the defaults to the 'resources/config' folder of the launcher)
>
> * It would allow us to manage the default config within an component (e.g. enhancer, entityhub, contenthub …).
> * the defaults-module could be added to the bundle list of that component
> * users that do not want to use the default config could just exclude the "o.a.s.{component}.defaults" bundle and provide their own configuration.
> * uninstalling "o.a.s.{component}.defaults" would cause the default configuration to be removed.
> * we would no longer need to duplicate the defaults for the different launchers.
>
> WDYT
> Rupert
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
--
Fabian
http://twitter.com/fctwitt
Stanbol Default Configuration (was: Stanbol on Karaf?)
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi all,
Note this question from A. Soroka:
On 06.03.2012, at 23:07, ajs6f@virginia.edu wrote:
> Some questions I feel emboldened to ask: would it perhaps be better for that "startup config" to be associated with the EntityHub service itself (and not the launchers), or would that be too direct a dependence? I can certainly imagine wanting to use a Clerezza Yard instead, or a remote Solr instance, or some other arrangement, but might it not be better to have everything the EntityHub service needs come with the bundlelist/feature repository itself?
Maybe an own "o.a.s.{component}.defaults" module that uses [1] to provide the default configuration for the {component}.
This would have the following advantages against the current solution (adding all the defaults to the 'resources/config' folder of the launcher)
* It would allow us to manage the default config within an component (e.g. enhancer, entityhub, contenthub …).
* the defaults-module could be added to the bundle list of that component
* users that do not want to use the default config could just exclude the "o.a.s.{component}.defaults" bundle and provide their own configuration.
* uninstalling "o.a.s.{component}.defaults" would cause the default configuration to be removed.
* we would no longer need to duplicate the defaults for the different launchers.
WDYT
Rupert
[1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
Re: Stanbol on Karaf?
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ahh-- I believe that would be it. There's no way with my current experiment that the config could get loaded. Well, live and learn. Today I learned something about manually building up Yards and Indexes!
I'll get that config incorporated in the next try. Thanks!
Some questions I feel emboldened to ask: would it perhaps be better for that "startup config" to be associated with the EntityHub service itself (and not the launchers), or would that be too direct a dependence? I can certainly imagine wanting to use a Clerezza Yard instead, or a remote Solr instance, or some other arrangement, but might it not be better to have everything the EntityHub service needs come with the bundlelist/feature repository itself?
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Mar 6, 2012, at 4:49 PM, Rupert Westenthaler wrote:
>
> On 06.03.2012, at 21:09, ajs6f@virginia.edu wrote:
>
>> 5) After getting the Stanbol Commons and EntityHub up and started, I had to manually configure the EntityHub's own Yard. This wasn't difficult, but it's not totally clear to me why the bundles didn't do this on activation.
>
> The configuration of the SolrYard used by the Entityhub itself is provided by the default configuration of the Sling launcher.
>
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/stable/src/main/resources/resources/config/org.apache.stanbol.entityhub.yard.solr.impl.SolrYard-entityhub.config
>
> Are you sure that the configurations included in the Sling Launcher are loaded by Karaf?
>
> best
> Rupert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPVoqRAAoJEATpPYSyaoIk7WAIAKZLxXEkKUUBpe6DGUmot1OW
cWM/uoDLtBaBLtGrrfo0stNnbbS/5RnqKLFXPoowYn1lS+LYKxw3H0EAIvUanUWS
xwz0CAzoEkcQHCyeY2vTQ/IqnHxjq5Uc1JgsY683TGr7EzxTX4eoXTTO1QwCfqtT
GdLqtoqYpkezU2Pnsf8QTj9c6woPUpj1tRmmvmkIqF41P2LGFSnHq3uBMdfEbQKx
Fvsnk5Dp1lzq15WtIz3v8hjQ/tVzw9jpwRuFeaJ0u0wRAjUYXPJLFqcCZDVrDBAw
UHrm9ieMp/ERnURB2KoELqTeFoQWS/6CU9sHPqH14brTZyfKCWr5ldBilQPKtVE=
=9YOd
-----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by Rupert Westenthaler <ru...@gmail.com>.
On 06.03.2012, at 21:09, ajs6f@virginia.edu wrote:
> 5) After getting the Stanbol Commons and EntityHub up and started, I had to manually configure the EntityHub's own Yard. This wasn't difficult, but it's not totally clear to me why the bundles didn't do this on activation.
The configuration of the SolrYard used by the Entityhub itself is provided by the default configuration of the Sling launcher.
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/stable/src/main/resources/resources/config/org.apache.stanbol.entityhub.yard.solr.impl.SolrYard-entityhub.config
Are you sure that the configurations included in the Sling Launcher are loaded by Karaf?
best
Rupert
Re: Stanbol on Karaf?
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just a check in:
Things are looking good. I've the EntityHub up and running in Karaf 2.2.5 using the Felix framework, and it was fairly easy. I'll give a few notes here on the way to writing up something more substantive after I've got the complete 'stable' suite up.
1) The Sling Launchpad Maven plugin went nowheresville for making Karaf feature repositories. I'm sure it does work and work well, but for me, I couldn't get over a NullPointer exception when it went looking for an unnamed properties file. Googling and a quick glance at the code got me no further, so I decided to hack it for now and come back to Maven later. Of course, for a "sustainable" solution, I'll have to engage the Maven build.
2) I decided to just run XSL stylesheets against the Sling bundlelists to make Karaf feature lists. This is not a good approach for any length of time, but time marches on and so do I, so I wanted to try to get something up and running.
3) I dropped the OSGi framework bundlelist entirely, because the only things I needed from it were the Felix webconsole, which is available as a Karaf feature, an OSGi DS implementation (I picked Felix's, for obvious reasons) and an HTTP service (again, I chose Felix's).
4) I ran into an issue with Jersey. It uses the SPI machinery to configure itself, which does not make OSGi resolution happy. It's a known issue, although I don't know whether the Jersey folks actually consider it a problem. The quickest way forward was just to copy the jersey-server META-INF/services directory into the Stanbol o.a.s.commons.web.base bundle. Again, a hack, but I thought it better not to trouble too much about Jersey while issues like:
https://issues.apache.org/jira/browse/STANBOL-352
are in play.
5) After getting the Stanbol Commons and EntityHub up and started, I had to manually configure the EntityHub's own Yard. This wasn't difficult, but it's not totally clear to me why the bundles didn't do this on activation.
And now I'm happily moving entities in and out of the Hub! The REST API is functional.
Now I'm moving on to the other parts of the 'stable' suite.
Thanks for the help so far!
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:
> Hi
>
> Sorry for the rather late replay, but we are currently very busy with
> preparing the first Stanbol release.
>
>
>
> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka <aj...@eservices.virginia.edu> wrote:
>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>>
>
> Thank you for the very positive feedback.
>
>> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>>
>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>>
>
> I do not have any experiences with Karaf, but assuming that you need
> also to configure the required bundles with start levels I can provide
> you with the following information that might help you to create a
> working configuration with Apache Karaf. In addition I will provide
> additional information on how Apache Stanbol uses the Apache Sling
> OSGI installer framework as I assume this will be the major hurdle you
> will need to overcome to successfully run Apache Stanbol in Karaf.
>
> Before I come to the details let me add two things:
>
> 1. If you have any problems feel free to ask here on the list or also
> on the #stanbol channel at "freenode.net"
> 2. If you have success it would be extremely nice if you could share
> you results with the Stanbol community
>
> - - - - - - - - - - - - - - -
>
> BundleLists:
>
> Apache Stanbol uses the "partial bundle list" feature of the Sling
> Launcher. This lists dependencies that are collected when building the
> launcher
>
> The following lists are required by Apache Stanbol:
>
> 1. OSGI framework bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
>
> I assume that you will already have most of those dependencies. I
> assume that you will not need "org.apache.sling.commons.log" because
> Karaf will have an own logging component.
>
> 2. Stanbol Commons bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
>
> There are some dependencies that need further investigation
>
> (a) Configuration: Apache Stanbol uses the sling osgi installer
> framework [3] for handling its configuration. So there will be no way
> around to getting this to run within Karaf.
>
> Related dependencies:
>
> * org.apache.sling.installer.core: This is used by Stanbol to
> install service configurations via the Configuration Admin. Such
> configuration are provided by the launcher (see e.g. [1] but are also
> be provided by the bundles via [2]. You will need this to run Apache
> Stanbol. See [3] for the documentation of the Sling installer. My
> guess is that this will run fine without Sling, but you might need to
> manually add some sling specific properties such as "sling.home" (see
> [4] for more infos).
>
> * org.apache.sling.installer.factory.configuration: required
> because it adds support for configurations (the main reason why
> Stanbol uses this)
>
> * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>
> * org.apache.sling.installer.provider.file: Optional: This is
> similar to the OSGI FileInstaller as it tracks files you add/remove to
> a configured directory. The directory is configured by the
> "sling.fileinstall.dir" property via the bundleContext#getProperty or
> "sling_fileinstall_dir" via System#getProperty. Because you will not
> be able to load the default configuration from the launcher [1] I
> would try to copy those files to a directory and load them by using
> the File installer.
>
> * org.apache.sling.launchpad.installer: This would normally copy
> the config from [1] during the first start of the sling launcher. I
> suppose that you will not be able to use this. Because of that I
> suggested to use the File Installer instead (see above). I think this
> will not be needed when using Karaf. Same for
> org.apache.sling.launchpad.api.
>
> * org.apache.stanbol.commons.solr.install: Note that the
> installation of SolrIndexes also depends on the Sling installer
> framework (see [5] for details)
>
> A final note to configurations: You need to make sure that the
> configuration for a Service is installed after the service was
> started. Otherwise the service for the configuration will not be
> activated correctly. Because of this I would suggest to use a start
> level >= 30 for the configurations. So keep an eye on the start level
> of the "org.apache.sling.installer.provider.file" as it will install
> the configurations in the configured directory as soon as it stats.
>
> (b) Jersey
>
> Apache Stanbol depends on Jersey as JAX-RS implementation (see
> STANBOL-352). So you will need to use Jersey for now.
>
> The rest of the dependencies should not have any issues.
>
> 3. Enhancer Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
>
> 4. Entityhub Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
>
> 5. Data Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
>
> --- Up to here all Bundle Lists are required to get the same
> functionality as of the Stable Launcher! ---
>
> The Full launcher uses additional Bundle list:
>
> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
> Allows to connect Stanbol directly with CMIS, JCR
>
> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
> I think this depends on the Enhancer and the CMS Adapter
>
> * FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
>
> * Ontology Manager:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
> * Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
> * Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
> Ontology manager, rules and reasoner should be only used together.
> Note that the RefactorEnhancementEngine
> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
> bundle list depends also on the availability of this.
>
>
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
> [2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
> [3] http://sling.apache.org/site/osgi-installer.html
> [4] http://sling.apache.org/site/configuration.html
> [5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
>
>
>> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
>
> Hope this helps
>
> best
> Rupert
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPVm8AAAoJEATpPYSyaoIkitEIANoihQ4jwvza13HcYvIvGQqZ
LaYRjkOffif9eP9rRq6NT3nkVcvzLCKX1lJ5Yt/+1hy5fqrMdLJcKsPOI3INCO5+
BvG4aYC1INXbz7Cr7jvoqO3gx3wpNpnFgSKs5G4j0cyyoAFQkCSX178l6OgaE2WG
sTC8E6Ihs/gzK8Kt9ZMN3JD/aAz+97Fxt/pGmRNL3c2Od4VvDEXY1/oQmgrcyF5s
LzUGbUsXe0t3X7xsB/ZnJ90Cu43fDmv0yEdBopK+GRRzuHJSvnTg2lVgyNz86VuH
3WhFF8wrB+6rEoCoeblZrI0vDvJzVyYuorkFeteirgasVSGQqyt13I60Qw1OE3A=
=P6xt
-----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just a further note-- I was able to get all of the services in the 'full' suite up and running in Karaf except for CMSAdaptor and ContentHub. I'll check back with those after the LDPath-related build issues are resolved.
I also managed to get the Sling Launchpad Maven plugin working over the Stanbol source (except for the launchers, which still suffer from odd missing properties files problems). Unfortunately, what I get after doing this is not a well-structured set of feature repositories, but repositories with enormous numbers of bundles and not much awareness of transitivity outside the individual services, so that (for example) bundles that appear in Stanbol Commons also appear over and over again in the repositories for individual services. It's not clear to me how far it's worth going down that road, unless I can find a way to make the relationships more explicit and therefore available to the Sling plugin.
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:
> Hi
>
> Sorry for the rather late replay, but we are currently very busy with
> preparing the first Stanbol release.
>
>
>
> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka <aj...@eservices.virginia.edu> wrote:
>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>>
>
> Thank you for the very positive feedback.
>
>> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>>
>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>>
>
> I do not have any experiences with Karaf, but assuming that you need
> also to configure the required bundles with start levels I can provide
> you with the following information that might help you to create a
> working configuration with Apache Karaf. In addition I will provide
> additional information on how Apache Stanbol uses the Apache Sling
> OSGI installer framework as I assume this will be the major hurdle you
> will need to overcome to successfully run Apache Stanbol in Karaf.
>
> Before I come to the details let me add two things:
>
> 1. If you have any problems feel free to ask here on the list or also
> on the #stanbol channel at "freenode.net"
> 2. If you have success it would be extremely nice if you could share
> you results with the Stanbol community
>
> - - - - - - - - - - - - - - -
>
> BundleLists:
>
> Apache Stanbol uses the "partial bundle list" feature of the Sling
> Launcher. This lists dependencies that are collected when building the
> launcher
>
> The following lists are required by Apache Stanbol:
>
> 1. OSGI framework bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
>
> I assume that you will already have most of those dependencies. I
> assume that you will not need "org.apache.sling.commons.log" because
> Karaf will have an own logging component.
>
> 2. Stanbol Commons bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
>
> There are some dependencies that need further investigation
>
> (a) Configuration: Apache Stanbol uses the sling osgi installer
> framework [3] for handling its configuration. So there will be no way
> around to getting this to run within Karaf.
>
> Related dependencies:
>
> * org.apache.sling.installer.core: This is used by Stanbol to
> install service configurations via the Configuration Admin. Such
> configuration are provided by the launcher (see e.g. [1] but are also
> be provided by the bundles via [2]. You will need this to run Apache
> Stanbol. See [3] for the documentation of the Sling installer. My
> guess is that this will run fine without Sling, but you might need to
> manually add some sling specific properties such as "sling.home" (see
> [4] for more infos).
>
> * org.apache.sling.installer.factory.configuration: required
> because it adds support for configurations (the main reason why
> Stanbol uses this)
>
> * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>
> * org.apache.sling.installer.provider.file: Optional: This is
> similar to the OSGI FileInstaller as it tracks files you add/remove to
> a configured directory. The directory is configured by the
> "sling.fileinstall.dir" property via the bundleContext#getProperty or
> "sling_fileinstall_dir" via System#getProperty. Because you will not
> be able to load the default configuration from the launcher [1] I
> would try to copy those files to a directory and load them by using
> the File installer.
>
> * org.apache.sling.launchpad.installer: This would normally copy
> the config from [1] during the first start of the sling launcher. I
> suppose that you will not be able to use this. Because of that I
> suggested to use the File Installer instead (see above). I think this
> will not be needed when using Karaf. Same for
> org.apache.sling.launchpad.api.
>
> * org.apache.stanbol.commons.solr.install: Note that the
> installation of SolrIndexes also depends on the Sling installer
> framework (see [5] for details)
>
> A final note to configurations: You need to make sure that the
> configuration for a Service is installed after the service was
> started. Otherwise the service for the configuration will not be
> activated correctly. Because of this I would suggest to use a start
> level >= 30 for the configurations. So keep an eye on the start level
> of the "org.apache.sling.installer.provider.file" as it will install
> the configurations in the configured directory as soon as it stats.
>
> (b) Jersey
>
> Apache Stanbol depends on Jersey as JAX-RS implementation (see
> STANBOL-352). So you will need to use Jersey for now.
>
> The rest of the dependencies should not have any issues.
>
> 3. Enhancer Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
>
> 4. Entityhub Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
>
> 5. Data Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
>
> --- Up to here all Bundle Lists are required to get the same
> functionality as of the Stable Launcher! ---
>
> The Full launcher uses additional Bundle list:
>
> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
> Allows to connect Stanbol directly with CMIS, JCR
>
> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
> I think this depends on the Enhancer and the CMS Adapter
>
> * FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
>
> * Ontology Manager:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
> * Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
> * Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
> Ontology manager, rules and reasoner should be only used together.
> Note that the RefactorEnhancementEngine
> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
> bundle list depends also on the availability of this.
>
>
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
> [2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
> [3] http://sling.apache.org/site/osgi-installer.html
> [4] http://sling.apache.org/site/configuration.html
> [5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
>
>
>> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
>
> Hope this helps
>
> best
> Rupert
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPV7d8AAoJEATpPYSyaoIkRoAH/ijByRUG/NnLtcmmHpjKEG4e
i6nx9whjSrDITtBiToYn5qyM0XOLN9T3QYWOMO4KJJpBI+IDyhjO2T3tpk1rwLfz
up6z0L8R4lW6smAThYQi88HtB7/VtC3/ial2FqnMAh8oDhsg/CCb6vDqb76qfhLD
1tJFTjMz/xbIp3eBZkoVqR8tC15WLaq4vIsVtz4jgNba3dKr0iRcOjR8ufEM77k0
gYyFe61sae0DNPaY2UjFh75QFIVGS1o3V4rGmw3SFYo5zRlvYnpLJ2hjeYrpHjV/
jzu8sVPDFlNA4Q7sEdLuFhhC2Gs8AzfaDDRCWckP4Ep01AS2l5Q1xdcDDdsgLpE=
=ptWu
-----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by Rupert Westenthaler <ru...@gmail.com>.
On 06.03.2012, at 21:55, ajs6f@virginia.edu wrote:
> Okay, I have the 'stable' suite up, with one exception: the Enhancer engine Refactor. I could not install it because it depends on OntoNet:
>
> Unresolved constraint in bundle org.apache.stanbol.enhancer.engines.refactor [505]: Unable to resolve 505.0: missing requirement [505.0] package; (package=org.apache.stanbol.ontologymanager.ontonet.api)
>
The refactor engine is not supposed to work within the stable launcher because it depends on the Ontonet and Rule modules that are not included in the stable launcher.
I think it was added to the Enhancer bundle list because it's an Enhancement Engine. However it should be rather part of the Rules bundle list.
> I'll try it again after I have the 'full' suite up. I'm not sure if that's supposed to be the case?
If you add the dependencies of the Ontonet Rule (and may be Reasoning) bundle lists the RefactorEngine should work just fine.
>
> In the meantime, I'm going to take a second look at the Sling Launchpad Maven plugin, since deployment to Karaf, if it is to be supported, must be integrated in a sensible way with the build machinery and this seems like the obvious first thing to try. Any advice from anyone who has successfully used it would be welcome! {grin}
thx great work!
best
Ruepert
Re: Stanbol on Karaf?
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Okay, I have the 'stable' suite up, with one exception: the Enhancer engine Refactor. I could not install it because it depends on OntoNet:
Unresolved constraint in bundle org.apache.stanbol.enhancer.engines.refactor [505]: Unable to resolve 505.0: missing requirement [505.0] package; (package=org.apache.stanbol.ontologymanager.ontonet.api)
I'll try it again after I have the 'full' suite up. I'm not sure if that's supposed to be the case?
In the meantime, I'm going to take a second look at the Sling Launchpad Maven plugin, since deployment to Karaf, if it is to be supported, must be integrated in a sensible way with the build machinery and this seems like the obvious first thing to try. Any advice from anyone who has successfully used it would be welcome! {grin}
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:
> Hi
>
> Sorry for the rather late replay, but we are currently very busy with
> preparing the first Stanbol release.
>
>
>
> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka <aj...@eservices.virginia.edu> wrote:
>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>>
>
> Thank you for the very positive feedback.
>
>> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>>
>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>>
>
> I do not have any experiences with Karaf, but assuming that you need
> also to configure the required bundles with start levels I can provide
> you with the following information that might help you to create a
> working configuration with Apache Karaf. In addition I will provide
> additional information on how Apache Stanbol uses the Apache Sling
> OSGI installer framework as I assume this will be the major hurdle you
> will need to overcome to successfully run Apache Stanbol in Karaf.
>
> Before I come to the details let me add two things:
>
> 1. If you have any problems feel free to ask here on the list or also
> on the #stanbol channel at "freenode.net"
> 2. If you have success it would be extremely nice if you could share
> you results with the Stanbol community
>
> - - - - - - - - - - - - - - -
>
> BundleLists:
>
> Apache Stanbol uses the "partial bundle list" feature of the Sling
> Launcher. This lists dependencies that are collected when building the
> launcher
>
> The following lists are required by Apache Stanbol:
>
> 1. OSGI framework bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
>
> I assume that you will already have most of those dependencies. I
> assume that you will not need "org.apache.sling.commons.log" because
> Karaf will have an own logging component.
>
> 2. Stanbol Commons bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
>
> There are some dependencies that need further investigation
>
> (a) Configuration: Apache Stanbol uses the sling osgi installer
> framework [3] for handling its configuration. So there will be no way
> around to getting this to run within Karaf.
>
> Related dependencies:
>
> * org.apache.sling.installer.core: This is used by Stanbol to
> install service configurations via the Configuration Admin. Such
> configuration are provided by the launcher (see e.g. [1] but are also
> be provided by the bundles via [2]. You will need this to run Apache
> Stanbol. See [3] for the documentation of the Sling installer. My
> guess is that this will run fine without Sling, but you might need to
> manually add some sling specific properties such as "sling.home" (see
> [4] for more infos).
>
> * org.apache.sling.installer.factory.configuration: required
> because it adds support for configurations (the main reason why
> Stanbol uses this)
>
> * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>
> * org.apache.sling.installer.provider.file: Optional: This is
> similar to the OSGI FileInstaller as it tracks files you add/remove to
> a configured directory. The directory is configured by the
> "sling.fileinstall.dir" property via the bundleContext#getProperty or
> "sling_fileinstall_dir" via System#getProperty. Because you will not
> be able to load the default configuration from the launcher [1] I
> would try to copy those files to a directory and load them by using
> the File installer.
>
> * org.apache.sling.launchpad.installer: This would normally copy
> the config from [1] during the first start of the sling launcher. I
> suppose that you will not be able to use this. Because of that I
> suggested to use the File Installer instead (see above). I think this
> will not be needed when using Karaf. Same for
> org.apache.sling.launchpad.api.
>
> * org.apache.stanbol.commons.solr.install: Note that the
> installation of SolrIndexes also depends on the Sling installer
> framework (see [5] for details)
>
> A final note to configurations: You need to make sure that the
> configuration for a Service is installed after the service was
> started. Otherwise the service for the configuration will not be
> activated correctly. Because of this I would suggest to use a start
> level >= 30 for the configurations. So keep an eye on the start level
> of the "org.apache.sling.installer.provider.file" as it will install
> the configurations in the configured directory as soon as it stats.
>
> (b) Jersey
>
> Apache Stanbol depends on Jersey as JAX-RS implementation (see
> STANBOL-352). So you will need to use Jersey for now.
>
> The rest of the dependencies should not have any issues.
>
> 3. Enhancer Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
>
> 4. Entityhub Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
>
> 5. Data Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
>
> --- Up to here all Bundle Lists are required to get the same
> functionality as of the Stable Launcher! ---
>
> The Full launcher uses additional Bundle list:
>
> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
> Allows to connect Stanbol directly with CMIS, JCR
>
> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
> I think this depends on the Enhancer and the CMS Adapter
>
> * FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
>
> * Ontology Manager:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
> * Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
> * Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
> Ontology manager, rules and reasoner should be only used together.
> Note that the RefactorEnhancementEngine
> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
> bundle list depends also on the availability of this.
>
>
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
> [2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
> [3] http://sling.apache.org/site/osgi-installer.html
> [4] http://sling.apache.org/site/configuration.html
> [5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
>
>
>> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
>
> Hope this helps
>
> best
> Rupert
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPVnngAAoJEATpPYSyaoIktNUIALvT+cxwWGN4EWbIn0Apu77i
5RILa/iQZDDyZVIGTZOXufUkHqKhvTAlv8mlEgdqgYrXrbK4soxGIZpI2uZhPStL
HA/EvvWn7Bz0Q+rGpD9OTmzZMnsZrgnu0Kurpd68xN8i7wSEc2H6T/YA4B1E/kVx
3tkQKyVPubvjUdRbQ4XD8UjrFW2Wt7eGKJyUrgOKMn4UPgIKy5mxYqJnFdy5yvrw
NvZ91n7n8SQS86E0FSk3zhJ4Yj7T7+EXplYyxlBl2QZqYP1kCLQjXgEZFJyp3Y60
oKMoQpLW91lysMBKdFbR65zQ/zaFU65FcXyVjRSMFAvM71vgw0sKEYyVwGBs7E4=
=e0S/
-----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by Rupert Westenthaler <ru...@gmail.com>.
On 06.03.2012, at 21:12, ajs6f@virginia.edu wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I should mentioned that I pulled out the Sling installer bundles as you suggested and had no trouble from it. Sling just assumed to use the working directory to install a home, so it's sitting there right in my Karaf home. Stanbol chose the same location for the SolrYard indexes. I'll try passing in sling.home as suggested to make sure that that's adjustable, but I'm not sure what to do about the indexes.
>
The directory for the "indexes" directory can be configured for the ManagedSolrServer (o.a.s.commons.solr.managed.impl.ManagedSolrServerImpl)
The directory for the data files folder can be changed in the configuration of the MainDataFileProvider (o.a.s.commons.stanboltools.datafileprovider.impl.MainDataFileProvider)
Re: Stanbol on Karaf?
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I should mentioned that I pulled out the Sling installer bundles as you suggested and had no trouble from it. Sling just assumed to use the working directory to install a home, so it's sitting there right in my Karaf home. Stanbol chose the same location for the SolrYard indexes. I'll try passing in sling.home as suggested to make sure that that's adjustable, but I'm not sure what to do about the indexes.
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:
> Hi
>
> Sorry for the rather late replay, but we are currently very busy with
> preparing the first Stanbol release.
>
>
>
> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka <aj...@eservices.virginia.edu> wrote:
>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>>
>
> Thank you for the very positive feedback.
>
>> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>>
>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>>
>
> I do not have any experiences with Karaf, but assuming that you need
> also to configure the required bundles with start levels I can provide
> you with the following information that might help you to create a
> working configuration with Apache Karaf. In addition I will provide
> additional information on how Apache Stanbol uses the Apache Sling
> OSGI installer framework as I assume this will be the major hurdle you
> will need to overcome to successfully run Apache Stanbol in Karaf.
>
> Before I come to the details let me add two things:
>
> 1. If you have any problems feel free to ask here on the list or also
> on the #stanbol channel at "freenode.net"
> 2. If you have success it would be extremely nice if you could share
> you results with the Stanbol community
>
> - - - - - - - - - - - - - - -
>
> BundleLists:
>
> Apache Stanbol uses the "partial bundle list" feature of the Sling
> Launcher. This lists dependencies that are collected when building the
> launcher
>
> The following lists are required by Apache Stanbol:
>
> 1. OSGI framework bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
>
> I assume that you will already have most of those dependencies. I
> assume that you will not need "org.apache.sling.commons.log" because
> Karaf will have an own logging component.
>
> 2. Stanbol Commons bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
>
> There are some dependencies that need further investigation
>
> (a) Configuration: Apache Stanbol uses the sling osgi installer
> framework [3] for handling its configuration. So there will be no way
> around to getting this to run within Karaf.
>
> Related dependencies:
>
> * org.apache.sling.installer.core: This is used by Stanbol to
> install service configurations via the Configuration Admin. Such
> configuration are provided by the launcher (see e.g. [1] but are also
> be provided by the bundles via [2]. You will need this to run Apache
> Stanbol. See [3] for the documentation of the Sling installer. My
> guess is that this will run fine without Sling, but you might need to
> manually add some sling specific properties such as "sling.home" (see
> [4] for more infos).
>
> * org.apache.sling.installer.factory.configuration: required
> because it adds support for configurations (the main reason why
> Stanbol uses this)
>
> * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>
> * org.apache.sling.installer.provider.file: Optional: This is
> similar to the OSGI FileInstaller as it tracks files you add/remove to
> a configured directory. The directory is configured by the
> "sling.fileinstall.dir" property via the bundleContext#getProperty or
> "sling_fileinstall_dir" via System#getProperty. Because you will not
> be able to load the default configuration from the launcher [1] I
> would try to copy those files to a directory and load them by using
> the File installer.
>
> * org.apache.sling.launchpad.installer: This would normally copy
> the config from [1] during the first start of the sling launcher. I
> suppose that you will not be able to use this. Because of that I
> suggested to use the File Installer instead (see above). I think this
> will not be needed when using Karaf. Same for
> org.apache.sling.launchpad.api.
>
> * org.apache.stanbol.commons.solr.install: Note that the
> installation of SolrIndexes also depends on the Sling installer
> framework (see [5] for details)
>
> A final note to configurations: You need to make sure that the
> configuration for a Service is installed after the service was
> started. Otherwise the service for the configuration will not be
> activated correctly. Because of this I would suggest to use a start
> level >= 30 for the configurations. So keep an eye on the start level
> of the "org.apache.sling.installer.provider.file" as it will install
> the configurations in the configured directory as soon as it stats.
>
> (b) Jersey
>
> Apache Stanbol depends on Jersey as JAX-RS implementation (see
> STANBOL-352). So you will need to use Jersey for now.
>
> The rest of the dependencies should not have any issues.
>
> 3. Enhancer Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
>
> 4. Entityhub Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
>
> 5. Data Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
>
> --- Up to here all Bundle Lists are required to get the same
> functionality as of the Stable Launcher! ---
>
> The Full launcher uses additional Bundle list:
>
> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
> Allows to connect Stanbol directly with CMIS, JCR
>
> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
> I think this depends on the Enhancer and the CMS Adapter
>
> * FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
>
> * Ontology Manager:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
> * Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
> * Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
> Ontology manager, rules and reasoner should be only used together.
> Note that the RefactorEnhancementEngine
> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
> bundle list depends also on the availability of this.
>
>
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
> [2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
> [3] http://sling.apache.org/site/osgi-installer.html
> [4] http://sling.apache.org/site/configuration.html
> [5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
>
>
>> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
>
> Hope this helps
>
> best
> Rupert
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPVm/FAAoJEATpPYSyaoIkZD8H/0gkJ6pWyGZZOhqkGFQu0uda
NAGfjKi9c9e01LCdbeFyo8Aflt420LDEy+mw7zFoFoiklQpxm3SwSH1SR2qVjvcY
I3kMUjJRolPF6pMx0yrdH17yDeT5XSjzC8QTxvRl64Ffe0fBUFz9mI6OAaejTk1+
7GwiLV2bWFxiVjYAfHswTZHDuwYmg5XvN5VkrYDMmYcN0KXlOnjJFGRGZtEeLD6k
jpOdakWHZgFGrNT3OubcGM4Ez7PGd9K74+0nRRwCEp2XFbCSj49zYpYx6V5x7myH
Y3C528+LPiVDs2nkcprh6hsXuksaOvZEKPBFImKn/mb7qrIIEAqc8yn9EvliSY4=
=CL1T
-----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is extremely helpful! Thank you.
I'll be looking at this Karaf question over the next week or two, and of course anything I discover will come back to the community. After all, this is open source! {grin}
I think I'll start with the 'stable' configuration. If I can get that working, 'full' shouldn't be too much further.
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Mar 6, 2012, at 4:24 AM, Rupert Westenthaler wrote:
> Hi
>
> Sorry for the rather late replay, but we are currently very busy with
> preparing the first Stanbol release.
>
>
>
> On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka <aj...@eservices.virginia.edu> wrote:
>> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>>
>
> Thank you for the very positive feedback.
>
>> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>>
>> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>>
>
> I do not have any experiences with Karaf, but assuming that you need
> also to configure the required bundles with start levels I can provide
> you with the following information that might help you to create a
> working configuration with Apache Karaf. In addition I will provide
> additional information on how Apache Stanbol uses the Apache Sling
> OSGI installer framework as I assume this will be the major hurdle you
> will need to overcome to successfully run Apache Stanbol in Karaf.
>
> Before I come to the details let me add two things:
>
> 1. If you have any problems feel free to ask here on the list or also
> on the #stanbol channel at "freenode.net"
> 2. If you have success it would be extremely nice if you could share
> you results with the Stanbol community
>
> - - - - - - - - - - - - - - -
>
> BundleLists:
>
> Apache Stanbol uses the "partial bundle list" feature of the Sling
> Launcher. This lists dependencies that are collected when building the
> launcher
>
> The following lists are required by Apache Stanbol:
>
> 1. OSGI framework bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
>
> I assume that you will already have most of those dependencies. I
> assume that you will not need "org.apache.sling.commons.log" because
> Karaf will have an own logging component.
>
> 2. Stanbol Commons bundle list:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
>
> There are some dependencies that need further investigation
>
> (a) Configuration: Apache Stanbol uses the sling osgi installer
> framework [3] for handling its configuration. So there will be no way
> around to getting this to run within Karaf.
>
> Related dependencies:
>
> * org.apache.sling.installer.core: This is used by Stanbol to
> install service configurations via the Configuration Admin. Such
> configuration are provided by the launcher (see e.g. [1] but are also
> be provided by the bundles via [2]. You will need this to run Apache
> Stanbol. See [3] for the documentation of the Sling installer. My
> guess is that this will run fine without Sling, but you might need to
> manually add some sling specific properties such as "sling.home" (see
> [4] for more infos).
>
> * org.apache.sling.installer.factory.configuration: required
> because it adds support for configurations (the main reason why
> Stanbol uses this)
>
> * org.apache.stanbol.commons.installer.bundleprovider: required for [2]
>
> * org.apache.sling.installer.provider.file: Optional: This is
> similar to the OSGI FileInstaller as it tracks files you add/remove to
> a configured directory. The directory is configured by the
> "sling.fileinstall.dir" property via the bundleContext#getProperty or
> "sling_fileinstall_dir" via System#getProperty. Because you will not
> be able to load the default configuration from the launcher [1] I
> would try to copy those files to a directory and load them by using
> the File installer.
>
> * org.apache.sling.launchpad.installer: This would normally copy
> the config from [1] during the first start of the sling launcher. I
> suppose that you will not be able to use this. Because of that I
> suggested to use the File Installer instead (see above). I think this
> will not be needed when using Karaf. Same for
> org.apache.sling.launchpad.api.
>
> * org.apache.stanbol.commons.solr.install: Note that the
> installation of SolrIndexes also depends on the Sling installer
> framework (see [5] for details)
>
> A final note to configurations: You need to make sure that the
> configuration for a Service is installed after the service was
> started. Otherwise the service for the configuration will not be
> activated correctly. Because of this I would suggest to use a start
> level >= 30 for the configurations. So keep an eye on the start level
> of the "org.apache.sling.installer.provider.file" as it will install
> the configurations in the configured directory as soon as it stats.
>
> (b) Jersey
>
> Apache Stanbol depends on Jersey as JAX-RS implementation (see
> STANBOL-352). So you will need to use Jersey for now.
>
> The rest of the dependencies should not have any issues.
>
> 3. Enhancer Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
>
> 4. Entityhub Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
>
> 5. Data Bundle List:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
>
> --- Up to here all Bundle Lists are required to get the same
> functionality as of the Stable Launcher! ---
>
> The Full launcher uses additional Bundle list:
>
> * CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
> Allows to connect Stanbol directly with CMIS, JCR
>
> * Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
> I think this depends on the Enhancer and the CMS Adapter
>
> * FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
>
> * Ontology Manager:
> http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
> * Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
> * Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
> Ontology manager, rules and reasoner should be only used together.
> Note that the RefactorEnhancementEngine
> (org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
> bundle list depends also on the availability of this.
>
>
>
> [1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
> [2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
> [3] http://sling.apache.org/site/osgi-installer.html
> [4] http://sling.apache.org/site/configuration.html
> [5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
>
>
>> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
>
> Hope this helps
>
> best
> Rupert
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPVgXlAAoJEATpPYSyaoIkMBgH/1h+EC7kAuVYhzAxgSWgby0D
62E0+Q7FhyVCNC81CRxdxRtefi/lMC2pj0MjuZIpQJtjWR5WEYnMvnxB1+zM06K9
Pxl0dZAIbl8LaTk06apoAxkrStHnkHTeM7uyhcegwHd6C6AsqOcdHhrIe+0hxNmR
DiGc7DSzyAdl2mxy82ZPNLrC/Uu/ZkRX81dQUaOcEKGPrS3ipy69yocDfsIcQt4y
sPb47drO8mgS1x1rdWEFUVfwJAmiOx5XQcjpfj4ywu7LY9HZpHLdoO/XpZY4LZLz
og2kHBQLSBkMHg3+eTDRfPvAtTrTU58KSqUt1qoe4WpuB+ebT2XcrgneZYTrq8s=
=gMLy
-----END PGP SIGNATURE-----
Re: Stanbol on Karaf?
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi
Sorry for the rather late replay, but we are currently very busy with
preparing the first Stanbol release.
On Thu, Mar 1, 2012 at 11:00 PM, A. Soroka <aj...@eservices.virginia.edu> wrote:
> Firstly, let me congratulate all of you on a fantastic project! I'm having a lot of fun exploring IKS and Stanbol (having been clued in by Steve Bayliss). It took no time at all to get some simple integrations going, using Stanbol to supply services for SKOS thesauri to some XForms applications, and I was impressed by how quickly I could index and deploy new vocabularies.
>
Thank you for the very positive feedback.
> I've got a question about Stanbol's build and deployment. Currently, it uses the Sling launcher gear to assemble components into an instance. I see that there is some support in Sling (via their Maven Launchpad Plugin) for creating Apache Karaf feature-repositories for Sling-based assemblages. We're invested in Karaf at my site through our use of ServiceMix, and I would very much like to be able to reuse that investment and knowledge.
>
> Does anyone out there in Stanbol-land deploy Stanbol to Karaf via the feature-repository functionality? Is there any experience with this or any known pitfalls?
>
I do not have any experiences with Karaf, but assuming that you need
also to configure the required bundles with start levels I can provide
you with the following information that might help you to create a
working configuration with Apache Karaf. In addition I will provide
additional information on how Apache Stanbol uses the Apache Sling
OSGI installer framework as I assume this will be the major hurdle you
will need to overcome to successfully run Apache Stanbol in Karaf.
Before I come to the details let me add two things:
1. If you have any problems feel free to ask here on the list or also
on the #stanbol channel at "freenode.net"
2. If you have success it would be extremely nice if you could share
you results with the Stanbol community
- - - - - - - - - - - - - - -
BundleLists:
Apache Stanbol uses the "partial bundle list" feature of the Sling
Launcher. This lists dependencies that are collected when building the
launcher
The following lists are required by Apache Stanbol:
1. OSGI framework bundle list:
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/osgiframework/src/main/bundles/list.xml
I assume that you will already have most of those dependencies. I
assume that you will not need "org.apache.sling.commons.log" because
Karaf will have an own logging component.
2. Stanbol Commons bundle list:
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/bundlelists/stanbolcommons/src/main/bundles/list.xml
There are some dependencies that need further investigation
(a) Configuration: Apache Stanbol uses the sling osgi installer
framework [3] for handling its configuration. So there will be no way
around to getting this to run within Karaf.
Related dependencies:
* org.apache.sling.installer.core: This is used by Stanbol to
install service configurations via the Configuration Admin. Such
configuration are provided by the launcher (see e.g. [1] but are also
be provided by the bundles via [2]. You will need this to run Apache
Stanbol. See [3] for the documentation of the Sling installer. My
guess is that this will run fine without Sling, but you might need to
manually add some sling specific properties such as "sling.home" (see
[4] for more infos).
* org.apache.sling.installer.factory.configuration: required
because it adds support for configurations (the main reason why
Stanbol uses this)
* org.apache.stanbol.commons.installer.bundleprovider: required for [2]
* org.apache.sling.installer.provider.file: Optional: This is
similar to the OSGI FileInstaller as it tracks files you add/remove to
a configured directory. The directory is configured by the
"sling.fileinstall.dir" property via the bundleContext#getProperty or
"sling_fileinstall_dir" via System#getProperty. Because you will not
be able to load the default configuration from the launcher [1] I
would try to copy those files to a directory and load them by using
the File installer.
* org.apache.sling.launchpad.installer: This would normally copy
the config from [1] during the first start of the sling launcher. I
suppose that you will not be able to use this. Because of that I
suggested to use the File Installer instead (see above). I think this
will not be needed when using Karaf. Same for
org.apache.sling.launchpad.api.
* org.apache.stanbol.commons.solr.install: Note that the
installation of SolrIndexes also depends on the Sling installer
framework (see [5] for details)
A final note to configurations: You need to make sure that the
configuration for a Service is installed after the service was
started. Otherwise the service for the configuration will not be
activated correctly. Because of this I would suggest to use a start
level >= 30 for the configurations. So keep an eye on the start level
of the "org.apache.sling.installer.provider.file" as it will install
the configurations in the configured directory as soon as it stats.
(b) Jersey
Apache Stanbol depends on Jersey as JAX-RS implementation (see
STANBOL-352). So you will need to use Jersey for now.
The rest of the dependencies should not have any issues.
3. Enhancer Bundle List:
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/bundlelist/src/main/bundles/list.xml
4. Entityhub Bundle List:
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/bundlelist/src/main/bundles/list.xml
5. Data Bundle List:
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/data/bundlelist/src/main/bundles/list.xml
--- Up to here all Bundle Lists are required to get the same
functionality as of the Stable Launcher! ---
The Full launcher uses additional Bundle list:
* CMS Adapter: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/cmsadapter/bundlelist/src/main/bundles/list.xml
Allows to connect Stanbol directly with CMIS, JCR
* Contenthub: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/contenthub/bundlelist/src/main/bundles/list.xml
I think this depends on the Enhancer and the CMS Adapter
* FactStore: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/factstore/bundlelist/src/main/bundles/list.xml
* Ontology Manager:
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/ontologymanager/bundlelist/src/main/bundles/list.xml
* Rules: http://svn.apache.org/repos/asf/incubator/stanbol/trunk/rules/bundlelist/src/main/bundles/list.xml
* Reasoners http://svn.apache.org/repos/asf/incubator/stanbol/trunk/reasoners/bundlelist/src/main/bundles/list.xml
Ontology manager, rules and reasoner should be only used together.
Note that the RefactorEnhancementEngine
(org.apache.stanbol.enhancer.engines.refactor) part of the Enhancer
bundle list depends also on the availability of this.
[1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/full/src/main/resources/resources/config/
[2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/installer/bundleprovider/README.md
[3] http://sling.apache.org/site/osgi-installer.html
[4] http://sling.apache.org/site/configuration.html
[5] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/solr/README.md
> Thanks again for a really elegant set of software components. I'm looking forward to exploring more!
Hope this helps
best
Rupert
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen