In rev 927907 I just removed the maven-bundle-plugin configuration that
was adding the org.apache.aries.blueprint.NamespaceHandler
Import-Service entries. This addresses my primary concern by removing
namespace Import-Service entries from the application bundle that
doesn't directly make use of them.
Of course this doesn't settle the bigger debate on the use of
Import/Export-Service in the MANIFEST related to the OBR repository.xml,
the appropriate syntax for those entries, or the maven-bundle-plugin
(and other tools) role in supporting this solution. Perhaps those
issues should be raised in Apache Felix as the project that manages the
maven-bundle-plugin? If anybody would like to pursue that they are
welcome to do so, but for the time being my primary issue is resolved.
Joe
Joe Bohn wrote:
Guillaume Nodet 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.
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.
I'll go ahead and make this change now while the discussion continues on
the plugin and valid results/uses for Import-Service when configured
with the properties. That will at least remove the entries from our
bundles. Any objections?
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/
--
Joe
