Based on Jarek's comments, we can make the provisioning against local runtime configurable via a system variable, "provision.exclude.local.repository". The default behaviour is that we provision EBA applications against the local runtimes (apache aries default behaviour) unless the system variable is set to true. In this way, any application servers can set this system variable to 'true' in their environment if they want to change the default behaviour. We won't need to change apache aries default behaviour.
What do people think? Thanks Emily On Mon, Nov 15, 2010 at 8:02 PM, Jarek Gawor <[email protected]> wrote: > Emily, > > Maybe I misunderstood what you meant in your original email but here's > what I'm thinking of. If I install some eba that has logging api > dependencies and my rumtime provides logging api I want the eba to use > the logging api provided by the runtime. > > Jarek > > On Mon, Nov 15, 2010 at 12:29 PM, Emily Jiang <[email protected]> > wrote: > > 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] > > > -- Thanks Emily ================= Emily Jiang [email protected]
