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. > 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
