[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] tooling... IU requirements
- From: Pascal Rapicault <pascal@xxxxxxxxxxxxx>
- Date: Sat, 11 Aug 2012 12:02:59 +0200
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=rapicault.net; h=content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; q=dns; s= rapicault.net; b=XMvCROeduogxiaw1JXxCyeiDu7+PRnXmlOWAGJ1kT7BDfaD UHeVdRe+T4XG++c6dMFIlREbxaOrgfvgcoGFLmov+vKJEMwkHbXwx7/+Vb80HgyT 8ZAUgQQHZm156/f63xB3UOTAPvqA7Su6hCIpJpxNpwMmvrOh46WgVCM3JfGs=
This is correct any configuration that is baked in the IU can not be changed (e.g. if I have a start level in the IU delivering a bundle, it is immutable). The rationale behind this is that IUs are expected to deliver the most generic information as possible.
On 2012-08-09, at 5:54 PM, Kopecz, Klaus wrote:
> I guess another rule is that an existing IU configuration cannot be changed by a CU? Is this true in general? For example, I can configure a bundle to have a start level 2 using a p2.inf file. Obviously, this is not overwritten by a generically binding fragment like tooling.osgi.bundle.default.
> -----Original Message-----
> From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
> Sent: Donnerstag, 9. August 2012 15:13
> To: P2 developer discussions
> Subject: Re: [p2-dev] tooling... IU requirements
> That falls in the terrible hack category :)
> Because we have these catch all CUs, we need to be able to ignore those when a more specific CU is available.
> The original hack that got put in place is one where the CU that had the most "hostRequirements" match would win and this is why you need to have the two requirements here.
> There is a bug discussing a better solution but I can't seem to find it.
> On 2012-08-09, at 2:40 PM, Igor Fedorenko wrote:
>> What about toolinggtk.linux.x86org.eclipse.equinox.ds IU? Does it make
>> sense for it to require any bundle? I realize this requirement will be
>> satisfied by the host bundle not other bundles will be brought into
>> solution, but is this just minor publisher sloppiness or there is more
>> to it?
>> On 12-08-09 8:31 AM, Pascal Rapicault wrote:
>>> Yes this is correct. The goal of such IUs is to apply a common configuration to all the bundles.
>>> For example in Eclipse every bundles but a few need to be started at start level 4. Since nothing happens for free in p2, there needs to be a configuration unit (an IUFragment) to delivers this information to every bundle. To avoid the creation of a plethora of CU (one per IU that delivers a bundle) it is much more maintainable to have one CU that attaches to multiple IUs. An example of such IU is tooling.osgi.bundle.default.
>>> On 2012-08-09, at 1:54 PM, Igor Fedorenko wrote:
>>>> I've noticed that many/all toolingBLAH IUs have a requirement that appear to be satisfied by any bundle
>>>> Did I get this right? What is the reason behind these?
>>>> p2-dev mailing list
>>> p2-dev mailing list
>> p2-dev mailing list
> p2-dev mailing list
> p2-dev mailing list