I've pushed what I have so far. Starting from a minimal distribution, you can do the following:
> feature:install --region root/aries aries-blueprint > feature:install --region root/gemini gemini-blueprint > feature:regions -v Note that bundle commands currently have a limited visibility, so if you use bundle:list, you should only see the bundles in the root region. The nice thing is that all the deployment computation is done in a single resolution. 2014-04-17 9:56 GMT+02:00 Guillaume Nodet <[email protected]>: > Reminder: region is a concept which allows partitioning the OSGi framework > between multiple defined regions and control the visibility of bundles, > packages and services while crossing regions. This allow the same bundle > to be deployed in two different regions if the regions can't see each other > (that's simplifying a bit, but you get the idea). > > Unless I'm wrong, support for regions in Karaf 3.x is very limited and > while we have a few commands to view and operate on regions. Currently, > the region where a feature is deployed has to be written in the feature > descriptor (which makes deploying the same feature in 2 different regions > quite difficult) and there's no option for sharing policies between regions. > > I've recently added support for Aries Subsystems in master. While > Subsystems could theoretically fulfil our needs, we still have the same > problems than with applications: i.e. it's totally unmanageable without > tooling. > > What I'd like to do, is get rid of the current region support to have the > feature service more aware of regions. The idea is to have the following: > * a "root" region > * multiple user created child regions for isolation (import everything > from the parent, but share nothing) as a tree > Those regions are organized in a tree: > root > root/container1 > root/container2 > root/container2/spring2 > root/container2/spring3 > > When installing / uninstalling features, the user will have to provide the > region path in which the new features should be added or removed. > > By default, features would be flattened, i.e, bundles are deployed > directly in the region, however, features can specify a custom sharing > policy so that the internal (services and packages) is hidden and not > visible outside of the region. For example, the aries-proxy could be > defined with the following: > > <feature name="aries-proxy" description="Aries Proxy" > version="${project.version}"> > <bundle dependency="true" > start-level="20">mvn:org.ow2.asm/asm-all/${asm.version}</bundle> > <bundle dependency="true" > start-level="20">mvn:org.apache.aries/org.apache.aries.util/${aries.util.version}</bundle> > <bundle > start-level="20">mvn:org.apache.aries.proxy/org.apache.aries.proxy.api/${aries.proxy.api.version}</bundle> > <bundle > start-level="20">mvn:org.apache.aries.proxy/org.apache.aries.proxy.impl/${aries.proxy.version}</bundle> > <capability> > > service-reference;effective:=active;objectClass=org.apache.aries.proxy.ProxyManager > </capability> > <scoping> > <export namespace="osgi.service"> > (objectClass=org.apache.aries.proxy.ProxyManager) > </export> > <export namespace="osgi.wiring.package"> > > (|(osgi.wiring.package=org.apache.aries.proxy)(osgi.wiring.package=org.apache.aries.proxy.*)) > </export> > <import namespace="org.eclipse.equinox.allow.all"> > (|(!(all=*))(all=*)) > </import> > </scoping> > </feature> > > The <scoping> element defines a custom policy. In the above case, the > only thing exported from the region is the org.apache.aries.proxy.* > packages and the org.apache.aries.proxy.ProxyManager service. The region > imports everything. > This is really just an example and while the syntax is what i'm > experimenting with now, the idea is to simplify it so that the user would > write "package", "service", "all" and with dedicated elements to help. > > Those scoped features will also create regions automatically, so that the > above when deployed into root/apps1 would create a child region > /root/apps1/aries-proxy-4.0.0-SNAPSHOT. > > The features service will be responsible for computing the regions and > which and where bundles need to be deployed using the OSGi resolver. > > Anyway, I'm still experimenting, but I wanted to give a heads up on this > point. > > Cheers, > Guillaume Nodet > >
