Alasdair
On 25 Mar 2010, at 19:58, Guillaume Nodet <[email protected]> wrote:
On Thu, Mar 25, 2010 at 19:34, Timothy Ward
<[email protected]>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 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 see how this follows. As a blueprint bundle you don't need to
care how the namespace is added in, just that it is. If you have a
dependency it is on the namespace, not a service that can parse it.
When those are standardized, it should be easy to switch to the
standardized
namespace handlers interface name and property.
Anyway, if you want to remove those additional headers, simply
remove the
<nsh_interface> and <nsh_namespace> properties from the maven bundle
configuration in the default-parent pom.
Is this opt in or out? I think it should be opt in.
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.
We discussed this before. When those headers were specified formally
it was explicitly defined as a comma separated list of class names.
Sure you can point at non-normative parts of a spec to justify a
position, that is why you have normative sections which did define the
Import-Service header, just as the spec today defines in a normative
way the syntax of Import-Package.
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
