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. > Regards, > Klaus > > -----Original Message----- > From: [email protected] [mailto:[email protected]] 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? >> >> -- >> Regards, >> Igor >> >> 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. >>> >>> HTH >>> >>> Pascal >>> >>> 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 >>>> >>>> >>>> <required >>>> namespace='org.eclipse.equinox.p2.eclipse.type' >>>> name='bundle' >>>> range='[1.0.0,2.0.0)' >>>> greedy='false'/> >>>> >>>> >>>> Did I get this right? What is the reason behind these? >>>> >>>> -- >>>> Regards, >>>> Igor >>>> _______________________________________________ >>>> p2-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/p2-dev >>> >>> _______________________________________________ >>> p2-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/p2-dev >>> >> _______________________________________________ >> p2-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/p2-dev > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev _______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
