Guillaume, I do see why one might want this information in bundle headers, but I'm afraid I don't understand why it needs to re-use the Import-Service and Export-Service headers.
If it were to use a different header (one not defined by OSGi) it would not cause problems to other projects that are unaware of the custom extensions. Right now the implementation of the bundle plugin requires everyone that ever used the existing Import-Service and Export-Service headers to understand the non-standard behaviour. I'm not wild about this metadata being generated for all bundles by default, but I wouldn't mind anywhere near as much if it weren't redefining an existing header and, as a result, breaking other projects. Regards, Tim ---------------------------------------- > Date: Thu, 23 Sep 2010 16:54:52 +0200 > Subject: Re: Auto-generation of Import-Service and Export-Service > From: [email protected] > To: [email protected] > > On Thu, Sep 23, 2010 at 16:05, Timothy Ward wrote: >> >> The headers are incorrect because they violate the syntax for Import-Service >> and Export-Service. From the OSGi 3 specification: >> >> ----------------------------------------------------------------------------------------- >> >> 4.14 Importing and Exporting Services >> >> The Export-Service manifest header declares the interfaces that a bundle >> may register. It provides advisory information that is not used by the >> Framework. >> This header is intended for use by server-side management tools. >> >> The Export-Service manifest header must conform to the following syntax: >> >> Export-Service ::= class-name ( ’,’ class-name )* >> class-name ::= >> >> The Import-Service manifest header declares the interfaces the bundle may >> use. It provides advisory information that is not used by the Framework. >> This header is also intended for use by server-side management tools. >> >> The Import-Service manifest header must conform to the following syntax: >> >> Import-Service ::= class-name ( ’,’ class-name )* >> class-name ::= >> >> ------------------------------------------------------------------------------------------ >> >> According to the specification it is not valid to supply any attributes or >> directives, this means that anyone using this header may fail to process any >> bundle which does. It also means that there's no standard way for anyone to >> indicate service properties, filters or optionality. The fact that the >> bundle plugin is doing this is actually causing bugs which we are having to >> work around. > > But since when is Aries supporting OSGi R3 ? We have requirements on > OSGi R 4.2 afaik. > > This syntax specification comes from R3 and the R4 specs does not > specify the syntax for those headers. I doubled checked a while back > with osgi experts about that. > Also if you have any tooling which supports OSGi R3 bundles, I must > suppose it's a bit buggy because it's easy to check if a bundle is a > R3 or R4 bundles by verifying if the Bundle-ManifestVersion is 2 or > not. Those headers should be ignored for all R4 bundles. > >> If the bundle plugin needs to implement some custom function to support some >> special use-cases in Felix then it should be using a custom manifest header, >> and preferrably it should only add that header when configured to do so. >> Right now anyone who uses the bundle plugin is, without their knowledge, >> generating bundles that use an OSGi reserved header with syntax that >> violates the core spec. > > Headers generated can always be removed in the bundle plugin by using > the -removeheaders command for bnd. > But I'd rather find another solution as I think this information is of > real importance, especially in the generated OBR xml file. > > > >> Regards, >> >> Tim >> >> ---------------------------------------- >>> Date: Thu, 23 Sep 2010 15:41:11 +0200 >>> Subject: Re: Auto-generation of Import-Service and Export-Service >>> From: [email protected] >>> To: [email protected] >>> >>> The maven bundle plugin actaully check if the service is mandatory or >>> not and should add that into the Import-Service manifest header. >>> What exactly is not right with those headers ? >>> >>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward wrote: >>>> >>>> Hi, >>>> >>>> There are some problems with the way in which Aries models bundles for >>>> resolution in OBR. Currently we look at the blueprint for imported and >>>> exported services, but also fall back to the Import-Service and >>>> Export-Service headers in case there are any legacy bundles. >>>> >>>> Unfortunately it seems as though all of our bundles have Import-Service >>>> and Export-Service headers generated (using non-standard directives and >>>> attributes to boot). This means that we duplicate service imports and >>>> exports in our OBR model, which is a major performance concern, but worse, >>>> the headers are interpreted differently. >>>> >>>> ARIES-425 was caused by the fact that the duplicate Import-Service header >>>> caused an optional blueprint service to also be found as a mandatory >>>> Import-Service. Where are these non-standard, deprecated headers coming >>>> from and how can we turn them off? >>>> >>>> Regards, >>>> >>>> Tim >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
