aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: [Discussion] resolving against local platform repository
Date Mon, 15 Nov 2010 16:49:27 GMT
Hi, not sure what this has to do with isolation.

Alasdair

On 15 Nov 2010, at 16:13, Jarek Gawor <jgawor@gmail.com> 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 <emijiang6@googlemail.com> 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 <EMIJIANG@uk.ibm.com>
>> Date: 15 October 2010 14:23
>> Subject: [Discussion] resolving against local platform repository
>> To: aries-dev@incubator.apache.org
>> 
>> 
>> 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
>> ejiang@apache.org
>> 

Mime
View raw message