Hi, OBR used to hide local bundles from the resolve results, is this still the case? If so I would prefer the default be to not resolve against the local framework.
Alasdair On 17 November 2010 11:18, Emily Jiang <[email protected]> wrote: > Yes, Mark. I plan to commit my own patch on > https://issues.apache.org/jira/browse/ARIES-460 for documenting the new > application.mf and deployment.mf. In addition, I will produce a full picture > on application module to detail what the bundles you need to be able to use > application module and which bundles you should provide your own etc. > Thanks > Emily > > On Wed, Nov 17, 2010 at 10:55 AM, Mark Nuttall <[email protected]> wrote: > >> Emily, >> That sounds reasonable to me. Will you add this to your >> documentation-to-do list? >> >> Regards, >> Mark >> >> On 17 November 2010 10:31, Emily Jiang <[email protected]> wrote: >> > 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] >> > >> > > > > -- > Thanks > Emily > ================= > Emily Jiang > [email protected] > -- Alasdair Nottingham [email protected]
