Hi Rupert This sounds good.
On little issue: I've been also using the bundlelists to add features at runtime (using the shell). This might get harder if they have dependencies. Maybe we could generate karaf feature descriptors. This seems to work with the launchpad plugin both for partial-bundlelist as well as for the launcher. However they are just flat lists, it would be nicer if they would reference the features generated by other partialbundlelist. Anyway, if things get refactored it would be nice to have a solution that works at runtime too. Cheers, Reto On Fri, Feb 8, 2013 at 3:51 PM, Rupert Westenthaler < [email protected]> wrote: > Hi all > > The last few days I was working on making the Stanbol Launchers (and > bundle lists used for launchers) more flexible. > > While building customized launchers is already possible now (see also > the production-mode [1] on the Webpage) the current solution was not > very easy to use. The main reason for that was that the current > `partialbundlelists` had dependencies between them that where not > exposed to the maven build system (e.g. the enhancer bundlelist > assumed the stanbolcommons and osgiframework to be present). > > This was also the reason why there where only very few bundle lists, > because making them more fine grained would have been not management > able. > > With STANBOL-915 [2] this will change. Bundlelists now define maven > dependencies to others they depend on. For the user this means that if > he want a feature to be present in his custom launcher, he needs only > declare a dependency to this feature in the pom.xml file of his > launcher and maven will automatically include all necessary modules > for that feature! > > The new system uses two levels of bundle lists: > > 1. Module (Feature) level: Those bundle lists allow users to add > specific features (e.g. Apache Tika based Enhancement Engines, Solr > Based Storage for the Entityhub) > 2. Component level: This are bundle lists providing a Stanbol > Component (e.g. the Stanbol Enhancer with typical Enhancement Engines) > > The idea is that users will start to build custom Stanbol Launchers by > using the Component level lists. E.g. Stanbol Enhancer & Stanbol > Entityhub plus some custom Enhancement Engines. The feature level > lists will allow expert users to build even more focused Launchers for > special use cases (e.g. Users that directly access the Java API might > want a launcher without the RESTful interface). > > The first version [3] also defines some new launcher configurations > > * stateless: Enhaner + Entityhub > * semindex: Contenthub + Enhancer + Entityhub + CMSAdapter > * kres: ontologymanager + reasoning + rules > > all those new launchers DO NOT include the default data (e.g. the > dbpedia index nor OpenNLP modules. This will give us also the > possibility to release binary versions of those. > > Development is done in an own branch. Please also note SLING-2722 [4] > an extension to the Apache Sling maven-launchpad-plugin - that is > required to support transitive dependencies of partialbundlelists. > > best > Rupert > > > [1] http://stanbol.apache.org/docs/trunk/production-mode/ > [2] https://issues.apache.org/jira/browse/STANBOL-915 > [3] http://svn.apache.org/r1444025 > [4] https://issues.apache.org/jira/browse/SLING-2722 > > -- > | Rupert Westenthaler [email protected] > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen >
