----------------------------------------
> Date: Thu, 25 Mar 2010 20:58:25 +0100
> Subject: Re: maven-bundle-plugin generating Import-Service entries
> From: [email protected]
> To: [email protected]
>
> On Thu, Mar 25, 2010 at 19:34, Timothy Ward wrote:
>
>>
>> I agree that this looks like a defect in the maven bundle plugin. The
>> services aren't used by the bundle, so they should not be expressed as
>> Import-Service entries for the bundle.
>>
>> I am also very concerned that the Import-Service entries generated are
>> Aries specific. I have plans to add Spring DM/Gemini Blueprint support for
>> the Aries JPA container namespace (which I have now formalized in JIRA
>> Aries-268). Adding this Import-Service header may prevent this support from
>> being added, or at the very least lead to unnecessary bundles (and their
>> dependencies) being provisioned. Essentially, someone who already has a
>> Gemini blueprint implementation installed may end up with Aries blueprint as
>> well, even though it is not necessary.
>>
>
> Not sure how that could work well in the future. Right now, blueprint
> custom namespaces are not standardized, which means any use of a custom
> namespace is specific to a given implementation. Until those are
> standardized, you need to choose which extender you want when using some
> extensions. If you don't, you may very well end up being extended by the
> wrong blueprint implementation.
I don't agree that a namespace is specific to an implementation of blueprint.
There is no reason the JPA namespace cannot be supported on any blueprint
implementation that supports pluggable xml namespaces as it has a simple
mapping to standard blueprint metadata. There will need to be an integration
bundle for each implementation of blueprint that is supported, but that does
not tie the namespace to any single blueprint implementation.
> I agree this is an even bigger problem which has no simple solution right
> now, but to import a package which is specific to a given implementation.
I don't agree here, if the namespace you want to use is supported on more than
one blueprint implementation then you should simply install the bundle that
adds that support for the blueprint implementation that you have. At that point
it doesn't matter which blueprint implementation extends you, and your
application can remain portable.
> When those are standardized, it should be easy to switch to the standardized
> namespace handlers interface name and property.
If I understand Alasdair correctly, even after the namespace handlers are
specified there are still potential problems. It is possible that the blueprint
extender and blueprint bundle exist a different scopes within the framework. At
this point the namespace handler only needs to be visible to the blueprint
extender, not the blueprint bundle, and the Import-Service header is
advertising a "false" dependency. I use the word "false" to indicate that the
dependency is not required at the scope of the blueprint bundle, I am not
trying to imply that there is no dependency at all.
> Anyway, if you want to remove those additional headers, simply remove the
> and properties from the maven bundle
> configuration in the default-parent pom.
>
>
>> One final concern is that the Import-Service headers being generated are
>> non-standard (the OSGi spec says that the values have no attributes). Isn't
>> there a risk that this might break existing tools?
>>
>
> The OSGI spec does not specify the syntax of those headers.
> If you look at the spec in section 6.1.13, it says: "Manifest header
> identifying the fully qualified class names of the services that the bundle
> requires (used for informational purposes only)." But that does not mean
> this header is a comma separated list of class names, because the definition
> of the Import-Package header is "Manifest header identifying the packages on
> which the bundle depends." and you can't really assert that the import
> package header is a simple comma separated list of namespaces.
>
> Before changing that, I'd like to know if there are any tools that would
> actually be broken and even so, the question could be raise if those tools
> should be fixed. I don't think creating new headers for storing the same
> information would be a good idea.
>
> Anyway, if everyone disagree with the use of the Import/Export-Service
> headers, the easiest way would be to remove those globally by adding them to
> the default aries.osgi.remove.headers property in the parent.
>
>
>>
>> I am +1 for raising a bug.
>>
>> Regards,
>>
>> Tim
>>
>>
>>
>> ----------------------------------------
>>> Date: Thu, 25 Mar 2010 13:58:15 -0400
>>> From: [email protected]
>>> To: [email protected]
>>> Subject: maven-bundle-plugin generating Import-Service entries
>>>
>>> I've noticed that recently the maven-bundle-plugin has started to
>>> generate the following Import-Service entries for namespace extensions
>>> for JPA and declarative transactions. For example, in AriesTrader there
>>> is a jpa persistence bundle that uses both of these features and
>>> therefore necessarily includes the following in the blueprint.xml:
>>>
>>>
>>> xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0";>
>>> ...
>>>
>>>
>>> class="org.apache.aries.samples.ariestrader.persist.jpa.cm.TradeJpaCm"
>>> init-method="init">
>>>
>>>
>>>
>>>
>>>
>>> This now results in the following import-service entries being generated
>>> in the MANIFEST.MF:
>>>
>>> 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)"
>>>
>>> These just started appearing recently - perhaps due to some recent
>>> change in the maven-bundle-plugin?
>>>
>>> IIUC these services are really only used by the blueprint
>>> implementation. They are not used directly by the application and so it
>>> seems to be inappropriate to include these in the MANIFEST for the
>>> application bundle. Is this a defect for the maven-bundle-plugin?
>>>
>>> Regards,
>>> Joe
>>
>> _________________________________________________________________
>> We want to hear all your funny, exciting and crazy Hotmail stories. Tell us
>> now
>> http://clk.atdmt.com/UKM/go/195013117/direct/01/
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
_________________________________________________________________
Send us your Hotmail stories and be featured in our newsletter
http://clk.atdmt.com/UKM/go/195013117/direct/01/
