You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@aries.apache.org by dk...@apache.org on 2012/05/18 19:42:46 UTC

svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

Author: dkulp
Date: Fri May 18 17:42:46 2012
New Revision: 1340184

URL: http://svn.apache.org/viewvc?rev=1340184&view=rev
Log:
Import the osgi blueprint stuff so it can work with a wider range of containers

Modified:
    aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

Modified: aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
URL: http://svn.apache.org/viewvc/aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml?rev=1340184&r1=1340183&r2=1340184&view=diff
==============================================================================
--- aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml (original)
+++ aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml Fri May 18 17:42:46 2012
@@ -40,7 +40,6 @@
         </aries.osgi.activator>
         <aries.osgi.import>
             !org.apache.aries.blueprint*,
-            !org.osgi.service.blueprint*,
             org.eclipse.osgi.internal.loader;resolution:=optional,
             org.eclipse.osgi.framework.internal.core;resolution:=optional,
             org.eclipse.osgi.framework.adaptor;resolution:=optional,



Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, May 22, 2012 at 9:16 AM, Siano, Stephan <st...@sap.com> wrote:
> I actually do not understand your argument. The class space compatibility mentioned in 121.3.1 of the compendium spec is actually fulfilled better if the blueprint apis are imported and exported by the extender bundle. In this case the class loader of the extender and the class loader of the blueprint bundle actually reference to the same class, whereas if the packages are not imported but only exported by the extender bundle this class space compatibility will break as soon as the blueprint bundle is wired with any other bundle exporting the api is present.

Section 121.3.1 did not make any explicit references to multiple
extenders because there was an RFC going on at that time to address
this issue, but that was the main use case for writing such a section.
 The spec also says that blueprint bundles should import the blueprint
package (which does not make sense on its own unless the package is
actually needed), and that's for the same reason.

Your problem is due to the fact that you deploy compendium.  That's a
really bad thing to do anyway as it breaks the modularity of all osgi
services implementations.  You can always use the fine grained bundles
if you prefer and that will solve your problem.

> Sure: with your model you can have two different blueprint extender bundles active at the at the same time and the blueprint bundle is extended by whichever blueprint bundle it is wired to (if both implement the same blueprint version this is random usually depending on the start order of the bundles), but I actually do not really see a use case for that.

That's really the use case that we had in mind when the spec was
discussed and written.  For example, karaf rely on Aries Blueprint
(because of the namespace handlers), but some users want to be able to
deploy spring-dm (to leverage some spring specific features).  The
only way to handle such a use case is to really split the class space.

>
> Why would you need additional bundles to deploy? Importing a bundle you do also provide does not require you to have another bundle present that exports the packages, it just means that you don't have these class space compatibility issues if another bundle is present that is exporting the same API (e.g. and API bundle containing the compendium or enterprise APIs).

This is a *bug fix* release.  So you should be able to upgrade
blueprint-bundle should work.  Forcing an import is a no go.

>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Dienstag, 22. Mai 2012 08:42
> To: dev@aries.apache.org
> Subject: Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>
> The rule you mentioned is the general rule, and I agree with it in
> most of the cases for API packages.
> However, as I mentioned, for blueprint, things are a bit different.
> You can see that by checking 121.3.1 which specifically talks about
> class space compatibility, and there's a reason for that as I
> explained (I can go though it with more details if necessary).   The
> overall goal is to actually split the class space into separate
> portions.
>
> So first, that's would be incompatible with 0.3 because it would needs
> an additional bundle to deploy (that will the case in 1.0 anyway with
> the small bundles, so please can we try to at least keep one version
> clean ?).
> Second, it would lead to serious problems when trying to have multiple
> blueprint extenders in the same container, which is supposed to work
> to some degree.
> And last, the only benefit of sharing API is that you should be able
> to update the extender without having to refresh the blueprint
> bundles.  However, in real cases, that's rarely the case and the all
> the blueprint beans have to be recreated anyway, so the benefit is
> very low.
>
> On Tue, May 22, 2012 at 7:52 AM, Siano, Stephan <st...@sap.com> wrote:
>>
>> AFAIK the OSGi spec proposes to do the import and export in such cases (section 3.5.6 of the 4.3 core spec). Personally I find it much more probable that the compendium or enterprise bundles are present, than having two different blueprint implementations on the same stack. I also do not see any issues with the different blueprint implementation importing the same org.osgi.blueprint APIs. They are specified in the spec and should always be the same wherever they come from.
>>
>> So I essentially do think that it's a good idea to import the osgi api.
>>
>> -----Original Message-----
>> From: Guillaume Nodet [mailto:gnodet@gmail.com]
>> Sent: Dienstag, 22. Mai 2012 00:44
>> To: dev@aries.apache.org
>> Subject: Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>>
>> I don't think that's a good idea to import the osgi api.
>>
>> It may lead to problems if multiple blueprint implementations are
>> deployed for some reason.
>> To support such a case, the blueprint bundles are supposed to import
>> the org.osgi.blueprint package iirc, so that the osgi framework wiring
>> will be correctly split and only the blueprint extender which has been
>> imported will actually extend the bundle.  By importing the api, two
>> extenders can then be compatible and both would extend the bundle.
>>
>> IF the main reason is that people have the compendium bundle deployed,
>> well, that's a bad idea because the same problem also tend to apply
>> with other osgi services such as ConfigAdmin and others which usually
>> ship their own version of the package.
>>
>>
>> On Fri, May 18, 2012 at 7:42 PM,  <dk...@apache.org> wrote:
>>> Author: dkulp
>>> Date: Fri May 18 17:42:46 2012
>>> New Revision: 1340184
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1340184&view=rev
>>> Log:
>>> Import the osgi blueprint stuff so it can work with a wider range of containers
>>>
>>> Modified:
>>>    aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>>>
>>> Modified: aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>>> URL: http://svn.apache.org/viewvc/aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml?rev=1340184&r1=1340183&r2=1340184&view=diff
>>> ==============================================================================
>>> --- aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml (original)
>>> +++ aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml Fri May 18 17:42:46 2012
>>> @@ -40,7 +40,6 @@
>>>         </aries.osgi.activator>
>>>         <aries.osgi.import>
>>>             !org.apache.aries.blueprint*,
>>> -            !org.osgi.service.blueprint*,
>>>             org.eclipse.osgi.internal.loader;resolution:=optional,
>>>             org.eclipse.osgi.framework.internal.core;resolution:=optional,
>>>             org.eclipse.osgi.framework.adaptor;resolution:=optional,
>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

RE: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

Posted by "Siano, Stephan" <st...@sap.com>.
I actually do not understand your argument. The class space compatibility mentioned in 121.3.1 of the compendium spec is actually fulfilled better if the blueprint apis are imported and exported by the extender bundle. In this case the class loader of the extender and the class loader of the blueprint bundle actually reference to the same class, whereas if the packages are not imported but only exported by the extender bundle this class space compatibility will break as soon as the blueprint bundle is wired with any other bundle exporting the api is present.

Sure: with your model you can have two different blueprint extender bundles active at the at the same time and the blueprint bundle is extended by whichever blueprint bundle it is wired to (if both implement the same blueprint version this is random usually depending on the start order of the bundles), but I actually do not really see a use case for that.

Why would you need additional bundles to deploy? Importing a bundle you do also provide does not require you to have another bundle present that exports the packages, it just means that you don't have these class space compatibility issues if another bundle is present that is exporting the same API (e.g. and API bundle containing the compendium or enterprise APIs).

-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com] 
Sent: Dienstag, 22. Mai 2012 08:42
To: dev@aries.apache.org
Subject: Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

The rule you mentioned is the general rule, and I agree with it in
most of the cases for API packages.
However, as I mentioned, for blueprint, things are a bit different.
You can see that by checking 121.3.1 which specifically talks about
class space compatibility, and there's a reason for that as I
explained (I can go though it with more details if necessary).   The
overall goal is to actually split the class space into separate
portions.

