Hi Jarek, Alasdair was correct that this was not related to isolation and it was our policy on provisioning.
Are you happy with the suggestion of choosing not to provision against local platform repositories (runtime jars)? Thanks Emily On Mon, Nov 15, 2010 at 4:49 PM, Alasdair Nottingham <[email protected]> wrote: > Hi, not sure what this has to do with isolation. > > Alasdair > > On 15 Nov 2010, at 16:13, Jarek Gawor <[email protected]> wrote: > > > 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] > >> > -- Thanks Emily ================= Emily Jiang [email protected]
