Well, feel free to submit a patch to change the headers in both the bundle plugin and the bundle repository. As long as the information is in the manifest and in the obr xml, I don't really care about the names themselves. But that in this case, we'd have to also change the aries application code to take those headers into account, as this is the only way to support bundles not using Blueprint.
Also, looking at the current Aries code, it seems it handles nicely the extended Import-Service syntax nicely with both the optional and filter attributes (see the second constructor of ImportedServiceImpl), though if it is (wrongly ?) marked as deprecated. I really don't care about the name of those headers, but I really care about the fact that they are used. On Thu, Sep 23, 2010 at 16:47, Alasdair Nottingham <[email protected]> wrote: > That is not the position the alliance takes on deprecated stuff. When they > deprecated stuff they don't "cease" to specify it, they just stop putting it > in specs. It is still specified as it was in the OSGi R3 spec. > > As I said back then if you want to do this you should be using non-standard > headers, or get the Alliance to change the spec. > > Alasdair Nottingham > > On 23 Sep 2010, at 06:59, Guillaume Nodet <[email protected]> wrote: > >> Right, and they are deprecated, so their syntax isn't defined anymore >> in the specs ;-) >> So that's completely untrue to say those headers are non-compliant, >> unless you plan to >> deploy on an OSGi 3 platform, which Aries does not support. >> >> Given those headers are not used by the OSGi framework, I fail to see >> what kind of >> problems it could lead to. >> >> Also, the generation you are referring to (about the namespace >> handlers additional service >> imports) have been removed in all maven modules afaik. >> >> I'd be happy to actually fix anything in the generation as I said. If >> the generated information >> can't be mapped back to the blueprint services, there is actaully a >> problem somewhere, >> else the information generated by the application deployer and the >> maven bundle plugin >> should be the same. >> >> Please remember, Aries components might be consumed by means other than Aries >> applications. Also, Aries applications can contains bundles based on >> tools other than >> Blueprint and the use of those headers is currently the only to have >> this metadata available >> for everyone. >> >> >> On Thu, Sep 23, 2010 at 15:49, Mark Nuttall <[email protected]> wrote: >>> These deprecated headers were defined in the version 3 spec, section 4.14 >>> >>> >>> 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 >>> Frame- >>> work. 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 ::= <fully qualified 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 ::= <fully qualified class name> >>> >>> >>> As we discussed back on March 25 ("maven-bundle-plugin generating >>> Import-Service entries"), the maven bundle plugin is adding a lot of >>> non-compliant information, e.g. >>> >>> Import-Service: org.apache.aries.blueprint.NamespaceHandler;filter="(o >>> >>> sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/transac >>> >>> tions/v1.0.0)",org.apache.aries.blueprint.NamespaceHandler;filter="(o >>> >>> sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/jpa/v1. >>> 0.0)" >>> >>> Regards, >>> Mark >>> >>> On 23 September 2010 14:41, Guillaume Nodet <[email protected]> wrote: >>> >>>> 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 <[email protected]> >>>> 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