So first, that's would be incompatible with 0.3 because it would needs
an additional bundle to deploy (that will the case in 1.0 anyway with
the small bundles, so please can we try to at least keep one version
clean ?).
Second, it would lead to serious problems when trying to have multiple
blueprint extenders in the same container, which is supposed to work
to some degree.
And last, the only benefit of sharing API is that you should be able
to update the extender without having to refresh the blueprint
bundles.  However, in real cases, that's rarely the case and the all
the blueprint beans have to be recreated anyway, so the benefit is
very low.

On Tue, May 22, 2012 at 7:52 AM, Siano, Stephan <st...@sap.com> wrote:
>
> AFAIK the OSGi spec proposes to do the import and export in such cases (section 3.5.6 of the 4.3 core spec). Personally I find it much more probable that the compendium or enterprise bundles are present, than having two different blueprint implementations on the same stack. I also do not see any issues with the different blueprint implementation importing the same org.osgi.blueprint APIs. They are specified in the spec and should always be the same wherever they come from.
>
> So I essentially do think that it's a good idea to import the osgi api.
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Dienstag, 22. Mai 2012 00:44
> To: dev@aries.apache.org
> Subject: Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>
> I don't think that's a good idea to import the osgi api.
>
> It may lead to problems if multiple blueprint implementations are
> deployed for some reason.
> To support such a case, the blueprint bundles are supposed to import
> the org.osgi.blueprint package iirc, so that the osgi framework wiring
> will be correctly split and only the blueprint extender which has been
> imported will actually extend the bundle.  By importing the api, two
> extenders can then be compatible and both would extend the bundle.
>
> IF the main reason is that people have the compendium bundle deployed,
> well, that's a bad idea because the same problem also tend to apply
> with other osgi services such as ConfigAdmin and others which usually
> ship their own version of the package.
>
>
> On Fri, May 18, 2012 at 7:42 PM,  <dk...@apache.org> wrote:
>> Author: dkulp
>> Date: Fri May 18 17:42:46 2012
>> New Revision: 1340184
>>
>> URL: http://svn.apache.org/viewvc?rev=1340184&view=rev
>> Log:
>> Import the osgi blueprint stuff so it can work with a wider range of containers
>>
>> Modified:
>>    aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>>
>> Modified: aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>> URL: http://svn.apache.org/viewvc/aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml?rev=1340184&r1=1340183&r2=1340184&view=diff
>> ==============================================================================
>> --- aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml (original)
>> +++ aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml Fri May 18 17:42:46 2012
>> @@ -40,7 +40,6 @@
>>         </aries.osgi.activator>
>>         <aries.osgi.import>
>>             !org.apache.aries.blueprint*,
>> -            !org.osgi.service.blueprint*,
>>             org.eclipse.osgi.internal.loader;resolution:=optional,
>>             org.eclipse.osgi.framework.internal.core;resolution:=optional,
>>             org.eclipse.osgi.framework.adaptor;resolution:=optional,
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

Posted by Guillaume Nodet <gn...@gmail.com>.
The rule you mentioned is the general rule, and I agree with it in
most of the cases for API packages.
However, as I mentioned, for blueprint, things are a bit different.
You can see that by checking 121.3.1 which specifically talks about
class space compatibility, and there's a reason for that as I
explained (I can go though it with more details if necessary).   The
overall goal is to actually split the class space into separate
portions.

So first, that's would be incompatible with 0.3 because it would needs
an additional bundle to deploy (that will the case in 1.0 anyway with
the small bundles, so please can we try to at least keep one version
clean ?).
Second, it would lead to serious problems when trying to have multiple
blueprint extenders in the same container, which is supposed to work
to some degree.
And last, the only benefit of sharing API is that you should be able
to update the extender without having to refresh the blueprint
bundles.  However, in real cases, that's rarely the case and the all
the blueprint beans have to be recreated anyway, so the benefit is
very low.

