I believe Alasdair's referring to Jarek's changes on June 24 under Jira ARIES-341 - " Also updated the code to ensure the system and local repositories are included in repository set used in resolver. Changes committed in revision 957403."
Alasdair raised concerns in this post: http://mail-archives.apache.org/mod_mbox/incubator-aries-dev/201006.mbox/%[email protected]%3e - the thread is visible here: http://mail-archives.apache.org/mod_mbox/incubator-aries-dev/201006.mbox/thread?2 but doesn't seem to have resulted in any code changes. >From what I can tell, we were all happy to add a switch to turn resolving against the local repository on or off, but I'm not sure we agreed on its default position. Regards, Mark On 17 November 2010 12:19, Alasdair Nottingham <[email protected]> wrote: > 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] >
