On 26 March 2010 08:32, Joe Bohn <[email protected]> wrote: > 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?
well the change to add those Import/Export-Service entries was committed by Guillaume, so I think this discussion could be held on the Aries list - especially as it's specific to the blueprint analysis code and doesn't affect other users of the bundleplugin 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 > -- Cheers, Stuart