On Tue, May 22, 2012 at 7:52 AM, Siano, Stephan <st...@sap.com> wrote:
>
> AFAIK the OSGi spec proposes to do the import and export in such cases (section 3.5.6 of the 4.3 core spec). Personally I find it much more probable that the compendium or enterprise bundles are present, than having two different blueprint implementations on the same stack. I also do not see any issues with the different blueprint implementation importing the same org.osgi.blueprint APIs. They are specified in the spec and should always be the same wherever they come from.
>
> So I essentially do think that it's a good idea to import the osgi api.
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Dienstag, 22. Mai 2012 00:44
> To: dev@aries.apache.org
> Subject: Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>
> I don't think that's a good idea to import the osgi api.
>
> It may lead to problems if multiple blueprint implementations are
> deployed for some reason.
> To support such a case, the blueprint bundles are supposed to import
> the org.osgi.blueprint package iirc, so that the osgi framework wiring
> will be correctly split and only the blueprint extender which has been
> imported will actually extend the bundle.  By importing the api, two
> extenders can then be compatible and both would extend the bundle.
>
> IF the main reason is that people have the compendium bundle deployed,
> well, that's a bad idea because the same problem also tend to apply
> with other osgi services such as ConfigAdmin and others which usually
> ship their own version of the package.
>
>
> On Fri, May 18, 2012 at 7:42 PM,  <dk...@apache.org> wrote:
>> Author: dkulp
>> Date: Fri May 18 17:42:46 2012
>> New Revision: 1340184
>>
>> URL: http://svn.apache.org/viewvc?rev=1340184&view=rev
>> Log:
>> Import the osgi blueprint stuff so it can work with a wider range of containers
>>
>> Modified:
>>    aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>>
>> Modified: aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>> URL: http://svn.apache.org/viewvc/aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml?rev=1340184&r1=1340183&r2=1340184&view=diff
>> ==============================================================================
>> --- aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml (original)
>> +++ aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml Fri May 18 17:42:46 2012
>> @@ -40,7 +40,6 @@
>>         </aries.osgi.activator>
>>         <aries.osgi.import>
>>             !org.apache.aries.blueprint*,
>> -            !org.osgi.service.blueprint*,
>>             org.eclipse.osgi.internal.loader;resolution:=optional,
>>             org.eclipse.osgi.framework.internal.core;resolution:=optional,
>>             org.eclipse.osgi.framework.adaptor;resolution:=optional,
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

RE: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

Posted by "Siano, Stephan" <st...@sap.com>.
AFAIK the OSGi spec proposes to do the import and export in such cases (section 3.5.6 of the 4.3 core spec). Personally I find it much more probable that the compendium or enterprise bundles are present, than having two different blueprint implementations on the same stack. I also do not see any issues with the different blueprint implementation importing the same org.osgi.blueprint APIs. They are specified in the spec and should always be the same wherever they come from.

So I essentially do think that it's a good idea to import the osgi api.

-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com] 
Sent: Dienstag, 22. Mai 2012 00:44
To: dev@aries.apache.org
Subject: Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

I don't think that's a good idea to import the osgi api.

It may lead to problems if multiple blueprint implementations are
deployed for some reason.
To support such a case, the blueprint bundles are supposed to import
the org.osgi.blueprint package iirc, so that the osgi framework wiring
will be correctly split and only the blueprint extender which has been
imported will actually extend the bundle.  By importing the api, two
extenders can then be compatible and both would extend the bundle.

IF the main reason is that people have the compendium bundle deployed,
well, that's a bad idea because the same problem also tend to apply
with other osgi services such as ConfigAdmin and others which usually
ship their own version of the package.


On Fri, May 18, 2012 at 7:42 PM,  <dk...@apache.org> wrote:
> Author: dkulp
> Date: Fri May 18 17:42:46 2012
> New Revision: 1340184
>
> URL: http://svn.apache.org/viewvc?rev=1340184&view=rev
> Log:
> Import the osgi blueprint stuff so it can work with a wider range of containers
>
> Modified:
>    aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>
> Modified: aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
> URL: http://svn.apache.org/viewvc/aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml?rev=1340184&r1=1340183&r2=1340184&view=diff
> ==============================================================================
> --- aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml (original)
> +++ aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml Fri May 18 17:42:46 2012
> @@ -40,7 +40,6 @@
>         </aries.osgi.activator>
>         <aries.osgi.import>
>             !org.apache.aries.blueprint*,
> -            !org.osgi.service.blueprint*,
>             org.eclipse.osgi.internal.loader;resolution:=optional,
>             org.eclipse.osgi.framework.internal.core;resolution:=optional,
>             org.eclipse.osgi.framework.adaptor;resolution:=optional,
>
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

