Well there was ARIES-425, I had to put in a fix to understand the availability directive.
It's possible that we also incorrectly interpret that directive as an attribute for matching - I don't know that the code was ever written to cope with a more extended syntax than the basic Import-Package. All I've done at the moment is the bare minimum to get things working, which is to read the availability directive to find out if something is optional. Might anything else ever be used e.g. resolution:="optional" or optional:="true"? I would much rather have a separate class implemented where we can clearly state our assumptions about the syntax. It might also be nice to have a source:= directive to indicate where the service came from (e.g. blueprint, DS, etc). That would allow people to filter out services that they find out about from elsewhere. Tim ---------------------------------------- > Date: Thu, 23 Sep 2010 17:29:32 +0200 > Subject: Re: Auto-generation of Import-Service and Export-Service > From: [email protected] > To: [email protected] > > Which other projects are you talking about? > In the last discussion, I had asked if there was actually any *real* > problem with redefining those headers other than making an argument > about the fact that those are not compliant with OSGi R3 and received > no answers. Still the case here. I'm not aware of anything broken so > far. > > On Thu, Sep 23, 2010 at 17:22, Timothy Ward wrote: >> >> 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 >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
