I think we should keep the current behavior and make it configurable. Not all environments support isolation.
Jarek On Mon, Nov 15, 2010 at 10:51 AM, Emily Jiang <[email protected]> wrote: > A month ago, I raised a question about disabling resolving an application > against local platform repository (runtime bundles). No one seems to object > the idea. I will go ahead to make the changes tomorrow not to provision > against the runtime bundles when provisioning an EBA application. If you > have any different opinion, please shout now. > > Thanks > Emily > ---------- Forwarded message ---------- > From: Emily Jiang <[email protected]> > Date: 15 October 2010 14:23 > Subject: [Discussion] resolving against local platform repository > To: [email protected] > > > At the moment, our aries resolver resolves eba files against local > platform repositories, which means that customer bundles will be able to > import packages exported by our runtime bundles, such as > org.apache.aries.application.api_0.3.0.incubating-SNAPSHOT. Ideally, we > should not allow customer bundles depend on our runtime bundles, which > should be private to our own runtime framework. I think not many ( or even > none:o) App Server would like to expose their internal to customer > bundles. Any objections for excluding the local runtime bundles when we > perform provisioning? > > If we do decide to keep the current behaviour, we should give an option to > the app servers to alter this behaviour (e.g. make their runtime bundles > invisible to provisioner). Thoughts? > > Below are the subset of the runtime bundles for setting up itests: > {1=org.ops4j.pax.exam_1.2.0 [1], > 2=org.ops4j.pax.exam.junit.extender_1.2.0 [2], > 3=org.ops4j.pax.exam.junit.extender.impl_1.2.0 [3], > 4=wrap_mvn_org.ops4j.pax.exam_pax-exam-junit_1.2.0_0.0.0 [4], > 5=org.ops4j.pax.logging.pax-logging-api_1.4.0 [5], > 6=org.ops4j.pax.logging.pax-logging-service_1.4.0 [6], > 7=org.apache.felix.configadmin_1.2.4 [7], > 8=org.ops4j.pax.url.mvn_1.1.2 [8], > 9=org.apache.aries.application.api_0.3.0.incubating-SNAPSHOT [9], > 10=org.apache.aries.application.utils_0.3.0.incubating-SNAPSHOT [10], > 11=org.apache.aries.application.management_0.3.0.incubating-SNAPSHOT > [11], > > 12=org.apache.aries.application.default.local.platform_0.3.0.incubating-SNAPSHOT > [12], > > 13=org.apache.aries.application.noop.platform.repo_0.3.0.incubating-SNAPSHOT > [13], > > 14=org.apache.aries.application.noop.postresolve.process_0.3.0.incubating-SNAPSHOT > [14], > 15=org.apache.aries.application.runtime_0.3.0.incubating-SNAPSHOT [15], > 16=org.apache.aries.application.resolver.obr_0.3.0.incubating-SNAPSHOT > [16], > > 17=org.apache.aries.application.deployment.management_0.3.0.incubating-SNAPSHOT > [17], > 18=org.apache.aries.application.modeller_0.3.0.incubating-SNAPSHOT [18], > 19=org.apache.felix.bundlerepository_1.6.4 [19], > > 20=org.apache.aries.application.runtime.itest.interfaces_0.3.0.incubating-SNAPSHOT > [20], > 21=org.apache.aries.util_0.3.0.incubating-SNAPSHOT [21], > 22=org.apache.aries.blueprint_0.3.0.incubating-SNAPSHOT [22], > 23=osgi.cmpn_4.2.0.200908310645 [23], ....} > > > Many thanks and kindest regards, > Emily > =========================== > Emily Jiang > > > -- > Thanks > Emily > ================= > Emily Jiang > [email protected] >