Posted by Guillaume Nodet <gn...@gmail.com>.
I'm otherwise done with all the changes in that branch and they are
all also in trunk now.

On Tue, May 22, 2012 at 12:43 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> I don't think that's a good idea to import the osgi api.
>
> It may lead to problems if multiple blueprint implementations are
> deployed for some reason.
> To support such a case, the blueprint bundles are supposed to import
> the org.osgi.blueprint package iirc, so that the osgi framework wiring
> will be correctly split and only the blueprint extender which has been
> imported will actually extend the bundle.  By importing the api, two
> extenders can then be compatible and both would extend the bundle.
>
> IF the main reason is that people have the compendium bundle deployed,
> well, that's a bad idea because the same problem also tend to apply
> with other osgi services such as ConfigAdmin and others which usually
> ship their own version of the package.
>
>
> On Fri, May 18, 2012 at 7:42 PM,  <dk...@apache.org> wrote:
>> Author: dkulp
>> Date: Fri May 18 17:42:46 2012
>> New Revision: 1340184
>>
>> URL: http://svn.apache.org/viewvc?rev=1340184&view=rev
>> Log:
>> Import the osgi blueprint stuff so it can work with a wider range of containers
>>
>> Modified:
>>    aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>>
>> Modified: aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>> URL: http://svn.apache.org/viewvc/aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml?rev=1340184&r1=1340183&r2=1340184&view=diff
>> ==============================================================================
>> --- aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml (original)
>> +++ aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml Fri May 18 17:42:46 2012
>> @@ -40,7 +40,6 @@
>>         </aries.osgi.activator>
>>         <aries.osgi.import>
>>             !org.apache.aries.blueprint*,
>> -            !org.osgi.service.blueprint*,
>>             org.eclipse.osgi.internal.loader;resolution:=optional,
>>             org.eclipse.osgi.framework.internal.core;resolution:=optional,
>>             org.eclipse.osgi.framework.adaptor;resolution:=optional,
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml

Posted by Guillaume Nodet <gn...@gmail.com>.
I don't think that's a good idea to import the osgi api.

It may lead to problems if multiple blueprint implementations are
deployed for some reason.
To support such a case, the blueprint bundles are supposed to import
the org.osgi.blueprint package iirc, so that the osgi framework wiring
will be correctly split and only the blueprint extender which has been
imported will actually extend the bundle.  By importing the api, two
extenders can then be compatible and both would extend the bundle.

IF the main reason is that people have the compendium bundle deployed,
well, that's a bad idea because the same problem also tend to apply
with other osgi services such as ConfigAdmin and others which usually
ship their own version of the package.


On Fri, May 18, 2012 at 7:42 PM,  <dk...@apache.org> wrote:
> Author: dkulp
> Date: Fri May 18 17:42:46 2012
> New Revision: 1340184
>
> URL: http://svn.apache.org/viewvc?rev=1340184&view=rev
> Log:
> Import the osgi blueprint stuff so it can work with a wider range of containers
>
> Modified:
>    aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
>
> Modified: aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
> URL: http://svn.apache.org/viewvc/aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml?rev=1340184&r1=1340183&r2=1340184&view=diff
> ==============================================================================
> --- aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml (original)
> +++ aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml Fri May 18 17:42:46 2012
> @@ -40,7 +40,6 @@
>         </aries.osgi.activator>
>         <aries.osgi.import>
>             !org.apache.aries.blueprint*,
> -            !org.osgi.service.blueprint*,
>             org.eclipse.osgi.internal.loader;resolution:=optional,
>             org.eclipse.osgi.framework.internal.core;resolution:=optional,
>             org.eclipse.osgi.framework.adaptor;resolution:=optional,
>
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com