[EMAIL PROTECTED] wrote on 11/13/2006 12:51:48 PM: > BJ, > > I chuckled at your reply. The technical details are pretty much what > I thought. However, given the real subtleties of, say, bundle class > loading, I was surprised at the reluctance to enumerate headers with > framework semantics. > > I have no such fears because I have a healthy experience of being > wrong. So here is my list: > > 3.2.1.1 Bundle-Activator: framework semantics > 3.2.1.2 Bundle-Category: localized > 3.2.1.3 Bundle-Classpath: framework semantics > 3.2.1.4 Bundle-ContactAddress: localized > 3.2.1.5 Bundle-Copyright: localized > 3.2.1.6 Bundle-Description: localized > 3.2.1.7 Bundle-DocURL: localized > 3.2.1.8 Bundle-Localization: framework semantics > 3.2.1.9 Bundle-ManifestVersion: framework semantics > 3.2.1.10 Bundle-Name: localized
This could be localized since the framework is not specified to use it at runtime. But I would not. Some framework impls will try to use this header as a substitute for Bundle-SymbolicName when old (pre-R4) bundles are installed. > 3.2.1.11 Bundle-NativeCode: framework semantics > 3.2.1.12 Bundle-RequiredExecutionEnvironment: framework semantics > 3.2.1.13 Bundle-SymbolicName: framework semantics > 3.2.1.14 Bundle-UpdateLocation: localized This has framework semantics since the framework should consult the value of the header during Bundle.update(). > 3.2.1.15 Bundle-Vendor: localized > 3.2.1.16 Bundle-Version: framework semantics > 3.2.1.17 DynamicImport-Package: framework semantics > 3.2.1.18 Export-Package: framework semantics > 3.2.1.19 Export-Service: framework semantics This header is deprecated and has no runtime semantics. > 3.2.1.20 Fragment-Host: framework semantics > 3.2.1.21 Import-Package: framework semantics > 3.2.1.22 Import-Service: framework semantics This header is deprecated and has no runtime semantics. > 3.2.1.23 Require-Bundle: framework semantics > > I assume in addition that those headers marked as having framework > semantics should be parsed as headers with clauses, and clauses with > values, directives, and attributes (some with additional constraints > as per the spec), while localized headers can be treated as mere > (localized) text strings, although in some cases it may be convenient > to present them in a more useful form (e.g. the bundle categories as > a list of strings). > > Feel free to comment or not ;-) > > Ciao! > > /djk > > > Date: Mon, 13 Nov 2006 11:56:51 -0500 > > From: BJ Hargrave <[EMAIL PROTECTED]> > > Subject: Re: [osgi-dev] manifest localization > > To: OSGi Developer Mail List <osgi-dev@bundles.osgi.org> > > Message-ID: > > <OF7CB72974.AA8DA227- > > [EMAIL PROTECTED]> > > Content-Type: text/plain; charset="US-ASCII" > > > > The list will change over time (as we make new spec releases) and, > > invariably, the spec team will screw up and and the list will be > > incorrect. :-) So we chose to not put such a list in the spec. > > > > For each header defined by the spec, if the framework will use the > > header > > value in some way (e.g. Import-Package) then that header has framework > > semantics and the framework must not use any localization of the > > header. > > Others, like Bundle-Description, are never used by the framework. > > So, if > > you are implementing the framework, any header whose value you > > would need > > to use should be the original, unlocalized value. > > > > BJ Hargrave > > Senior Technical Staff Member, IBM > > OSGi Fellow and CTO of the OSGi Alliance > > [EMAIL PROTECTED] > > > > office: +1 407 849 9117 > > mobile: +1 386 848 3788 > > > > > > > > > > David Kemper <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 11/13/2006 11:44 AM > > Please respond to > > OSGi Developer Mail List <osgi-dev@bundles.osgi.org> > > > > > > To > > osgi-dev@bundles.osgi.org > > cc > > > > Subject > > [osgi-dev] manifest localization > > > > > > > > > > > > > > Section 3.10.2 (Manifest Localization) of the R4 specification states > > that > > > > "All headers in a bundle's manifest can be localized. However, the > > Framework must always use the non-localized versions of headers that > > have Framework semantics." > > > > I can make a guess as to which of the 23 manifest headers (see > > 3.2.1.1 through 3.2.1.23) have "Framework semantics" but would > > appreciate the list from a more official source. > > > > Also, I suggest that the list be made more explicit in the next > > revision of the specification. > > > > If the list is made clear in the specification, maybe someone could > > point it out and accept my apologies? > > > > Thanks in advance. > > > > /djk > _______________________________________________ > OSGi Developer Mail List > osgi-dev@bundles.osgi.org > http://bundles.osgi.org/mailman/listinfo/osgi-dev BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 407 849 9117 mobile: +1 386 848 3788 _______________________________________________ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
