You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Emily Jiang <EM...@uk.ibm.com> on 2010/10/15 15:23:31 UTC
[Discussion] resolving against local platform repository
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
WebSphere ESB Foundation Technologies
MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang@uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [Discussion] resolving against local platform repository
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Nov 17, 2010 at 7:56 AM, Mark Nuttall <mn...@apache.org> wrote:
> 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."
Ah, yes. Thanks for finding this. This was addressing a specific
problem I've ran into.
> Alasdair raised concerns in this post:
> http://mail-archives.apache.org/mod_mbox/incubator-aries-dev/201006.mbox/%3CAANLkTinn8lEIMgOGp5KASqLaUc4XKc43qwSdrH5LhkOK@mail.gmail.com%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.
At the time the concern was about generating an incomplete
deployment.mf. That was addressed in
http://svn.apache.org/viewvc?view=revision&revision=964138
(ARIES-358).
Jarek
Re: [Discussion] resolving against local platform repository
Posted by Mark Nuttall <mn...@apache.org>.
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/%3CAANLkTinn8lEIMgOGp5KASqLaUc4XKc43qwSdrH5LhkOK@mail.gmail.com%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 <no...@apache.org> 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 <em...@googlemail.com> 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 <mn...@apache.org> 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 <em...@googlemail.com> 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 <jg...@gmail.com> 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 <emijiang6@googlemail.com
>>> >
>>> >> 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 <no...@apache.org>
>>> >> wrote:
>>> >> >
>>> >> >> Hi, not sure what this has to do with isolation.
>>> >> >>
>>> >> >> Alasdair
>>> >> >>
>>> >> >> On 15 Nov 2010, at 16:13, Jarek Gawor <jg...@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 <EM...@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
>>> >> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Thanks
>>> >> > Emily
>>> >> > =================
>>> >> > Emily Jiang
>>> >> > ejiang@apache.org
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Thanks
>>> > Emily
>>> > =================
>>> > Emily Jiang
>>> > ejiang@apache.org
>>> >
>>>
>>
>>
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang@apache.org
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
Re: [Discussion] resolving against local platform repository
Posted by Alasdair Nottingham <no...@apache.org>.
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 <em...@googlemail.com> 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 <mn...@apache.org> 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 <em...@googlemail.com> 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 <jg...@gmail.com> 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 <emijiang6@googlemail.com
>> >
>> >> 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 <no...@apache.org>
>> >> wrote:
>> >> >
>> >> >> Hi, not sure what this has to do with isolation.
>> >> >>
>> >> >> Alasdair
>> >> >>
>> >> >> On 15 Nov 2010, at 16:13, Jarek Gawor <jg...@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 <EM...@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
>> >> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Thanks
>> >> > Emily
>> >> > =================
>> >> > Emily Jiang
>> >> > ejiang@apache.org
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Thanks
>> > Emily
>> > =================
>> > Emily Jiang
>> > ejiang@apache.org
>> >
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: [Discussion] resolving against local platform repository
Posted by Emily Jiang <em...@googlemail.com>.
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 <mn...@apache.org> 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 <em...@googlemail.com> 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 <jg...@gmail.com> 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 <emijiang6@googlemail.com
> >
> >> 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 <no...@apache.org>
> >> wrote:
> >> >
> >> >> Hi, not sure what this has to do with isolation.
> >> >>
> >> >> Alasdair
> >> >>
> >> >> On 15 Nov 2010, at 16:13, Jarek Gawor <jg...@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 <EM...@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
> >> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Thanks
> >> > Emily
> >> > =================
> >> > Emily Jiang
> >> > ejiang@apache.org
> >> >
> >>
> >
> >
> >
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang@apache.org
> >
>
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: [Discussion] resolving against local platform repository
Posted by Mark Nuttall <mn...@apache.org>.
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 <em...@googlemail.com> 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 <jg...@gmail.com> 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 <em...@googlemail.com>
>> 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 <no...@apache.org>
>> wrote:
>> >
>> >> Hi, not sure what this has to do with isolation.
>> >>
>> >> Alasdair
>> >>
>> >> On 15 Nov 2010, at 16:13, Jarek Gawor <jg...@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 <EM...@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
>> >> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Thanks
>> > Emily
>> > =================
>> > Emily Jiang
>> > ejiang@apache.org
>> >
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>
Re: [Discussion] resolving against local platform repository
Posted by Emily Jiang <em...@googlemail.com>.
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 <jg...@gmail.com> 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 <em...@googlemail.com>
> 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 <no...@apache.org>
> wrote:
> >
> >> Hi, not sure what this has to do with isolation.
> >>
> >> Alasdair
> >>
> >> On 15 Nov 2010, at 16:13, Jarek Gawor <jg...@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 <EM...@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
> >> >>
> >>
> >
> >
> >
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang@apache.org
> >
>
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: [Discussion] resolving against local platform repository
Posted by Jarek Gawor <jg...@gmail.com>.
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 <em...@googlemail.com> 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 <no...@apache.org> wrote:
>
>> Hi, not sure what this has to do with isolation.
>>
>> Alasdair
>>
>> On 15 Nov 2010, at 16:13, Jarek Gawor <jg...@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 <em...@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 <EM...@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
>> >>
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>
Re: [Discussion] resolving against local platform repository
Posted by Emily Jiang <em...@googlemail.com>.
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 <no...@apache.org> wrote:
> Hi, not sure what this has to do with isolation.
>
> Alasdair
>
> On 15 Nov 2010, at 16:13, Jarek Gawor <jg...@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 <em...@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 <EM...@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
> >>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: [Discussion] resolving against local platform repository
Posted by Alasdair Nottingham <no...@apache.org>.
Hi, not sure what this has to do with isolation.
Alasdair
On 15 Nov 2010, at 16:13, Jarek Gawor <jg...@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 <em...@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 <EM...@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
>>
Re: [Discussion] resolving against local platform repository
Posted by Jarek Gawor <jg...@gmail.com>.
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 <em...@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 <EM...@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
>
Fwd: [Discussion] resolving against local platform repository
Posted by Emily Jiang <em...@googlemail.com>.
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 <EM...@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