On Thu, Sep 23, 2010 at 17:52, Timothy Ward <[email protected]> wrote: > > 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"?
That that I know of. > > 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. Those are good ideas, I like those constructive comments a lot. The code that generates the headers for blueprint are specified lives at http://svn.apache.org/repos/asf/felix/trunk/bundleplugin/src/main/resources/org/apache/felix/bundleplugin/blueprint.xsl The source attribute should be easy to add in the xsl, so a simple patch would do the trick for that one. > > 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
