You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Joe Bohn <jo...@gmail.com> on 2010/03/25 18:58:15 UTC
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:
<blueprint xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0">
...
<bean id="tradeServicesBeanJPA-CM"
class="org.apache.aries.samples.ariestrader.persist.jpa.cm.TradeJpaCm"
init-method="init">
<jpa:context property="entityManager" unitname="ariestrader-cm" />
<tx:transaction method="*" value="Required"/>
</bean>
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
Re: maven-bundle-plugin generating Import-Service entries
Posted by Alasdair Nottingham <no...@apache.org>.
As Tim says you only need that service if you use the Apache Aries
blueprint. If you use the bluprint RI you need something different.
Another blueprint impl might not use services for adding in new
namespaces to the XML. I do not think the maven bundle plugin should
generate metadata that ties you to an implementation of blueprint.
Also given the metadata is there if it were used to provision
dependancies you would end up provisioning things you either don't
need, or don't want. Having two blueprint runtimes is one such don't
want.
I do understand you are trying to solve a real problem here, but I
think doing it this way is wrong and therefore a bug.
On the subject of importing org.osgi.service.blueprint I think that is
reasonable as the spec says you should import that package and I do
not see the two as being related.
Alasdair
On 25 Mar 2010, at 19:20, Guillaume Nodet <gn...@gmail.com> wrote:
> Why would you see that as a defect ?
> Will your bundle work if you don't have the namespace handler
> present ? I
> doubt it will ;-)
> So your bundle actually requires those services to be present, even
> if you
> as a user don't really know it.
> Actually, you'll also notice that the bundle also import the
> org.osgi.service.blueprint package, even if your bundle does not
> actually
> require it.
> Would there be a way to express the fact that the bundle needs to be
> extended by blueprint, this should also be in the manifest.
>
> On Thu, Mar 25, 2010 at 18:58, Joe Bohn <jo...@gmail.com> wrote:
>
>> 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:
>>
>> <blueprint xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
>> xmlns:tx="http://aries.apache.org/xmlns/transactions/
>> v1.0.0">
>> ...
>>
>> <bean id="tradeServicesBeanJPA-CM"
>> class=
>> "org.apache.aries.samples.ariestrader.persist.jpa.cm.TradeJpaCm"
>> init-method="init">
>> <jpa:context property="entityManager" unitname="ariestrader-cm" />
>> <tx:transaction method="*" value="Required"/>
>> </bean>
>>
>>
>> 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
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: maven-bundle-plugin generating Import-Service entries
Posted by Guillaume Nodet <gn...@gmail.com>.
Why would you see that as a defect ?
Will your bundle work if you don't have the namespace handler present ? I
doubt it will ;-)
So your bundle actually requires those services to be present, even if you
as a user don't really know it.
Actually, you'll also notice that the bundle also import the
org.osgi.service.blueprint package, even if your bundle does not actually
require it.
Would there be a way to express the fact that the bundle needs to be
extended by blueprint, this should also be in the manifest.
On Thu, Mar 25, 2010 at 18:58, Joe Bohn <jo...@gmail.com> wrote:
> 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:
>
> <blueprint xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
> xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0">
> ...
>
> <bean id="tradeServicesBeanJPA-CM"
> class="org.apache.aries.samples.ariestrader.persist.jpa.cm.TradeJpaCm"
> init-method="init">
> <jpa:context property="entityManager" unitname="ariestrader-cm" />
> <tx:transaction method="*" value="Required"/>
> </bean>
>
>
> 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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
RE: maven-bundle-plugin generating Import-Service entries
Posted by Timothy Ward <ti...@apache.org>.
----------------------------------------
> Date: Thu, 25 Mar 2010 20:58:25 +0100
> Subject: Re: maven-bundle-plugin generating Import-Service entries
> From: gnodet@gmail.com
> To: aries-dev@incubator.apache.org
>
> 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: joebohn@gmail.com
>>> To: aries-dev@incubator.apache.org
>>> 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/
Re: maven-bundle-plugin generating Import-Service entries
Posted by Stuart McCulloch <mc...@gmail.com>.
On 26 March 2010 08:32, Joe Bohn <jo...@gmail.com> 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 <timothyjward@hotmail.com
>>> >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: joebohn@gmail.com
>>>>> To: aries-dev@incubator.apache.org
>>>>> 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
Re: maven-bundle-plugin generating Import-Service entries
Posted by Joe Bohn <jo...@gmail.com>.
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
>> <ti...@hotmail.com>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: joebohn@gmail.com
>>>> To: aries-dev@incubator.apache.org
>>>> 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
Re: maven-bundle-plugin generating Import-Service entries
Posted by Joe Bohn <jo...@gmail.com>.
Guillaume Nodet wrote:
> On Thu, Mar 25, 2010 at 19:34, Timothy Ward <ti...@hotmail.com>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: joebohn@gmail.com
>>> To: aries-dev@incubator.apache.org
>>> 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
Re: maven-bundle-plugin generating Import-Service entries
Posted by Alasdair Nottingham <no...@apache.org>.
Alasdair
On 25 Mar 2010, at 19:58, Guillaume Nodet <gn...@gmail.com> wrote:
> On Thu, Mar 25, 2010 at 19:34, Timothy Ward
> <ti...@hotmail.com>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: joebohn@gmail.com
>>> To: aries-dev@incubator.apache.org
>>> 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
Re: maven-bundle-plugin generating Import-Service entries
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Mar 25, 2010 at 19:34, Timothy Ward <ti...@hotmail.com>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: joebohn@gmail.com
> > To: aries-dev@incubator.apache.org
> > 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
Re: maven-bundle-plugin generating Import-Service entries
Posted by Alasdair Nottingham <no...@apache.org>.
I have to agree. In my usage of aries the blueprint runtime can see
namespace handlers that are hidden from the blueprint bundle.
Joe I'm happy to raise a JIRA against the plugin if you don't want to,
but we need this fixed.
Alasdair
On 25 Mar 2010, at 18:34, Timothy Ward <ti...@hotmail.com> 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.
>
> 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?
>
> I am +1 for raising a bug.
>
> Regards,
>
> Tim
>
>
>
> ----------------------------------------
>> Date: Thu, 25 Mar 2010 13:58:15 -0400
>> From: joebohn@gmail.com
>> To: aries-dev@incubator.apache.org
>> 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/
RE: maven-bundle-plugin generating Import-Service entries
Posted by Timothy Ward <ti...@hotmail.com>.
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.
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?
I am +1 for raising a bug.
Regards,
Tim
----------------------------------------
> Date: Thu, 25 Mar 2010 13:58:15 -0400
> From: joebohn@gmail.com
> To: aries-dev@incubator.apache.org
> 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/