[HEADS UP] Region support in Karaf 4.x
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=20mvn:org.ow2.asm/asm-all/${asm.version}/bundle
bundle dependency=true
start-level=20mvn:org.apache.aries/org.apache.aries.util/${aries.util.version}/bundle
bundle
start-level=20mvn:org.apache.aries.proxy/org.apache.aries.proxy.api/${aries.proxy.api.version}/bundle
bundle
start-level=20mvn: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
Re: [HEADS UP] Region support in Karaf 4.x
Hi Guillaume,
thanks for the Head-up. The first time I had contact with some sort of
region was while playing around with the spring-dm-server (now Virgo) and
tbh. I didn't like it.
Especially this separation of kernel- and user-land for bundles been a big
pita and quite confusing,
the worst thing about it, I needed to install bundles twice. This is
something I surely don't want for Karaf. We need to make sure this doesn't
bloat everything as it did for Virgo.
Besides this :)
The idea of the regions especially for having spring2 and spring3
applications running on the same container does seem quite tempting. Are
bundles of the root region to be shared with the underlying region. And
doesn't the region concept go back to a hierarchical classloader? Like what
we have in a JEE server? (Beware I'm in devels advocate mode) While at it,
wouldn't this mean Karaf ends up doing the same as a standard JEE server
with the hierarchical classloader and what is the purpose of Karaf then?
Don't we loose all the benefits of OSGi at this point, shouldn't people
just develop EAR applications then again?
regards, Achim
2014-04-17 9:56 GMT+02:00 Guillaume Nodet gno...@apache.org:
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=20mvn:org.ow2.asm/asm-all/${asm.version}/bundle
bundle dependency=true
start-level=20mvn:org.apache.aries/org.apache.aries.util/${aries.util.version}/bundle
bundle
start-level=20mvn:org.apache.aries.proxy/org.apache.aries.proxy.api/${aries.proxy.api.version}/bundle
bundle
start-level=20mvn: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
Re: [HEADS UP] Region support in Karaf 4.x
Hi Achim, as far as I understood the concept regions control visibility of bundles. So when for example the spring 2 bundles are visible in a region then the resolver will wire bundle imports to them. If they are not visible the resolver does not wire them. So I think the classloading is not really different from plain OSGi. Only the resolver wires differently. I hope my assumptions here are correct :-) Christian On 17.04.2014 13:16, Achim Nierbeck wrote: Hi Guillaume, thanks for the Head-up. The first time I had contact with some sort of region was while playing around with the spring-dm-server (now Virgo) and tbh. I didn't like it. Especially this separation of kernel- and user-land for bundles been a big pita and quite confusing, the worst thing about it, I needed to install bundles twice. This is something I surely don't want for Karaf. We need to make sure this doesn't bloat everything as it did for Virgo. Besides this :) The idea of the regions especially for having spring2 and spring3 applications running on the same container does seem quite tempting. Are bundles of the root region to be shared with the underlying region. And doesn't the region concept go back to a hierarchical classloader? Like what we have in a JEE server? (Beware I'm in devels advocate mode) While at it, wouldn't this mean Karaf ends up doing the same as a standard JEE server with the hierarchical classloader and what is the purpose of Karaf then? Don't we loose all the benefits of OSGi at this point, shouldn't people just develop EAR applications then again? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [HEADS UP] Region support in Karaf 4.x
Yes, you're right about a lot of things. Regions end up creating some kind of hierarchical classloader tree similar to JEE. In theory, regions define a graph, not a tree, but it's quite difficult to manage from a user pov, so limiting to a tree makes things easier imho. Using a graph instead of a tree could be interesting, as we could isolate features, but still use them in a graph. At a pure package level, we could imagine you would install the spring2 and spring3 features, and another scoped feature could say that it depends on spring2 and thus would not be allowed to see spring3 bundles. But we can achieve the same simple use cases using a tree really. Anyway, I have the following requirements in mind: * the use of regions is optional : even if the code supports it, and even if it's enabled by default, given the deployer explicitely require to install a feature on a given region, the default behavior would be the same as today and all features would be installed to the root region by default. So unless the user explicitely requires an installation onto a different region, the behavior would be the same. * unless explicitely stated otherwise in the feature scoping element, regions do inherit from all their parent capabilities, so if you define an isolated region root/apps, any feature deployed on the root region would be available So you're actually right when you describe the whole system as a classloader tree. However, regions isolate more than just packages, especially bundle visibility (which can be interesting when working with extenders such as aries-blueprint and gemini-blueprint) and service visibility. One big use case I have in mind is if you want to allow deployment of bundles by a third party : you may want to tightly control the region so that bundles from the third party can't see your internal stuff (and can't mess with it) and also isolate bundles from a third party from another (multi-tenant applications). 2014-04-17 13:16 GMT+02:00 Achim Nierbeck bcanh...@googlemail.com: Hi Guillaume, thanks for the Head-up. The first time I had contact with some sort of region was while playing around with the spring-dm-server (now Virgo) and tbh. I didn't like it. Especially this separation of kernel- and user-land for bundles been a big pita and quite confusing, the worst thing about it, I needed to install bundles twice. This is something I surely don't want for Karaf. We need to make sure this doesn't bloat everything as it did for Virgo. Besides this :) The idea of the regions especially for having spring2 and spring3 applications running on the same container does seem quite tempting. Are bundles of the root region to be shared with the underlying region. And doesn't the region concept go back to a hierarchical classloader? Like what we have in a JEE server? (Beware I'm in devels advocate mode) While at it, wouldn't this mean Karaf ends up doing the same as a standard JEE server with the hierarchical classloader and what is the purpose of Karaf then? Don't we loose all the benefits of OSGi at this point, shouldn't people just develop EAR applications then again? regards, Achim 2014-04-17 9:56 GMT+02:00 Guillaume Nodet gno...@apache.org: 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
Re: Build freezes when the invoker plugin is invoked
Hi, building the latest 3.0.2-SNAPSHOT did work right away, it only failed for a integration test, but we had some issues with that during the release also. Master I didn't test yet. regards, Achim 2014-04-15 23:36 GMT+02:00 Krzysztof Sobkowiak krzys.sobkow...@gmail.com: Hi I'm trying to build (mvn clean install) the master or 3.0.x branch and the build freezes when invoking the invoker plugin [INFO] [INFO] --- maven-invoker-plugin:1.6:run (integration-test) @ karaf-maven-plugin --- [INFO] Building: test-check-dependencies/pom.xml Building the code usingmvn install -DskipTests helps, but disables the tests. After this run evenmvn install works. But mvn clean install freezes again. Do you have any good solution for this problem? Best regards Krzysztof -- Krzysztof Sobkowiak JEE OSS Architect | Technical Architect @ Capgemini Capgemini http://www.pl.capgemini.com/ | Software Solutions Center http://www.pl.capgemini-sdm.com/ | Wroclaw e-mail: krzys.sobkow...@gmail.com mailto:krzys.sobkow...@gmail.com | Twitter: @KSobkowiak -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead blog http://notizblog.nierbeck.de/ Software Architect / Project Manager / Scrum Master
Re: [HEADS UP] Region support in Karaf 4.x
+1000 for removing the existing region support I added before the subsystems
spec was ready.
I don't understand why you want to do the rest. Could you elaborate on what
your proposal does that can't be done with spec subsystems? Also, what tooling
is missing for spec subsystems?
I always thought that when the subsystems spec was ready karat would drop its
proprietary features.
thanks
david jencks
On Apr 17, 2014, at 12:56 AM, Guillaume Nodet gno...@apache.org wrote:
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=20mvn:org.ow2.asm/asm-all/${asm.version}/bundle
bundle dependency=true
start-level=20mvn:org.apache.aries/org.apache.aries.util/${aries.util.version}/bundle
bundle
start-level=20mvn:org.apache.aries.proxy/org.apache.aries.proxy.api/${aries.proxy.api.version}/bundle
bundle
start-level=20mvn: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
Re: Annotation processing in war deployed to karaf 3.0.0
I just test @MultipartConfig on Karaf 3.0.1. It's works! Thank you! -- View this message in context: http://karaf.922171.n3.nabble.com/Annotation-processing-in-war-deployed-to-karaf-3-0-0-tp4031937p4032847.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Annotation processing in war deployed to karaf 3.0.0
Awsome :) been a pleasure :) 2014-04-17 20:16 GMT+02:00 lis0x90 lis0...@gmail.com: I just test @MultipartConfig on Karaf 3.0.1. It's works! Thank you! -- View this message in context: http://karaf.922171.n3.nabble.com/Annotation-processing-in-war-deployed-to-karaf-3-0-0-tp4031937p4032847.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead blog http://notizblog.nierbeck.de/ Software Architect / Project Manager / Scrum Master
Re: [HEADS UP] Region support in Karaf 4.x
I like idea of having regions and/or subsystens. We currently run multiple
applications and layering” of some things would work great for us. Now
services published by one bundle might be consumed by any other module which is
fine but very relax. For example database connection should not be visible out
of persistence module to deny dirtness of architecture.
What I have found bad in subsystems spec is packaging. EBA, ESA and all these
forms of MANIFEST.MF seems to be big overhead. Maven integration was not great
couple months ago and at runtime it was not working (Karaf 2.2.x). But again, I
didn’t try it since a while. If we could push new bundles to subsystems easily
without that then it would make sense to integrate with it instead of writing
everything from scratch.
Kind regards,
Łukasz Dywicki
--
l...@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
Wiadomość napisana przez David Jencks david_jen...@yahoo.com w dniu 17 kwi
2014, o godz. 19:08:
+1000 for removing the existing region support I added before the subsystems
spec was ready.
I don't understand why you want to do the rest. Could you elaborate on what
your proposal does that can't be done with spec subsystems? Also, what
tooling is missing for spec subsystems?
I always thought that when the subsystems spec was ready karat would drop its
proprietary features.
thanks
david jencks
On Apr 17, 2014, at 12:56 AM, Guillaume Nodet gno...@apache.org wrote:
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=20mvn:org.ow2.asm/asm-all/${asm.version}/bundle
bundle dependency=true
start-level=20mvn:org.apache.aries/org.apache.aries.util/${aries.util.version}/bundle
bundle
start-level=20mvn:org.apache.aries.proxy/org.apache.aries.proxy.api/${aries.proxy.api.version}/bundle
bundle
start-level=20mvn: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
Re: [HEADS UP] Region support in Karaf 4.x
Here are a few missing things that are supported with features and not
subsystems (api or impl), roughtly sorted from less important to more
important. The first point is really an implementation limitation, the
others are more related to the spec.
* missing configurations support
* missing conditional features
* require zip packaging with multiple files, so you need tooling
* you need to either embed the dependencies or manage a repository, you
can't a uri as we do with maven urls for most of our stuff
* limited resolver support : computed dependencies could actually not be
used (that's the same we had with features in karaf 2.x and 3.x actually,
but now the 4.x features use a real resolver : we start from requirements
and compute the needed dependencies, the diff wrt the current state and
apply it)
* no support for updates (related to the above) which also means no
ability to patch
Guillaume
2014-04-17 19:08 GMT+02:00 David Jencks david_jen...@yahoo.com:
+1000 for removing the existing region support I added before the
subsystems spec was ready.
I don't understand why you want to do the rest. Could you elaborate on
what your proposal does that can't be done with spec subsystems? Also,
what tooling is missing for spec subsystems?
I always thought that when the subsystems spec was ready karat would drop
its proprietary features.
thanks
david jencks
On Apr 17, 2014, at 12:56 AM, Guillaume Nodet gno...@apache.org wrote:
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=20mvn:org.ow2.asm/asm-all/${asm.version}/bundle
bundle dependency=true
start-level=20mvn:org.apache.aries/org.apache.aries.util/${aries.util.version}/bundle
bundle
start-level=20mvn:org.apache.aries.proxy/org.apache.aries.proxy.api/${aries.proxy.api.version}/bundle
bundle
start-level=20mvn: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
