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]

Reply via email to