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 Wed, 17 Nov 2010 12:19:47 GMT
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 <emijiang6@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 <mnuttall@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 <emijiang6@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 <jgawor@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 <not@apache.org>
>> >> wrote:
>> >> >
>> >> >> 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
>> >> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > 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

Mime
View raw message